Brian Norris <briannorris@xxxxxxxxxxxx> writes: > [ To be clear, I haven't asked for this debugfs knob, and as of now, > there is no plan for Chrome OS to use $subject feature. Per some of > Tony's descriptions, I suppose maybe this would be useful for certain > debugging scenarios, but only that -- no intention of wiring this up > "in production." IIUC, he CC'd me only because of the "measuring the > TX power" portion of the commit message. ] > > On Fri, Mar 20, 2020 at 6:06 AM Johannes Berg <johannes@xxxxxxxxxxxxxxxx> > wrote: > > Brian can probably comment on this - I think ChromeOS (used to) use(s) > > some kind of fixed rate at the beginning of the connection to force low > > rates? But I also remember this interacting badly with some APs that > > just don't want to enable low rates at all... > [...] > > As Johannes noted, masking off these rates caused problems of its own, > especially when APs (esp., guided by (mis?)guided I.T. admins who > think that low bitrates are evil) removed these low bitrates from > their SupportedRates field. Apparently these APs may start to reject > clients if they don't obey. > > Additionally, we found no evidence that forcing low bitrates like this > was substantially helpful for anything other than older ath9k systems. > So longer story shorter, Chrome OS does not use > NL80211_CMD_SET_TX_BITRATE_MASK any more. > We want to measure the TX power, and the equipment just cannot detect the signal on some rates, unless we "fix" the rate exactly. So NL80211_CMD_SET_TX_BITRATE_MASK is not so useful for us sometimes. Also we wanted to see not only the TX power, but the signal quality of certain modulations/coding rates, and the equipment still tends to receive fixed rates. [...] > > One could also argue that, if iwlwifi already has a debugfs knob > (looks like rs_sta_dbgfs_scale_table_write()?), rtw88 should be able > to have one too ;) > > Regards, > Brian > Yen-Hsuan
