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

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

[Simonas Kazlauskas]

[-- Attachment #1: Type: text/plain, Size: 4216 bytes --]

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

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.

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


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.

[-- Attachment #2: log --]
[-- Type: text/plain, Size: 20026 bytes --]

[2023-10-14 11:23:45.425115] src/netdev.c:netdev_mlme_notify() MLME notification Del Station(20)
[2023-10-14 11:23:45.425896] src/netdev.c:netdev_link_notify() event 16 on ifindex 6
[2023-10-14 11:23:45.426149] src/netdev.c:netdev_mlme_notify() MLME notification Deauthenticate(39)
[2023-10-14 11:23:45.426301] src/netdev.c:netdev_deauthenticate_event()
[2023-10-14 11:23:45.426587] src/netdev.c:netdev_link_notify() event 16 on ifindex 6
[2023-10-14 11:23:45.426853] src/netdev.c:netdev_mlme_notify() MLME notification Disconnect(48)
[2023-10-14 11:23:45.427113] src/netdev.c:netdev_disconnect_event()
[2023-10-14 11:23:45.429020] Received Deauthentication event, reason: 3, from_ap: false
[2023-10-14 11:23:45.429371] src/station.c:station_disconnect_event() 6
[2023-10-14 11:23:45.429674] src/station.c:station_disassociated() 6
[2023-10-14 11:23:45.429990] src/station.c:station_reset_connection_state() 6
[2023-10-14 11:23:45.430338] src/station.c:station_roam_state_clear() 6
[2023-10-14 11:23:45.430649] src/station.c:station_enter_state() Old State: connected, new state: disconnected
[2023-10-14 11:23:45.430988] src/station.c:station_enter_state() Old State: disconnected, new state: autoconnect_quick
[2023-10-14 11:23:45.431300] src/wiphy.c:wiphy_radio_work_insert() Inserting work item 6
[2023-10-14 11:23:45.431601] src/wiphy.c:wiphy_radio_work_next() Starting work item 6
[2023-10-14 11:23:45.431914] src/wiphy.c:wiphy_reg_notify() Notification of command Wiphy Reg Change(113)
[2023-10-14 11:23:45.432223] src/wiphy.c:wiphy_update_reg_domain() New reg domain country code for phy0 is XX
[2023-10-14 11:23:45.432515] src/scan.c:scan_notify() Scan notification Trigger Scan(33)
[2023-10-14 11:23:45.432810] src/scan.c:scan_request_triggered() Active scan triggered for wdev 6
[2023-10-14 11:23:45.433122] src/station.c:station_quick_scan_triggered() Quick scan triggered for wlan0
[2023-10-14 11:23:45.994947] src/wiphy.c:wiphy_reg_notify() Notification of command Wiphy Reg Change(113)
[2023-10-14 11:23:45.995156] src/wiphy.c:wiphy_update_reg_domain() New reg domain country code for phy0 is LT
[2023-10-14 11:23:46.003086] src/scan.c:scan_notify() Scan notification New Scan Results(34)
[2023-10-14 11:23:46.003349] src/netdev.c:netdev_link_notify() event 16 on ifindex 6
[2023-10-14 11:23:46.003461] src/scan.c:get_scan_callback() get_scan_callback
[2023-10-14 11:23:46.003548] src/scan.c:scan_parse_bss_information_elements() Load: 36/255
[2023-10-14 11:23:46.003633] src/scan.c:get_scan_callback() get_scan_callback
[2023-10-14 11:23:46.003716] src/scan.c:scan_parse_bss_information_elements() Load: 36/255
[2023-10-14 11:23:46.003841] src/scan.c:get_scan_callback() get_scan_callback
[2023-10-14 11:23:46.003963] src/scan.c:scan_parse_bss_information_elements() Load: 36/255
[2023-10-14 11:23:46.004073] src/scan.c:get_scan_callback() get_scan_callback
[2023-10-14 11:23:46.004178] src/scan.c:scan_parse_bss_information_elements() Load: 36/255
[2023-10-14 11:23:46.004294] src/scan.c:get_scan_callback() get_scan_callback
[2023-10-14 11:23:46.004401] src/scan.c:scan_parse_bss_information_elements() Load: 40/255
[2023-10-14 11:23:46.004509] src/scan.c:get_scan_callback() get_scan_callback
[2023-10-14 11:23:46.004614] src/scan.c:scan_parse_bss_information_elements() Load: 40/255
[2023-10-14 11:23:46.004724] src/scan.c:get_scan_callback() get_scan_callback
[2023-10-14 11:23:46.004853] src/scan.c:scan_parse_bss_information_elements() Load: 40/255
[2023-10-14 11:23:46.004971] src/scan.c:get_scan_callback() get_scan_callback
[2023-10-14 11:23:46.005083] src/scan.c:scan_parse_bss_information_elements() Load: 40/255
[2023-10-14 11:23:46.005191] src/scan.c:get_scan_callback() get_scan_callback
[2023-10-14 11:23:46.005297] src/scan.c:scan_parse_bss_information_elements() Load: 4/255
[2023-10-14 11:23:46.005401] src/scan.c:get_scan_callback() get_scan_callback
[2023-10-14 11:23:46.005510] src/scan.c:scan_parse_bss_information_elements() Load: 4/255
[2023-10-14 11:23:46.005621] src/scan.c:get_scan_callback() get_scan_callback
[2023-10-14 11:23:46.005731] src/scan.c:scan_parse_bss_information_elements() Load: 3/255
[2023-10-14 11:23:46.005856] src/scan.c:get_scan_callback() get_scan_callback
[2023-10-14 11:23:46.005973] src/scan.c:scan_parse_bss_information_elements() Load: 3/255
[2023-10-14 11:23:46.006079] src/scan.c:get_scan_done() get_scan_done
[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
[2023-10-14 11:23:46.007558] src/station.c:station_autoconnect_start()
[2023-10-14 11:23:46.007657] src/wiphy.c:wiphy_select_akm() Network is WPA3-Personal...
[2023-10-14 11:23:46.007763] src/station.c:station_autoconnect_next() autoconnect: Trying SSID: SSID1
[2023-10-14 11:23:46.007895] src/station.c:station_autoconnect_next() autoconnect: '00:00:00:00:00:01' freq: 2437, rank: 1126, strength: -6600
[2023-10-14 11:23:46.008010] src/wiphy.c:wiphy_select_akm() Network is WPA3-Personal...
[2023-10-14 11:23:46.008130] src/netdev.c:netdev_cqm_rssi_update()
[2023-10-14 11:23:46.008233] src/wiphy.c:wiphy_radio_work_insert() Inserting work item 7
[2023-10-14 11:23:46.008327] src/station.c:__station_connect_network() connecting to BSS 00:00:00:00:00:01
[2023-10-14 11:23:46.008438] src/station.c:station_enter_state() Old State: autoconnect_quick, new state: connecting (auto)
[2023-10-14 11:23:46.008572] src/scan.c:scan_cancel() Trying to cancel scan id 6 for wdev 6
[2023-10-14 11:23:46.008690] src/wiphy.c:wiphy_radio_work_done() Work item 6 done
[2023-10-14 11:23:46.008869] src/wiphy.c:wiphy_radio_work_next() Starting work item 7
[2023-10-14 11:23:46.042487] CMD_SET_CQM failed: Invalid argument
[2023-10-14 11:23:46.048545] src/netdev.c:netdev_mlme_notify() MLME notification New Station(19)
[2023-10-14 11:23:46.079448] src/netdev.c:netdev_mlme_notify() MLME notification Authenticate(37)
[2023-10-14 11:23:46.079688] src/netdev.c:netdev_authenticate_event()
[2023-10-14 11:23:46.107648] src/netdev.c:netdev_mlme_notify() MLME notification Del Station(20)
[2023-10-14 11:23:46.107927] src/netdev.c:netdev_mlme_notify() MLME notification New Station(19)
[2023-10-14 11:23:46.206679] src/netdev.c:netdev_mlme_notify() MLME notification Authenticate(37)
[2023-10-14 11:23:46.206932] src/netdev.c:netdev_authenticate_event()
[2023-10-14 11:23:46.231296] src/netdev.c:netdev_mlme_notify() MLME notification Authenticate(37)
[2023-10-14 11:23:46.231527] src/netdev.c:netdev_authenticate_event()
[2023-10-14 11:23:46.561747] src/netdev.c:netdev_mlme_notify() MLME notification Del Station(20)
[2023-10-14 11:23:46.562371] src/netdev.c:netdev_mlme_notify() MLME notification Associate(38)
[2023-10-14 11:23:46.562562] src/netdev.c:netdev_associate_event()
[2023-10-14 11:23:46.562682] association timed out
[2023-10-14 11:23:46.562797] Error sending CMD_ASSOCIATE (-2)
[2023-10-14 11:23:46.563514] src/wiphy.c:wiphy_radio_work_done() Work item 7 done
[2023-10-14 11:23:46.563629] src/station.c:station_connect_cb() 6, result: 2
[2023-10-14 11:23:46.563733] src/wiphy.c:wiphy_select_akm() Network is WPA3-Personal...
[2023-10-14 11:23:46.563906] src/wiphy.c:wiphy_select_akm() Network is WPA3-Personal...
[2023-10-14 11:23:46.564017] src/netdev.c:netdev_cqm_rssi_update()
[2023-10-14 11:23:46.564121] src/wiphy.c:wiphy_radio_work_insert() Inserting work item 8
[2023-10-14 11:23:46.564222] src/wiphy.c:wiphy_radio_work_next() Starting work item 8
[2023-10-14 11:23:46.600850] src/station.c:__station_connect_network() connecting to BSS 00:00:00:00:00:01
[2023-10-14 11:23:46.601012] src/station.c:station_try_next_bss() Attempting to connect to next BSS 00:00:00:00:00:01
[2023-10-14 11:23:46.601105] CMD_SET_CQM failed: Invalid argument
[2023-10-14 11:23:46.601193] src/netdev.c:netdev_auth_cb() Error during auth: -2
[2023-10-14 11:23:46.602065] src/scan.c:scan_notify() Scan notification Trigger Scan(33)
[2023-10-14 11:23:46.719156] src/netdev.c:netdev_new_scan_results_event()
[2023-10-14 11:23:46.719398] src/scan.c:scan_notify() Scan notification New Scan Results(34)
[2023-10-14 11:23:46.719496] src/netdev.c:netdev_link_notify() event 16 on ifindex 6
[2023-10-14 11:23:46.722773] src/netdev.c:netdev_mlme_notify() MLME notification New Station(19)
[2023-10-14 11:23:46.761627] src/netdev.c:netdev_mlme_notify() MLME notification Authenticate(37)
[2023-10-14 11:23:46.761853] src/netdev.c:netdev_authenticate_event()
[2023-10-14 11:23:46.761968] src/wiphy.c:wiphy_radio_work_done() Work item 8 done
[2023-10-14 11:23:46.762059] src/station.c:station_connect_cb() 6, result: 1
[2023-10-14 11:23:46.762135] src/wiphy.c:wiphy_select_akm() Network is WPA3-Personal...
[2023-10-14 11:23:46.762252] src/wiphy.c:wiphy_select_akm() Network is WPA3-Personal...
[2023-10-14 11:23:46.762373] src/netdev.c:netdev_cqm_rssi_update()
[2023-10-14 11:23:46.762451] src/wiphy.c:wiphy_radio_work_insert() Inserting work item 9
[2023-10-14 11:23:46.762521] src/wiphy.c:wiphy_radio_work_next() Starting work item 9
[2023-10-14 11:23:46.794606] src/station.c:__station_connect_network() connecting to BSS 00:00:00:00:00:01
[2023-10-14 11:23:46.794775] src/station.c:station_try_next_bss() Attempting to connect to next BSS 00:00:00:00:00:01
[2023-10-14 11:23:46.794922] src/netdev.c:netdev_mlme_notify() MLME notification Del Station(20)
[2023-10-14 11:23:46.795024] CMD_SET_CQM failed: Invalid argument
[2023-10-14 11:23:46.798169] src/netdev.c:netdev_mlme_notify() MLME notification New Station(19)
[2023-10-14 11:23:46.840398] src/netdev.c:netdev_mlme_notify() MLME notification Authenticate(37)
[2023-10-14 11:23:46.840634] src/netdev.c:netdev_authenticate_event()
[2023-10-14 11:23:46.840734] src/wiphy.c:wiphy_radio_work_done() Work item 9 done
[2023-10-14 11:23:46.840857] src/station.c:station_connect_cb() 6, result: 1
[2023-10-14 11:23:46.840984] src/wiphy.c:wiphy_select_akm() Network is WPA3-Personal...
[2023-10-14 11:23:46.841149] src/wiphy.c:wiphy_select_akm() Network is WPA3-Personal...
[2023-10-14 11:23:46.841264] src/wiphy.c:wiphy_select_akm() Network is WPA3-Personal...
[2023-10-14 11:23:46.841352] src/netdev.c:netdev_cqm_rssi_update()
[2023-10-14 11:23:46.841434] src/wiphy.c:wiphy_radio_work_insert() Inserting work item 10
[2023-10-14 11:23:46.841514] src/wiphy.c:wiphy_radio_work_next() Starting work item 10
[2023-10-14 11:23:46.876036] src/station.c:__station_connect_network() connecting to BSS 00:00:00:00:00:08
[2023-10-14 11:23:46.876203] src/station.c:station_try_next_bss() Attempting to connect to next BSS 00:00:00:00:00:08
[2023-10-14 11:23:46.876295] src/netdev.c:netdev_mlme_notify() MLME notification Del Station(20)
[2023-10-14 11:23:46.876383] CMD_SET_CQM failed: Invalid argument
[2023-10-14 11:23:46.879488] src/netdev.c:netdev_mlme_notify() MLME notification New Station(19)
[2023-10-14 11:23:46.916611] src/netdev.c:netdev_mlme_notify() MLME notification Authenticate(37)
[2023-10-14 11:23:46.916882] src/netdev.c:netdev_authenticate_event()
[2023-10-14 11:23:46.929372] src/netdev.c:netdev_mlme_notify() MLME notification Del Station(20)
[2023-10-14 11:23:46.936504] src/netdev.c:netdev_mlme_notify() MLME notification New Station(19)
[2023-10-14 11:23:47.054721] src/netdev.c:netdev_mlme_notify() MLME notification Authenticate(37)
[2023-10-14 11:23:47.055000] src/netdev.c:netdev_authenticate_event()
[2023-10-14 11:23:47.093228] src/netdev.c:netdev_mlme_notify() MLME notification Authenticate(37)
[2023-10-14 11:23:47.093504] src/netdev.c:netdev_authenticate_event()
[2023-10-14 11:23:47.420248] src/netdev.c:netdev_mlme_notify() MLME notification Del Station(20)
[2023-10-14 11:23:47.420911] src/netdev.c:netdev_mlme_notify() MLME notification Associate(38)
[2023-10-14 11:23:47.421097] src/netdev.c:netdev_associate_event()
[2023-10-14 11:23:47.421221] association timed out
[2023-10-14 11:23:47.421345] Error sending CMD_ASSOCIATE (-2)
[2023-10-14 11:23:47.421456] src/wiphy.c:wiphy_radio_work_done() Work item 10 done
[2023-10-14 11:23:47.421567] src/station.c:station_connect_cb() 6, result: 2
[2023-10-14 11:23:47.421680] src/wiphy.c:wiphy_select_akm() Network is WPA3-Personal...
[2023-10-14 11:23:47.421788] src/wiphy.c:wiphy_select_akm() Network is WPA3-Personal...
[2023-10-14 11:23:47.421935] src/wiphy.c:wiphy_select_akm() Network is WPA3-Personal...
[2023-10-14 11:23:47.422049] src/wiphy.c:wiphy_select_akm() Network is WPA3-Personal...
[2023-10-14 11:23:47.422157] src/netdev.c:netdev_cqm_rssi_update()
[2023-10-14 11:23:47.422266] src/wiphy.c:wiphy_radio_work_insert() Inserting work item 11
[2023-10-14 11:23:47.422373] src/wiphy.c:wiphy_radio_work_next() Starting work item 11
[2023-10-14 11:23:47.456508] src/station.c:__station_connect_network() connecting to BSS 00:00:00:00:00:10
[2023-10-14 11:23:47.456688] src/station.c:station_try_next_bss() Attempting to connect to next BSS 00:00:00:00:00:10
[2023-10-14 11:23:47.461036] src/netdev.c:netdev_mlme_notify() MLME notification New Station(19)
[2023-10-14 11:23:47.492314] src/netdev.c:netdev_mlme_notify() MLME notification Authenticate(37)
[2023-10-14 11:23:47.492529] src/netdev.c:netdev_authenticate_event()
[2023-10-14 11:23:47.505915] src/netdev.c:netdev_mlme_notify() MLME notification Del Station(20)
[2023-10-14 11:23:47.510470] src/netdev.c:netdev_mlme_notify() MLME notification New Station(19)
[2023-10-14 11:23:47.598257] src/netdev.c:netdev_mlme_notify() MLME notification Authenticate(37)
[2023-10-14 11:23:47.598489] src/netdev.c:netdev_authenticate_event()
[2023-10-14 11:23:47.623158] src/netdev.c:netdev_mlme_notify() MLME notification Authenticate(37)
[2023-10-14 11:23:47.623496] src/netdev.c:netdev_authenticate_event()
[2023-10-14 11:23:47.634026] src/netdev.c:netdev_mlme_notify() MLME notification Associate(38)
[2023-10-14 11:23:47.634324] src/netdev.c:netdev_associate_event()
[2023-10-14 11:23:47.634481] src/netdev.c:netdev_mlme_notify() MLME notification Connect(46)
[2023-10-14 11:23:47.634585] src/netdev.c:netdev_connect_event()
[2023-10-14 11:23:47.634680] src/netdev.c:netdev_connect_event() aborting and ignore_connect_event not set, proceed
[2023-10-14 11:23:47.634773] src/netdev.c:netdev_connect_event() expect_connect_failure not set, proceed
[2023-10-14 11:23:47.634910] src/netdev.c:parse_request_ies()
[2023-10-14 11:23:47.635032] src/netdev.c:netdev_connect_event() Request / Response IEs parsed
[2023-10-14 11:23:47.635126] src/netdev.c:netdev_get_oci()
[2023-10-14 11:23:47.635218] src/netdev.c:netdev_link_notify() event 16 on ifindex 6
[2023-10-14 11:23:47.635312] src/netdev.c:netdev_link_notify() event 16 on ifindex 6
[2023-10-14 11:23:47.635403] src/netdev.c:netdev_get_oci_cb() Obtained OCI: freq: 5180, width: 2, center1: 5190, center2: 0
[2023-10-14 11:23:47.635495] src/eapol.c:eapol_start()
[2023-10-14 11:23:47.635595] src/netdev.c:netdev_link_notify() event 16 on ifindex 6
[2023-10-14 11:23:47.635688] src/netdev.c:netdev_link_notify() event 16 on ifindex 6
[2023-10-14 11:23:47.661940] src/netdev.c:netdev_unicast_notify() Unicast notification Control Port Frame(129)
[2023-10-14 11:23:47.662104] src/netdev.c:netdev_control_port_frame_event()
[2023-10-14 11:23:47.662189] src/eapol.c:eapol_handle_ptk_1_of_4() ifindex=6
[2023-10-14 11:23:47.663891] src/netdev.c:netdev_mlme_notify() MLME notification Control Port TX Status(139)
[2023-10-14 11:23:47.667478] src/netdev.c:netdev_unicast_notify() Unicast notification Control Port Frame(129)
[2023-10-14 11:23:47.667586] src/netdev.c:netdev_control_port_frame_event()
[2023-10-14 11:23:47.668080] src/eapol.c:eapol_handle_ptk_3_of_4() ifindex=6
[2023-10-14 11:23:47.668178] src/netdev.c:netdev_set_gtk() ifindex=6 key_idx=1
[2023-10-14 11:23:47.668235] src/netdev.c:netdev_set_igtk() ifindex=6 key_idx=4
[2023-10-14 11:23:47.668287] src/station.c:station_handshake_event() Setting keys
[2023-10-14 11:23:47.668339] src/netdev.c:netdev_set_tk() ifindex=6 key_idx=0
[2023-10-14 11:23:47.668388] src/netdev.c:netdev_set_rekey_offload() 6
[2023-10-14 11:23:47.680872] src/netdev.c:netdev_new_group_key_cb() ifindex: 6, err: 0
[2023-10-14 11:23:47.681042] src/netdev.c:try_handshake_complete() ptk_installed: 0, gtk_installed: 1, igtk_installed: 0
[2023-10-14 11:23:47.688708] src/netdev.c:netdev_new_group_management_key_cb() ifindex: 6, err: 0
[2023-10-14 11:23:47.688946] src/netdev.c:try_handshake_complete() ptk_installed: 0, gtk_installed: 1, igtk_installed: 1
[2023-10-14 11:23:47.694721] src/netdev.c:netdev_mlme_notify() MLME notification Control Port TX Status(139)
[2023-10-14 11:23:47.695985] src/netdev.c:netdev_set_station_cb()
[2023-10-14 11:23:47.696190] src/netdev.c:try_handshake_complete() ptk_installed: 1, gtk_installed: 1, igtk_installed: 1
[2023-10-14 11:23:47.696349] src/netdev.c:try_handshake_complete() nhs->complete: 0
[2023-10-14 11:23:47.696502] src/netdev.c:try_handshake_complete() Invoking handshake_event()
[2023-10-14 11:23:47.696655] src/netdev.c:netdev_connect_ok()
[2023-10-14 11:23:47.696817] src/station.c:station_connect_cb() 6, result: 0
[2023-10-14 11:23:47.697001] src/station.c:station_connect_ok()
[2023-10-14 11:23:47.697153] src/station.c:station_enter_state() Old State: connecting (auto), new state: connected
[2023-10-14 11:23:47.697370] src/wiphy.c:wiphy_radio_work_done() Work item 11 done
[2023-10-14 11:23:47.697510] src/netdev.c:netdev_link_notify() event 16 on ifindex 6
[2023-10-14 11:23:47.697604] src/netdev.c:netdev_mlme_notify() MLME notification Frame TX Status(60)
[2023-10-14 11:23:47.699295] src/station.c:station_early_neighbor_report_cb() ifindex: 6, error: 0()
[2023-10-14 11:23:47.699477] src/netdev.c:netdev_unicast_notify() Unicast notification Frame(59)
[2023-10-14 11:23:47.743312] src/netdev.c:netdev_mlme_notify() MLME notification Notify CQM(64)
[2023-10-14 11:23:47.743815] src/netdev.c:netdev_cqm_event() Signal change event (above=1 signal=-79)
[2023-10-14 11:27:14.568840] src/netdev.c:netdev_mlme_notify() MLME notification Notify CQM(64)
[2023-10-14 11:27:14.569147] src/netdev.c:netdev_cqm_event() Signal change event (above=1 signal=-70)

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

[James Prestwood]

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

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

[Denis Kenzior]

Hi James,

>>
>>      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.

We should support HE rates just fine.  Just look at the unit tests in 
test-band.c.  Probably need an iwmon log of the AP IEs and local capabilities to 
see why the estimate is lower than what happens in practice.

What hardware is being used here?

Regards,
-Denis

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

[Simonas Kazlauskas]

Hey,

James Prestwood wrote:
>Hi Simonas,
>
>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.

The RSSI is an unfortunate combination of my walls being quite thick (and 
really good at attenuating 5GHz), the AP being right across said wall and, I 
believe, Ubiquiti’s automatic signal strength algorithm not picking the 
maximum transmit strength[^1] in order to avoid the sticky client problem.

[^1]: At the maximum allowed 20dBm transmit power the AverageRSSI is -72dBm.

Is -80dBm really that bad? In my experience even -85dBm felt quite serviceable 
in terms of speed and stability. Looking at Unifi’s own client diagnostics, I 
see that the connection to the machine in question does have an increased “TX 
Retries” metric at around 15%. But it is comparable to some other devices with 
RSSIs in the neighbourhood of -70dBm and retries still at around 13%, so I'm 
not quite sure if I should be paying much of my attention to that metric.

I unfortunately am not able to add more APs without tearing down the ceiling, 
and my experience with -80dBm really didn’t feel bad enough to justify maxing 
out the transmit power and thus incapacitating roaming elsewhere.

>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.

Got it, I’ll investigate the authentication failures further. Though any 
suggestions on what I should be looking at would be appreciated, as the only 
idea I have right now is to disable band steering and see if the 
authentication failures in the 2.4GHz band go away.

>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 taking into account the EHT rates something that *should* be implemented, 
or is this something that cannot be implemented (and thus this misestimation 
cannot be fixed?) I could dedicate some effort implementing this if its the 
former (though, again, any links to relevant resources or docs would be 
greatly appreciated to save me the effort looking for good ones myself, if you 
have any on hand.) If it is the latter, I would love to learn more about why 
that’s the case.

>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.

Right. I don’t necessarily want to disable 2.4GHz entirely. The device in 
question is a laptop, and I use it sometimes in locations around my house 
where I don’t anticipate 5GHz channels to be a good choice at all. I could try 
fine-tuning for my experience by fiddling with these ranking modifiers, but my 
experience today isn’t *that* terrible that I wouldn’t be able to address it 
by other means.

>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.

ACK

>Thanks,
>James

Thank you,
S.

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

[Simonas Kazlauskas]

Denis Kenzior wrote:
>Hi James,
>
>>>
>>>     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.
>
>We should support HE rates just fine.  Just look at the unit tests in 
>test-band.c.  Probably need an iwmon log of the AP IEs and local 
>capabilities to see why the estimate is lower than what happens in 
>practice.
>
>What hardware is being used here?

Intel’s AX201 on the client side and Ubiquiti’s U6-Pro are the AP(s).

Thank you for pointing me at iwmon, I’ll fiddle with it :)

>
>Regards,
>-Denis

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

[Denis Kenzior]

Hi Simonas,

On 10/14/23 12:45, Simonas Kazlauskas wrote:
> Denis Kenzior wrote:
>> Hi James,
>>
>>>>
>>>>      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.
>>
>> We should support HE rates just fine.  Just look at the unit tests in 
>> test-band.c.  Probably need an iwmon log of the AP IEs and local capabilities 
>> to see why the estimate is lower than what happens in practice.
>>
>> What hardware is being used here?
> 
> Intel’s AX201 on the client side and Ubiquiti’s U6-Pro are the AP(s).
> 
> Thank you for pointing me at iwmon, I’ll fiddle with it :)

It may be we screwed something up with HE since hardware was still pretty rare 
when the feature was developed.  But we do treat RSSI values below -82 as almost 
unusable.  Perhaps this needs to be tweaked for newer hardware.

If you want to get your hands dirty, it should be fairly easy to modify 
unit/test-band.c to test what our estimate code does with your specific 
circumstances.

The local HE capabilities can be found via 'iw phy', looking at what iwd prints 
at start, or using iwmon.  Similarly, remote capabilities can be sniffed using 
iwmon and running an iwd scan or 'iw scan trigger'.

Me or James can walk you through all this if needed.

Regards,
-Denis

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

[Simonas Kazlauskas]

[-- Attachment #1: Type: text/plain, Size: 3210 bytes --]

Hey,

Denis Kenzior wrote:
>It may be we screwed something up with HE since hardware was still pretty 
>rare when the feature was developed.  But we do treat RSSI values below -82 
>as almost unusable.  Perhaps this needs to be tweaked for newer hardware.
>
>If you want to get your hands dirty, it should be fairly easy to 
>modify unit/test-band.c to test what our estimate code does with your 
>specific circumstances.
>
>The local HE capabilities can be found via 'iw phy', looking at what 
>iwd prints at start, or using iwmon.  Similarly, remote capabilities 
>can be sniffed using iwmon and running an iwd scan or 'iw scan 
>trigger'.
>
>Me or James can walk you through all this if needed.

Thanks for offering. I have cracked open the file, and just started playing 
around by adding a new `he_test_data` structure. Alas, I’m really hazy on what 
I ought to be filing into the `capabilities` and `he_capabilities` fields. My 
initial guess is something like this, based on one of the other tests around:

+/* 5GHz, 40MHz, MCS 11, NSS 1 */
+const struct he_test_data he_test_5_40mhz_mcs_5_nss_1 = {
+	.freq = BAND_FREQ_5_GHZ,
+	.rssi = -76,
+	.expected_rate = 275200000ULL,
+	.capabilities = {
+		.he_mcs_set = { HE_MCS_SET(MCS11, 1), MCS_UNSUP },
+		.he_phy_capa = { HE_PHY_CAPA(0x00) },
+		.iftypes = 1 << NETDEV_IFTYPE_STATION,
+	},
+	.he_capabilities = {
+		22, IE_TYPE_HE_CAPABILITIES - 256, HE_MAC_CAPA,
+		HE_PHY_CAPA(0x00), MCS_UNSUP, HE_MCS_SET(MCS11, 1)
+	},
+};

This computes a rate of `25800000`, which I’m guessing corresponds to 
25.8Mbps, perhaps? That’s fair I guess, since the only thing I really really 
changed in there compared to the other tests is the `MCS11` (that’s supported 
by AX201) and the `rssi`. There clearly are plenty of other fields that I 
should be filling in here, I feel, if I wanted to accurately represent my 
hardware.

I think I managed to grab the capabilities of both the AP and the client using 
your instructions, but I’m really unclear on how to go from the output from 
`iwmon` to fields in this struct. My best guess right now is to actually run 
`iwd` under a gdb and place some breakpoints in the scanning code to extract 
the capabilities. Would that make sense, or is there a better way to fill in 
these fields?

(As I’m writing this mail, I realize now that I probably want to somehow 
specify NSS=2 for `2x2` MIMO…?)

Another thing that confuses me a great deal is the fact that the scan results 
with my APs don’t actually show any of the HE capabilities, only the HT and 
VHT ones (see attached sample from the `iwmon` output.) I also tried scanning 
an Android hotspot on a reasonably recent phone, and although the set of MCS 
supported were different, the output still contains only HT and VHT 
capabilities. I would love to attach my pcap here, but unfortunately I also 
have no clue how to sanitize it, so I’m going to attach an excerpt from 
`iwmon`’s output for the time being. Is this expected, or could this perhaps 
be at least part of the problem I’m seeing? Is it possible that an AP could 
not advertise HE capabilities at scan time, but for HE to still be used after 
authentication occurs?

Thank you,
S.

[-- Attachment #2: x --]
[-- Type: text/plain, Size: 452 bytes --]

/* 5GHz, 40MHz, MCS 11, NSS 1 */
const struct he_test_data he_test_5_40mhz_mcs_5_nss_1 = {
	.freq = BAND_FREQ_5_GHZ,
	.rssi = -76,
	.expected_rate = 275200000ULL,
	.capabilities = {
		.he_mcs_set = { HE_MCS_SET(MCS11, 1), MCS_UNSUP },
		.he_phy_capa = { HE_PHY_CAPA(0x00) },
		.iftypes = 1 << NETDEV_IFTYPE_STATION,
	},
	.he_capabilities = {
		22, IE_TYPE_HE_CAPABILITIES - 256, HE_MAC_CAPA,
		HE_PHY_CAPA(0x00), MCS_UNSUP, HE_MCS_SET(MCS11, 1)
	},
};

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

[James Prestwood]

Hi Somonas,

On 10/15/23 12:40 PM, Simonas Kazlauskas wrote:
> Hey,
> 
> Denis Kenzior wrote:
>> It may be we screwed something up with HE since hardware was still 
>> pretty rare when the feature was developed.  But we do treat RSSI 
>> values below -82 as almost unusable.  Perhaps this needs to be tweaked 
>> for newer hardware.
>>
>> If you want to get your hands dirty, it should be fairly easy to 
>> modify unit/test-band.c to test what our estimate code does with your 
>> specific circumstances.
>>
>> The local HE capabilities can be found via 'iw phy', looking at what 
>> iwd prints at start, or using iwmon.  Similarly, remote capabilities 
>> can be sniffed using iwmon and running an iwd scan or 'iw scan trigger'.
>>
>> Me or James can walk you through all this if needed.
> 
> Thanks for offering. I have cracked open the file, and just started 
> playing around by adding a new `he_test_data` structure. Alas, I’m 
> really hazy on what I ought to be filing into the `capabilities` and 
> `he_capabilities` fields. My initial guess is something like this, based 
> on one of the other tests around:
> 
> +/* 5GHz, 40MHz, MCS 11, NSS 1 */
> +const struct he_test_data he_test_5_40mhz_mcs_5_nss_1 = {
> +    .freq = BAND_FREQ_5_GHZ,
> +    .rssi = -76,
> +    .expected_rate = 275200000ULL,
> +    .capabilities = {
> +        .he_mcs_set = { HE_MCS_SET(MCS11, 1), MCS_UNSUP },
> +        .he_phy_capa = { HE_PHY_CAPA(0x00) },
> +        .iftypes = 1 << NETDEV_IFTYPE_STATION,
> +    },
> +    .he_capabilities = {
> +        22, IE_TYPE_HE_CAPABILITIES - 256, HE_MAC_CAPA,
> +        HE_PHY_CAPA(0x00), MCS_UNSUP, HE_MCS_SET(MCS11, 1)
> +    },
> +};
> 
> This computes a rate of `25800000`, which I’m guessing corresponds to 
> 25.8Mbps, perhaps? That’s fair I guess, since the only thing I really 
> really changed in there compared to the other tests is the `MCS11` 
> (that’s supported by AX201) and the `rssi`. There clearly are plenty of 
> other fields that I should be filling in here, I feel, if I wanted to 
> accurately represent my hardware.
> 
> I think I managed to grab the capabilities of both the AP and the client 
> using your instructions, but I’m really unclear on how to go from the 
> output from `iwmon` to fields in this struct. My best guess right now is 
> to actually run `iwd` under a gdb and place some breakpoints in the 
> scanning code to extract the capabilities. Would that make sense, or is 
> there a better way to fill in these fields?
> 
> (As I’m writing this mail, I realize now that I probably want to somehow 
> specify NSS=2 for `2x2` MIMO…?)
> 
> Another thing that confuses me a great deal is the fact that the scan 
> results with my APs don’t actually show any of the HE capabilities, only 
> the HT and VHT ones (see attached sample from the `iwmon` output.) I 
> also tried scanning an Android hotspot on a reasonably recent phone, and 
> although the set of MCS supported were different, the output still 
> contains only HT and VHT capabilities. I would love to attach my pcap 
> here, but unfortunately I also have no clue how to sanitize it, so I’m 
> going to attach an excerpt from `iwmon`’s output for the time being. Is 
> this expected, or could this perhaps be at least part of the problem I’m 
> seeing? Is it possible that an AP could not advertise HE capabilities at 
> scan time, but for HE to still be used after authentication occurs?

Looks like iwmon doesn't actually print out the HE element, but that 
doesn't explain the same behavior on the android device. If your more 
comfortable you could send the pcap just to Me or Denis.

But as Denis pointed out maybe this needs another look as far as signal 
strength any usability. The difficult part is one card could perform 
much better at -85dbm than another. I'll take a closer look and see if 
something got missed in the spec and do some testing myself (I think I 
have an ax201, and definitely an ax210).

Thanks,
James

> 
> Thank you,
> S.

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

[James Prestwood]

Hi Simonas,

On 10/16/23 4:35 AM, James Prestwood wrote:
> Hi Somonas,
> 
> On 10/15/23 12:40 PM, Simonas Kazlauskas wrote:
>> Hey,
>>
>> Denis Kenzior wrote:
>>> It may be we screwed something up with HE since hardware was still 
>>> pretty rare when the feature was developed.  But we do treat RSSI 
>>> values below -82 as almost unusable.  Perhaps this needs to be 
>>> tweaked for newer hardware.
>>>
>>> If you want to get your hands dirty, it should be fairly easy to 
>>> modify unit/test-band.c to test what our estimate code does with your 
>>> specific circumstances.
>>>
>>> The local HE capabilities can be found via 'iw phy', looking at what 
>>> iwd prints at start, or using iwmon.  Similarly, remote capabilities 
>>> can be sniffed using iwmon and running an iwd scan or 'iw scan trigger'.
>>>
>>> Me or James can walk you through all this if needed.
>>
>> Thanks for offering. I have cracked open the file, and just started 
>> playing around by adding a new `he_test_data` structure. Alas, I’m 
>> really hazy on what I ought to be filing into the `capabilities` and 
>> `he_capabilities` fields. My initial guess is something like this, 
>> based on one of the other tests around:
>>
>> +/* 5GHz, 40MHz, MCS 11, NSS 1 */
>> +const struct he_test_data he_test_5_40mhz_mcs_5_nss_1 = {
>> +    .freq = BAND_FREQ_5_GHZ,
>> +    .rssi = -76,
>> +    .expected_rate = 275200000ULL,
>> +    .capabilities = {
>> +        .he_mcs_set = { HE_MCS_SET(MCS11, 1), MCS_UNSUP },
>> +        .he_phy_capa = { HE_PHY_CAPA(0x00) },
>> +        .iftypes = 1 << NETDEV_IFTYPE_STATION,
>> +    },
>> +    .he_capabilities = {
>> +        22, IE_TYPE_HE_CAPABILITIES - 256, HE_MAC_CAPA,
>> +        HE_PHY_CAPA(0x00), MCS_UNSUP, HE_MCS_SET(MCS11, 1)
>> +    },
>> +};
>>
>> This computes a rate of `25800000`, which I’m guessing corresponds to 
>> 25.8Mbps, perhaps? That’s fair I guess, since the only thing I really 
>> really changed in there compared to the other tests is the `MCS11` 
>> (that’s supported by AX201) and the `rssi`. There clearly are plenty 
>> of other fields that I should be filling in here, I feel, if I wanted 
>> to accurately represent my hardware.
>>
>> I think I managed to grab the capabilities of both the AP and the 
>> client using your instructions, but I’m really unclear on how to go 
>> from the output from `iwmon` to fields in this struct. My best guess 
>> right now is to actually run `iwd` under a gdb and place some 
>> breakpoints in the scanning code to extract the capabilities. Would 
>> that make sense, or is there a better way to fill in these fields?
>>
>> (As I’m writing this mail, I realize now that I probably want to 
>> somehow specify NSS=2 for `2x2` MIMO…?)
>>
>> Another thing that confuses me a great deal is the fact that the scan 
>> results with my APs don’t actually show any of the HE capabilities, 
>> only the HT and VHT ones (see attached sample from the `iwmon` 
>> output.) I also tried scanning an Android hotspot on a reasonably 
>> recent phone, and although the set of MCS supported were different, 
>> the output still contains only HT and VHT capabilities. I would love 
>> to attach my pcap here, but unfortunately I also have no clue how to 
>> sanitize it, so I’m going to attach an excerpt from `iwmon`’s output 
>> for the time being. Is this expected, or could this perhaps be at 
>> least part of the problem I’m seeing? Is it possible that an AP could 
>> not advertise HE capabilities at scan time, but for HE to still be 
>> used after authentication occurs?
> 
> Looks like iwmon doesn't actually print out the HE element, but that 
> doesn't explain the same behavior on the android device. If your more 
> comfortable you could send the pcap just to Me or Denis.
> 
> But as Denis pointed out maybe this needs another look as far as signal 
> strength any usability. The difficult part is one card could perform 
> much better at -85dbm than another. I'll take a closer look and see if 
> something got missed in the spec and do some testing myself (I think I 
> have an ax201, and definitely an ax210).

FWIW, my 802.11ax mesh APs I have at home don't advertise the HE element 
either.

> 
> Thanks,
> James
> 
>>
>> Thank you,
>> S.

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

[Denis Kenzior]

Hi Simonas,

>>
>> Me or James can walk you through all this if needed.
> 
> Thanks for offering. I have cracked open the file, and just started playing 
> around by adding a new `he_test_data` structure. Alas, I’m really hazy on what I 
> ought to be filing into the `capabilities` and `he_capabilities` fields. My 
> initial guess is something like this, based on one of the other tests around:
> 
> +/* 5GHz, 40MHz, MCS 11, NSS 1 */
> +const struct he_test_data he_test_5_40mhz_mcs_5_nss_1 = {
> +    .freq = BAND_FREQ_5_GHZ,
> +    .rssi = -76,
> +    .expected_rate = 275200000ULL,
> +    .capabilities = {
> +        .he_mcs_set = { HE_MCS_SET(MCS11, 1), MCS_UNSUP },
> +        .he_phy_capa = { HE_PHY_CAPA(0x00) },
> +        .iftypes = 1 << NETDEV_IFTYPE_STATION,
> +    },
> +    .he_capabilities = {
> +        22, IE_TYPE_HE_CAPABILITIES - 256, HE_MAC_CAPA,
> +        HE_PHY_CAPA(0x00), MCS_UNSUP, HE_MCS_SET(MCS11, 1)
> +    },
> +};
> 
> This computes a rate of `25800000`, which I’m guessing corresponds to 25.8Mbps, 

Yes, sounds about right.  This is for a single NSS.  If NSS==2, then use 
HE_MCS_SET(MCS11, 2)

> perhaps? That’s fair I guess, since the only thing I really really changed in 
> there compared to the other tests is the `MCS11` (that’s supported by AX201) and 
> the `rssi`. There clearly are plenty of other fields that I should be filling in 
> here, I feel, if I wanted to accurately represent my hardware.

Right.  Easiest is to look at this with wireshark or iwmon:
https://rowelldionicio.com/identifying-802-11ax-support-wireshark/

> 
> I think I managed to grab the capabilities of both the AP and the client using 
> your instructions, but I’m really unclear on how to go from the output from 
> `iwmon` to fields in this struct. My best guess right now is to actually run 
> `iwd` under a gdb and place some breakpoints in the scanning code to extract the 
> capabilities. Would that make sense, or is there a better way to fill in these 
> fields?

Having the IE format from the spec would be easiest, but I can't find a public 
reference just now.

> 
> (As I’m writing this mail, I realize now that I probably want to somehow specify 
> NSS=2 for `2x2` MIMO…?)
> 

Yes.

> Another thing that confuses me a great deal is the fact that the scan results 
> with my APs don’t actually show any of the HE capabilities, only the HT and VHT 

Hmm, that would explain the low estimate.

> ones (see attached sample from the `iwmon` output.) I also tried scanning an 
> Android hotspot on a reasonably recent phone, and although the set of MCS 
> supported were different, the output still contains only HT and VHT 
> capabilities. I would love to attach my pcap here, but unfortunately I also have 
> no clue how to sanitize it, so I’m going to attach an excerpt from `iwmon`’s 
> output for the time being. Is this expected, or could this perhaps be at least 
> part of the problem I’m seeing? Is it possible that an AP could not advertise HE 
> capabilities at scan time, but for HE to still be used after authentication occurs?

Yes, HE Capabilities would be included during Association, so this indeed could 
happen.

Regards,
-Denis

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

[Denis Kenzior]

Hi James,

> 
> FWIW, my 802.11ax mesh APs I have at home don't advertise the HE element either.
> 

I wonder if this is a bug?

According to 9.3.3.2 Beacon frame format:
"The HE Capabilities element is present if dot11HEOptionImplemented is true; 
otherwise, it is not present."

Regards,
-Denis

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

[Simonas Kazlauskas]

James,

Thank you for implementing the display of HE capabilities in `iwmon` – these do 
indeed show up in my scans now, false alert there.

> HE Capabilities: len 34
>     HE supported channel width set: bit  1: 40MHz/80MHz supported (5GHz/6GHz)
>         Rx HE-MCS Map <= 80MHz 1 Streams: MCS 0-11 supported
>         Rx HE-MCS Map <= 80MHz 2 Streams: MCS 0-11 supported
>         Rx HE-MCS Map <= 80MHz 3 Streams: MCS 0-11 supported
>         Rx HE-MCS Map <= 80MHz 4 Streams: MCS 0-11 supported
>         Tx HE-MCS Map <= 80MHz 1 Streams: MCS 0-11 supported
>         Tx HE-MCS Map <= 80MHz 2 Streams: MCS 0-11 supported
>         Tx HE-MCS Map <= 80MHz 3 Streams: MCS 0-11 supported
>         Tx HE-MCS Map <= 80MHz 4 Streams: MCS 0-11 supported
>     0d 01 08 9a 40 10 04 60 48 88 1f 43 81 1c 11 08  ....@..`H..C....
>     00 aa ff aa ff 7b 1c c7 71 1c c7 71 1c c7 71 1c  .....{..q..q..q.
>     c7 71                                            .q             

I’ve sent you and Denis both the pcap of the scan. I, unforunately, don’t think 
I’ll be able to hack on the test and/or data rate investigation much further 
before the weekend, but I’m happy to test out patches and such at any time.

Thanks,
S.

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

[Simonas Kazlauskas]

[-- Attachment #1: Type: text/plain, Size: 3107 bytes --]

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.)

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.

[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).

I’m not sure if this stellar MCS behaviour is Ubiquiti’s doing something fancy, 
or if its a result of those aforementioned thick walls, which *also* happen to 
block out any interference from the neighbours as well (making my APs literally 
the only transmitter in the 5GHz band devices bother noticing…) 

I have no clue if there’s anything actionable here, but I’m happy to help with 
testing the observed behaviour at various signal strengths if coming up with a 
better `ht_vht_he_base_rssi` table is… on the table :)

Have a great weekend,
S.

Simonas Kazlauskas wrote:
>James,
>
>Thank you for implementing the display of HE capabilities in `iwmon` – 
>these do indeed show up in my scans now, false alert there.
>
>>HE Capabilities: len 34
>>    HE supported channel width set: bit  1: 40MHz/80MHz supported (5GHz/6GHz)
>>        Rx HE-MCS Map <= 80MHz 1 Streams: MCS 0-11 supported
>>        Rx HE-MCS Map <= 80MHz 2 Streams: MCS 0-11 supported
>>        Rx HE-MCS Map <= 80MHz 3 Streams: MCS 0-11 supported
>>        Rx HE-MCS Map <= 80MHz 4 Streams: MCS 0-11 supported
>>        Tx HE-MCS Map <= 80MHz 1 Streams: MCS 0-11 supported
>>        Tx HE-MCS Map <= 80MHz 2 Streams: MCS 0-11 supported
>>        Tx HE-MCS Map <= 80MHz 3 Streams: MCS 0-11 supported
>>        Tx HE-MCS Map <= 80MHz 4 Streams: MCS 0-11 supported
>>    0d 01 08 9a 40 10 04 60 48 88 1f 43 81 1c 11 08  ....@..`H..C....
>>    00 aa ff aa ff 7b 1c c7 71 1c c7 71 1c c7 71 1c  .....{..q..q..q.
>>    c7 71                                            .q
>
>I’ve sent you and Denis both the pcap of the scan. I, unforunately, 
>don’t think I’ll be able to hack on the test and/or data rate 
>investigation much further before the weekend, but I’m happy to test 
>out patches and such at any time.
>
>Thanks,
>S.

[-- Attachment #2: 0001-test-band-HE-band-test-with-real-world-capabilities.patch --]
[-- Type: text/plain, Size: 2590 bytes --]

From 6961629e93d9e74f5760c5be00393459ad55c0b5 Mon Sep 17 00:00:00 2001
From: Simonas Kazlauskas <git@kazlauskas.me>
Date: Sun, 22 Oct 2023 00:46:38 +0300
Subject: [PATCH] test-band: HE band test with real-world capabilities
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

I've been observing that the rate estimations in the real world usage
end up being quite a bit different from the rates that end up being used
after the association. In this commit I’m adding a test case with the
capabilities from two physical devices, if only to demonstrate the
how the rate estimation behaves in such circumstances.
---
 unit/test-band.c | 29 ++++++++++++++++++++++++++++-
 1 file changed, 28 insertions(+), 1 deletion(-)

diff --git a/unit/test-band.c b/unit/test-band.c
index e27531f7..fec09e61 100644
--- a/unit/test-band.c
+++ b/unit/test-band.c
@@ -294,7 +294,7 @@ struct he_test_data {
 	/* Own capabilities */
 	struct band_he_capabilities capabilities;
 	/* Peer HE Capabilities IE */
-	uint8_t he_capabilities[31];
+	uint8_t he_capabilities[36];
 
 };
 
@@ -366,6 +366,31 @@ const struct he_test_data he_test_5_20mhz_mcs_7_nss_1 = {
 	},
 };
 
+/* 5GHz, 40MHz With data from a real-world Unifi’s U6 Enterprise AP and a client
+ * with the Intel AX201 card.
+ */
+const struct he_test_data he_test_5_40mhz_unifi_ap_and_ax201 = {
+	.freq = BAND_FREQ_5_GHZ,
+	.rssi = -76,
+	// In practice seems to be more like 275_200_000ULL instead...
+	.expected_rate = 72000000ULL,
+	.capabilities = {
+		.he_mcs_set = {
+			HE_MCS_SET(MCS11, 2), HE_MCS_SET(MCS11, 1), MCS_UNSUP
+		},
+		.he_phy_capa = {
+			0x0e, 0x3f, 0x0e, 0x09, 0xfd, 0x09, 0x8c, 0x16, 0x0f, 0xf0, 0x01
+		},
+		.iftypes = 1 << NETDEV_IFTYPE_STATION,
+	},
+	.he_capabilities = {
+		0x22, IE_TYPE_HE_CAPABILITIES - 256,
+		0x0d, 0x01, 0x08, 0x9a, 0x40, 0x10, 0x04, 0x60, 0x48, 0x88, 0x1f, 0x43,
+		0x81, 0x1c, 0x11, 0x08, 0x00, 0xaa, 0xff, 0xaa, 0xff, 0x7b, 0x1c, 0xc7,
+		0x71, 0x1c, 0xc7, 0x71, 0x1c, 0xc7, 0x71, 0x1c, 0xc7, 0x71,
+	},
+};
+
 /* 5GHz, 80MHz, MCS 7, NSS 1 */
 const struct he_test_data he_test_5_80mhz_mcs_7_nss_1 = {
 	.freq = BAND_FREQ_5_GHZ,
@@ -698,6 +723,8 @@ int main(int argc, char *argv[])
 					&he_all_mcs_unsupported);
 	l_test_add("/band/HE/test/low RSSI", band_test_he,
 					&he_test_5_low_rssi);
+	l_test_add("/band/HE/test/5GHz/40MHz/Unifi+AX201", band_test_he,
+					&he_test_5_40mhz_unifi_ap_and_ax201);
 
 	l_test_add("/band/oci2freq 1", test_oci2freq, &oci2freq_data_1);
 	l_test_add("/band/oci2freq 2", test_oci2freq, &oci2freq_data_2);
-- 
2.41.0

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

[Denis Kenzior]

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

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

[James Prestwood]

Hi Denis/Simonas,

> 
> 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.

Trying to catalog different hardware performance and act on it for 
ranking is an impossible task :)

The only simple solution I can think of would be to add a user-option 
for some threshold RSSI in the rate calculation. If set and the RSSI is 
below the lowest of ht_vht_he_base_rssi just use the last index (-82) 
(and maybe force a 20MHz channel width?). This would at least let the 
rate logic return _something_, albeit maybe not accurate. But again, 
those RSSI thresholds were sorta made up anyways :)

So you could set:
[Rank].LowSignalRateThreshold=-90

Any RSSI between -82 and -90 would use -82 for the rank calculation. No 
idea how this would play out in practice, but its at least simple and 
not tied to any given hardware.

Thanks,
James

> 
> Regards,
> -Denis

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

[Denis Kenzior]

Hi James,

On 10/24/23 07:32, James Prestwood wrote:
> Hi Denis/Simonas,
> 
>>
>> 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.
> 
> Trying to catalog different hardware performance and act on it for ranking is an 
> impossible task :)

We can actually have our own hwdb of sorts for this.  Hardware sensitivity is a 
differentiator (think marketing), so should be fairly easy to find.  Also, it 
doesn't have to be absolutely perfect, just reflect the hw capability a bit more 
closely.

> 
> The only simple solution I can think of would be to add a user-option for some 
> threshold RSSI in the rate calculation. If set and the RSSI is below the lowest 
> of ht_vht_he_base_rssi just use the last index (-82) (and maybe force a 20MHz 
> channel width?). This would at least let the rate logic return _something_, 
> albeit maybe not accurate. But again, those RSSI thresholds were sorta made up 
> anyways :)

They are not made up, they're direct from 802.11.  But again, they're the 
_minimum_ specified sensitivity.  Hardware typically does better.

> 
> So you could set:
> [Rank].LowSignalRateThreshold=-90
> 
> Any RSSI between -82 and -90 would use -82 for the rank calculation. No idea how 
> this would play out in practice, but its at least simple and not tied to any 
> given hardware.

No, I was more thinking about:
/* Added to the rssi value prior to looking up in the ht_vht_he_base_rssi */
SensitivityFudgeFactor=4
/* Width penalty */
SensitivityWidthPenalty=0 (3 today)
/* NSS penalty */
SensitivityNSSPenalty=3
/* Same as SensitivityFudgeFactor, but for HE */
SensitivityHEFudgeFactor=10

Regards,
-Denis

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

[James Prestwood]

Hi Simonas,

On 10/24/23 7:26 AM, Denis Kenzior wrote:
> Hi James,
> 
> On 10/24/23 07:32, James Prestwood wrote:
>> Hi Denis/Simonas,
>>
>>>
>>> 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.
>>
>> Trying to catalog different hardware performance and act on it for 
>> ranking is an impossible task :)
> 
> We can actually have our own hwdb of sorts for this.  Hardware 
> sensitivity is a differentiator (think marketing), so should be fairly 
> easy to find.  Also, it doesn't have to be absolutely perfect, just 
> reflect the hw capability a bit more closely.

I shouldn't have said impossible, just quite an undertaking. It would 
rely near 100% on community support to add various cards, in addition to 
the "hwdb" framework being committed to the project. But we're open to 
contributions!

> 
>>
>> The only simple solution I can think of would be to add a user-option 
>> for some threshold RSSI in the rate calculation. If set and the RSSI 
>> is below the lowest of ht_vht_he_base_rssi just use the last index 
>> (-82) (and maybe force a 20MHz channel width?). This would at least 
>> let the rate logic return _something_, albeit maybe not accurate. But 
>> again, those RSSI thresholds were sorta made up anyways :)
> 
> They are not made up, they're direct from 802.11.  But again, they're 
> the _minimum_ specified sensitivity.  Hardware typically does better.

The rates/MCS table (ht_vht_rates) is from 802.11, but the mapping from 
RSSI to MCS index's (ht_vht_he_base_rssi) is not. The spec just has a 
formula for calculating the rate using a given MCS/channel width. IWD 
just chooses what it thinks the MCS will be for a given RSSI.

I don't remember exactly where I got those values from but this seems to 
match:

https://wlanprofessionals.com/mcs-table-and-how-to-use-it/

So ultimately its a bit "hand-wavy" but so far has served us pretty 
well. Whats happening in your case is the RSSI is below the lowest 
threshold so its not calculating a rate for HT/VHT/HE (at least I think 
thats whats happening). So my idea is we just force it to use the lowest 
MCS if some threshold is set. That will calculate _something_ at least 
rather than failing.

> 
>>
>> So you could set:
>> [Rank].LowSignalRateThreshold=-90
>>
>> Any RSSI between -82 and -90 would use -82 for the rank calculation. 
>> No idea how this would play out in practice, but its at least simple 
>> and not tied to any given hardware.
> 
> No, I was more thinking about:
> /* Added to the rssi value prior to looking up in the 
> ht_vht_he_base_rssi */
> SensitivityFudgeFactor=4
> /* Width penalty */
> SensitivityWidthPenalty=0 (3 today)
> /* NSS penalty */
> SensitivityNSSPenalty=3
> /* Same as SensitivityFudgeFactor, but for HE */
> SensitivityHEFudgeFactor=10
> 
> Regards,
> -Denis

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

[Simonas Kazlauskas]

Denis Kenzior wrote:
>On 10/24/23 07:32, James Prestwood wrote:
>>So you could set:
>>[Rank].LowSignalRateThreshold=-90
>>
>>Any RSSI between -82 and -90 would use -82 for the rank calculation. 
>>No idea how this would play out in practice, but its at least simple 
>>and not tied to any given hardware.
>
>No, I was more thinking about:
>/* Added to the rssi value prior to looking up in the ht_vht_he_base_rssi */
>SensitivityFudgeFactor=4
>/* Width penalty */
>SensitivityWidthPenalty=0 (3 today)
>/* NSS penalty */
>SensitivityNSSPenalty=3
>/* Same as SensitivityFudgeFactor, but for HE */
>SensitivityHEFudgeFactor=10

My main worry then would be finding good defaults for these values. Ultimately, 
unless `iwd` ends up in a place where people install it and get a great 
experience in anything that involves ranking (roaming, initial association, 
etc.), the WiFi experience on Linux may have a hard time shaking off its stigma. 
If many has to modify some config variables to get a good experience, the 
experience will continue staying subpar for the large majority still. Although 
having the knobs will at least enable a minority to extract a reasonably good 
experience.

What worries me in parituclar here is that if we tune these defaults too high 
(i.e. estimate rate better than it might end up being in practice) then we might 
end up associating with the AP that is too far away/weak to provide a 
serviceable connection.

I wonder if there’s any place in here for some dynamic component that would 
monitor how the NSS, MCS and other bandwidth affecting parameters behave for a 
given SSID/BSSID/etc. as the RSSI varies, and transparently learn these 
parameters throughout a… session (is that a term?) That way even if the 
estimation for the very first association is too pessimistic, `iwd` can do 
better when it needs to estimate again for e.g. a romaing decision or a new 
association after a sleep.

With such a scheme in place “training” IWD would also be pretty easy to explain 
to the users (walk around the area with your device connected to the network) if 
they encountered problems with a particular AP.

S.

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

[Denis Kenzior]

Hi Simonas,

On 10/24/23 10:19, Simonas Kazlauskas wrote:
> Denis Kenzior wrote:
>> On 10/24/23 07:32, James Prestwood wrote:
>>> So you could set:
>>> [Rank].LowSignalRateThreshold=-90
>>>
>>> Any RSSI between -82 and -90 would use -82 for the rank calculation. No idea 
>>> how this would play out in practice, but its at least simple and not tied to 
>>> any given hardware.
>>
>> No, I was more thinking about:
>> /* Added to the rssi value prior to looking up in the ht_vht_he_base_rssi */
>> SensitivityFudgeFactor=4
>> /* Width penalty */
>> SensitivityWidthPenalty=0 (3 today)
>> /* NSS penalty */
>> SensitivityNSSPenalty=3
>> /* Same as SensitivityFudgeFactor, but for HE */
>> SensitivityHEFudgeFactor=10
> 
> My main worry then would be finding good defaults for these values. Ultimately, 
> unless `iwd` ends up in a place where people install it and get a great 
> experience in anything that involves ranking (roaming, initial association, 
> etc.), the WiFi experience on Linux may have a hard time shaking off its stigma. 
> If many has to modify some config variables to get a good experience, the 
> experience will continue staying subpar for the large majority still. Although 
> having the knobs will at least enable a minority to extract a reasonably good 
> experience.

Well, WiFi on Linux is plain terrible.  iwd tries to make it better, but 
ultimately we're down to only two people.  There's only so much that can be 
done.  The goal here was to describe the parameters we could use to 'tweak' the 
current calculation.  These can then be stored per vid/pid/driver or whatever 
and added onto over time.  If the parameters are not provided, then fall back to 
the (very pessimistic) calculation we use now.  Still better than what we used 
to have.

> 
> What worries me in parituclar here is that if we tune these defaults too high 
> (i.e. estimate rate better than it might end up being in practice) then we might 
> end up associating with the AP that is too far away/weak to provide a 
> serviceable connection.
> 
> I wonder if there’s any place in here for some dynamic component that would 
> monitor how the NSS, MCS and other bandwidth affecting parameters behave for a 
> given SSID/BSSID/etc. as the RSSI varies, and transparently learn these 
> parameters throughout a… session (is that a term?) That way even if the 
> estimation for the very first association is too pessimistic, `iwd` can do 
> better when it needs to estimate again for e.g. a romaing decision or a new 
> association after a sleep.
> 
> With such a scheme in place “training” IWD would also be pretty easy to explain 
> to the users (walk around the area with your device connected to the network) if 
> they encountered problems with a particular AP.
> 

Patches are always welcome.  ML isn't my area of expertise, so I can't really 
help here.

Regards,
-Denis

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

[Denis Kenzior]

Hi James,

>>
>> They are not made up, they're direct from 802.11.  But again, they're the 
>> _minimum_ specified sensitivity.  Hardware typically does better.
> 
> The rates/MCS table (ht_vht_rates) is from 802.11, but the mapping from RSSI to 
> MCS index's (ht_vht_he_base_rssi) is not. The spec just has a formula for 
> calculating the rate using a given MCS/channel width. IWD just chooses what it 
> thinks the MCS will be for a given RSSI.

Sheesh!  Everything is directly from 802.11.

80211-2020.pdf, page 2835, Table 17-18.
80211ax-2021.pdf, page 642, Table 27-51

> 
> I don't remember exactly where I got those values from but this seems to match:
> 

The spec?

Regards,
-Denis

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

[James Prestwood]

On 10/24/23 8:32 AM, Denis Kenzior wrote:
> Hi James,
> 
>>>
>>> They are not made up, they're direct from 802.11.  But again, they're 
>>> the _minimum_ specified sensitivity.  Hardware typically does better.
>>
>> The rates/MCS table (ht_vht_rates) is from 802.11, but the mapping 
>> from RSSI to MCS index's (ht_vht_he_base_rssi) is not. The spec just 
>> has a formula for calculating the rate using a given MCS/channel 
>> width. IWD just chooses what it thinks the MCS will be for a given RSSI.
> 
> Sheesh!  Everything is directly from 802.11.
> 
> 80211-2020.pdf, page 2835, Table 17-18.
> 80211ax-2021.pdf, page 642, Table 27-51

Apparently wherever I got them from, got them from the spec. IIRC I 
couldn't find such tables when I was doing this, and found something 
online. Hence why I left this comment:

  * Note: The values here are not based on anything from 802.11 but data
  *       found elsewhere online (presumably from testing, we hope). The two
  *       indexes for HE (MCS 11/12) are not based on any data, but just
  *       increased by 3dB compared to the previous value. We consider 
this good
  *       enough for its purpose to estimate the date rate for network/BSS
  *       preference.

I suppose this can be removed now since they did in fact come from the spec.

> 
>>
>> I don't remember exactly where I got those values from but this seems 
>> to match:
>>
> 
> The spec?
> 
> Regards,
> -Denis