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

[James Prestwood <prestwoj@gmail.com>]

Hi Simonas,

On 10/14/23 2:23 AM, Simonas Kazlauskas wrote:
> Hello everyone,
> 
> I’ve been seeing some weird behaviour with iwd in my environment with 
> multiple Unifi access points, which has led me to run iwd with debug 
> mode enabled that I look through once in a while. I anticipate writing 
> more about my woes in the future, but this is the most apparent 
> weirdness I’ve seen.
> 
> In my situation, when a scan occurs, I’m seeing that 2.4GHz channels 
> will have throughput estimations that consider be realistic – the data 
> rates reflect the rates I get after connecting to those APs. On the 
> other hand, the estimated rate for 5GHz channels is extremely low & 
> incorrect from what I can tell:
> 
>      [2023-10-14 11:23:46.006184] src/station.c:station_add_seen_bss() 
> Processing BSS '00:00:00:00:00:01' with SSID: SSID1, freq: 2437, rank: 
> 1126, strength: -6600, data_rate: 137.6
>      [2023-10-14 11:23:46.006293] src/station.c:station_add_seen_bss() 
> Processing BSS '00:00:00:00:00:02' with SSID: SSID2, freq: 2437, rank: 
> 1126, strength: -6600, data_rate: 137.6
>      [2023-10-14 11:23:46.006405] src/station.c:station_add_seen_bss() 
> Processing BSS '00:00:00:00:00:03' with SSID: SSID3, freq: 2437, rank: 
> 844, strength: -6700, data_rate: 103.2
>      [2023-10-14 11:23:46.006514] src/station.c:station_add_seen_bss() 
> Processing BSS '00:00:00:00:00:04' with SSID: SSID4, freq: 2437, rank: 
> 844, strength: -6700, data_rate: 103.2
>      [2023-10-14 11:23:46.006618] src/station.c:station_add_seen_bss() 
> Processing BSS '00:00:00:00:00:05' with SSID: SSID3, freq: 2462, rank: 
> 422, strength: -7600, data_rate: 51.6
>      [2023-10-14 11:23:46.006731] src/station.c:station_add_seen_bss() 
> Processing BSS '00:00:00:00:00:06' with SSID: SSID4, freq: 2462, rank: 
> 422, strength: -7600, data_rate: 51.6
>      [2023-10-14 11:23:46.006889] src/station.c:station_add_seen_bss() 
> Processing BSS '00:00:00:00:00:07' with SSID: SSID2, freq: 2462, rank: 
> 422, strength: -7600, data_rate: 51.6
>      [2023-10-14 11:23:46.007017] src/station.c:station_add_seen_bss() 
> Processing BSS '00:00:00:00:00:08' with SSID: SSID1, freq: 2462, rank: 
> 422, strength: -7600, data_rate: 51.6
>      [2023-10-14 11:23:46.007135] src/station.c:station_add_seen_bss() 
> Processing BSS '00:00:00:00:00:09' with SSID: SSID3, freq: 5180, rank: 
> 140, strength: -8000, data_rate: 17.2
>      [2023-10-14 11:23:46.007259] src/station.c:station_add_seen_bss() 
> Processing BSS '00:00:00:00:00:10' with SSID: SSID1, freq: 5180, rank: 
> 140, strength: -8000, data_rate: 17.2
>      [2023-10-14 11:23:46.007374] src/station.c:station_add_seen_bss() 
> Processing BSS '00:00:00:00:00:11' with SSID: SSID3, freq: 5220, rank: 
> 16, strength: -9200, data_rate: 2.0
>      [2023-10-14 11:23:46.007474] src/station.c:station_add_seen_bss() 
> Processing BSS '00:00:00:00:00:12' with SSID: SSID1, freq: 5220, rank: 
> 16, strength: -9200, data_rate: 2.0

The signal strength for the 5GHz BSS's are very low. Anything below 
-80dbm is _really_ bad. So it makes sense why IWD is choosing 2.4GHz 
instead. IWD's estimation is based on data from the 802.11 spec, and 
capabilities advertised by the APs.

> 
> This leads iwd to try connecting to the 2.4GHz channels first as they're 
> ranked higher. Authentications to those channels timeout, which I 
> believe is caused by the band steering being enabled on the APs. So 
> eventually IWD connects to the 00:00:00:00:00:10 AP anyway.

Band steering should be done after authentication. APs shouldn't refuse 
connections like that, otherwise what would be the point of having a 
2.4GHz network anyways if its impossible to connect to. Something else 
must be going on here.

> 
> Once it does that, iwctl shows rates in the region of 200-300Mbps, which 
> is what I observe in practice as well, and a big difference from the 
> 17.2Mbps that iwd estimated initially:
> 
>      RSSI                  -78 dBm
>      AverageRSSI           -79 dBm
>      RxMode                802.11ax
>      RxMCS                 8
>      TxMode                802.11ax
>      TxMCS                 4
>      TxBitrate             206400 Kbit/s
>      RxBitrate             206500 Kbit/s

This is probably because IWD doesn't take into account any of the newer 
802.11ax IEs when estimating the data rate. So its estimation is based 
on VHT and not the newest EHT rates.

> 
> 
> Is it expected to be that way? If nothing else, this misestimation I 
> believe results in WiFi connection times to increase from sub-second to 
> at least 1.5 seconds, due to waiting for all the 2.4GHz channels to 
> timeout authenticating first. I’ve attached the entirety of my iwd debug 
> log (with redacted BSSs and SSIDs) from today.
> 
> For posteriority my config contains these entries:
> 
>      [General]
>      EnableNetworkConfiguration=false
>      RoamRetryInterval=120
>      RoamThreshold=1
>      RoamThreshold5G=-85
>      UseDefaultInterface=false
> 
>      [Rank]
>      BandModifier5GHz=5.000000
> 
> but as far as my code reading goes none of them should affect the 
> data_rate estimation.

Since the 2.4GHz BSS's are giving you such problems you could try a 
recently added feature to disable the 2.4GHz band entirely. You can set 
[Rank].BandModifier2_4Ghz=0.0.

Also your BandModifier5Ghz setting has a typo, its using an uppercase 
'H'. Someone else got hit by this recently, we need to add support for both.

Thanks,
James