On Mon, 2016-09-12 at 08:43 +0200, Johannes Berg wrote: > On Wed, 2016-09-07 at 18:20 +0000, Pedersen, Thomas wrote: > > > > On 09/06/2016 12:07 PM, Ben Greear wrote: > > > > > > > > > On 09/06/2016 12:00 PM, Thomas Pedersen wrote: > > > > > > > > > > > > Some drivers (ath10k) report MCS 9 @ 20MHz, which > > > > technically isn't allowed. To get more meaningful value > > > > than 0 out of this however, just cap the bitrate for 20MHz > > > > to MCS 8. > > > > > > If it is actually reporting MCS9, why lie about it? Report it up > > > the stack as a proper value instead of hiding the issue? > > > > Good point, will send a v2 extrapolating the value to 86.5Mb/s. > > That makes no sense either, IMHO. > > Are you saying that ath10k actually somehow manages to use an invalid > bitrate over the air?! > > It seems more likely that it's actually just misreporting what it's > doing, and thus the issue should be fixed in ath10k.
Yeah so apparently the overhead involved in 256-QAM 5/6 (MCS 9) results in lower effective bitrate than just using MCS 8 (unless you're using 3 spatial streams). Sounds like a rate control or reporting bug then. Please drop this. Thanks, Thomas
