Re: Is the data rate estimation for 5GHz channels overly pessimistic?

[Denis Kenzior <denkenz@gmail.com>]

Hi Simonas,

On 10/21/23 18:23, Simonas Kazlauskas wrote:
> Hey,
> 
> I finally got around to figuring out the test specifications (I think.) At least 
> the test results I’m seeing are the same as the output from `iwd -d`.
> 
> See the attached patch (feel free to merge it, or not to merge it – entirely up 
> to you.)

Ok, I'll take a look during the week.

> 
> 72Mbps appears to be coming from the table for 80MHz rates (NSS=2 so 36MHz in 
> the table itself), but this *should* be a 40MHz ordeal. My APs are set up for 
> 40MHz 5GHz channels and 160MHz 6GHz channels, but it seems like it might still 
> be sending capabilities that include 80MHz support…? Weird.

Probably does, but iwd should also be paying attention to the vht operations 
field and taking into account that width=40.  This is why we pass in both VHT 
Capabilities and VHT Operation elements:
https://git.kernel.org/pub/scm/network/wireless/iwd.git/tree/src/wiphy.c#n1049

> 
> [1]: https://semfionetworks.com/blog/mcs-table-updated-with-80211ax-data-rates/
> 
> Anyhow, besides the 80MHz weirdness, this all seems to ultimately come down to 
> the `ht_vht_he_base_rssi` table (as you both have pointed out in the very 
> beginning!) After the `width_adjust` in `band_he_rate` is applied, -76dBm is the 
> bare minimum for it to pick out even the lowest 36MHz rate from the 80MHz table.
> Meanwhile in practice I’m getting MCS anywhere from 4 to 10 (seems to be fairly 
> random regardless of the signal strength, which varies between -72dBm and -79dBm 
> this particular evening.) The only caveat is that for very high MCS values (8, 
> 9, 10), NSS appears to drop down to 1 (thus making them roughly equivalent to 
> MCS 4-to-5).

The values in this table are directly from 802.11.  Section 21.3.18.1 in 
802.11-2020.  These are 'minimum input level sensitivity'.  Most hardware can do 
better.  For example, here's what AX201 can do according to some HP spec sheet:

https://h20195.www2.hp.com/v2/getpdf.aspx/c06986242.pdf

•802.11b, 1Mbps : -93.5dBm 30áximum
•802.11b, 11Mbps : -84dBm 30áximum
• 802.11a/g, 6Mbps : -86dBm maximum
• 802.11a/g, 54Mbps : -72dBm maximum
• 802.11n, MCS07 : -67dBm maximum
• 802.11n, MCS15 : -64dBm maximum
• 802.11ac, MCS0 : -84dBm maximum
• 802.11ac, MCS9 : -59dBm maximum
•802.11ax, MCS11(HT40): -59dBm maximum
•802.11ax, MCS11(VHT160): -58.5dBm maximum

Minimum for MCS9 (256 QAM 5/6) is -57, but the hardware can receive it at -59. 
MCS7 (64 QAM 5/6) is -64, but the hardware can do it at -67.

Also, there seems to be little penalty between HT40/VHT160 sensitivity at a 
given MCS, at least for HE.  There's a 3 db penalty per width step in 802.11. 
For example, 802.11 AX lists minimum sensitivity for HE MCS11 @ 40 Mhz(1024-QAM 
5/6) as -49, but the hw can do it at -59, quite a difference.  For HE @ 160 Mhz 
the difference is even bigger, -43 according to the spec, but -58.5 according to 
the hardware.  As you can see, HE sensitivity estimate is largely out of whack 
with stated specs.

A more realistic estimate for AX201 on HE might be to increase the sensitivity 
by ~7 db and drop the 3 db 'width' penalty in band_ofdm_rate().  See if we get 
closer?

Another interesting this is that HT rates suffer a ~3db penalty for NSS=2 
(MCS07/MCS15).  This is something we also don't take into account.

Now the question is, how do we make sure iwd is estimating the HE rate if 
available?  Also, how do we tweak the estimation logic with sensitivity numbers 
(obtained from a spec sheet, or through experimentation) for specific hardware 
being used.

Regards,
-Denis