Intel AX210 vs. AMD (MediaTek) RZ616 on an AMD Framework

[kirelagin]

@dimitris

Narrowly on the topic of the client selecting the “better” AP on Linux: As I understand it, the default (at least on Fedora) wpa_supplicant will indeed hold on to AP it was connected to for dear life even if a better one is available, whether in the same SSID or not. Hardware probably not playing much of a role here.

This could be a convincing explanation if it wouldn’t be switching perfectly with the Intel adapter.

Here is an extract from a wpa_supplicant log I have just captured with the Intel card, where you can see that it knows that the APs are the same network and decides to switch to the other AP, even though the estimated throughput of the previous one is still 11 Mbit/s, which I would’t call “holding for dear life” – it just sees that it is the same ESS, and it can do a 802.11r fast transition, and the throughput is going to be better, so it does.

wpa_supplicant log

nl80211: Event message available
nl80211: Ignored event 64 (NL80211_CMD_NOTIFY_CQM) for foreign interface (ifindex 2 wdev 0x0)
nl80211: Drv Event 64 (NL80211_CMD_NOTIFY_CQM) received for wlp1s0
nl80211: Connection quality monitor event: RSSI low
nl80211: Signal: -76 dBm  txrate: 866700
nl80211: Noise: 9999 dBm
wlp1s0: Event SIGNAL_CHANGE (24) received
wlp1s0: CTRL-EVENT-SIGNAL-CHANGE above=0 signal=-76 noise=9999 txrate=866700
bgscan simple: signal level changed (above=0 current_signal=-76 current_noise=9999 current_txrate=866700))
bgscan simple: Trigger immediate scan
bgscan simple: Request a background scan
wlp1s0: Add radio work 'scan'@0x91fa80
wlp1s0: First radio work item in the queue - schedule start immediately
wlp1s0: Starting radio work 'scan'@0x91fa80 after 0.000015 second wait
wlp1s0: nl80211: scan request
nl80211: Scan SSID kirNet
Scan requested (ret=0) - scan timeout 30 seconds
nl80211: Event message available
nl80211: Ignored event 33 (NL80211_CMD_TRIGGER_SCAN) for foreign interface (ifindex 2 wdev 0x0)
nl80211: Drv Event 33 (NL80211_CMD_TRIGGER_SCAN) received for wlp1s0
wlp1s0: nl80211: Scan trigger
wlp1s0: Event SCAN_STARTED (47) received
wlp1s0: Own scan request started a scan in 0.000186 seconds
<...>
RTM_NEWLINK: ifi_index=2 ifname=wlp1s0 wext ifi_family=0 ifi_flags=0x11043 ([UP][RUNNING][LOWER_UP])
nl80211: Event message available
nl80211: Ignored event 34 (NL80211_CMD_NEW_SCAN_RESULTS) for foreign interface (ifindex 2 wdev 0x0)
nl80211: Drv Event 34 (NL80211_CMD_NEW_SCAN_RESULTS) received for wlp1s0
wlp1s0: nl80211: New scan results available
nl80211: Scan probed for SSID 'kirNet'
nl80211: Scan included frequencies: 2412 2417 2422 2427 2432 2437 2442 2447 2452 2457 2462 2467 2472 5180 5200 5220 5240 5260 5280 5300 5320 5500 5520 5540 5560 5580 5600 5620 5640 5660 5680 5700 5720 5745 5765 5785 5805 5825 5955 5975 5995 6015 6035 6055 6075 6095 6115 6135 6155 6175 6195 6215 6235 6255 6275 6295 6315 6335 6355 6375 6395 6415 6435 6455 6475 6495 6515 6535 6555 6575 6595 6615 6635 6655 6675 6695 6715 6735 6755 6775 6795 6815 6835 6855 6875 6895 6915 6935 6955 6975 6995 7015 7035 7055 7075 7095 7115
wlp1s0: Event SCAN_RESULTS (3) received
wlp1s0: Scan completed in 4.275842 seconds
nl80211: Received scan results (23 BSSes)
nl80211: Scan results indicate BSS status with 94:83:c4:06:d7:6d as associated
wlp1s0: BSS: Start scan result update 18
<...>
wlp1s0: Radio work 'scan'@0x91fa80 done in 4.281589 seconds
wlp1s0: radio_work_free('scan'@0x91fa80): num_active_works --> 0
wlp1s0: Scan results matching the currently selected network
wlp1s0: 0: 48:8f:5a:7d:b3:6f freq=5180 level=-41 snr=51 est_throughput=65000
wlp1s0: 7: 94:83:c4:06:d7:6c freq=2462 level=-76 snr=13 est_throughput=33000
wlp1s0: 17: 94:83:c4:06:d7:6d freq=5785 level=-89 snr=3 est_throughput=10988
wlp1s0: Selecting BSS from priority group 0
wlp1s0: 0: 48:8f:5a:7d:b3:6f ssid='kirNet' wpa_ie_len=0 rsn_ie_len=24 caps=0x1011 level=-41 freq=5180
wlp1s0:    selected based on RSN IE
wlp1s0:    selected BSS 48:8f:5a:7d:b3:6f ssid='kirNet'
wlp1s0: Considering within-ESS reassociation
wlp1s0: Current BSS: 94:83:c4:06:d7:6d freq=5785 level=-89 snr=3 est_throughput=10988
wlp1s0: Selected BSS: 48:8f:5a:7d:b3:6f freq=5180 level=-41 snr=51 est_throughput=65000
wlp1s0: Using signal poll values for the current BSS: level=-84 snr=8 est_throughput=29301
wlp1s0: Allow reassociation - selected BSS has better estimated throughput
wlp1s0: Considering connect request: reassociate: 0  selected: 48:8f:5a:7d:b3:6f  bssid: 94:83:c4:06:d7:6d  pending: 00:00:00:00:00:00  wpa_state: COMPLETED  ssid=0x94a350  current_ssid=0x94a350
wlp1s0: Request association with 48:8f:5a:7d:b3:6f
wlp1s0: Re-association to the same ESS
<...>

[dimitris]

Interesting. I’m not sure what the division of responsibility between hardware, the driver, and the OS/userspace client stack is for AP transitions.

Your log shows a transition triggered by low signal level. Presumably on the Mediatek the same doesn’t happen, even after a longer wait time? I have noticed that the Mediatek card seems to take longer to scan, maybe (especially?) on 5GHz, so that could be playing into how long it takes it to “find” the better alternative. Of course if that’s “never” then it’s no good and potentially a Mediatek firmware or driver issue.

My intended use case is slightly different. I have a single wireless router where both the 2.4GHz and 5GHz access points live, and signal strength is ok throughout the fairly small area I’m interested in. I just want to skew the client’s preference very heavily towards the 5GHz AP while still being able to fall back to 2.4GHz quickly in the rare occasions where 5GHz drops temporarily (radar detection).

That’s where I assume (from what I’m reading out there) that iwd could make a difference by being more “proactive” and tunable in its band preference.

(more edit: I’m aware of band steering as an option on the AP, but I’d rather try solving this on the client first)

(more more edit: My Pixel 7 phone does the “right thing” and chooses the much faster 5GHz AP when it becomes available on the same SSID, even though both 5GHz and 2,4GHz have at least “good” RSSI)

[dimitris]

@dimitris

(more more edit: My Pixel 7 phone does the “right thing” and chooses the much faster 5GHz AP when it becomes available on the same SSID, even though both 5GHz and 2,4GHz have at least “good” RSSI)

On somewhat of a whim I re-enabled the 2.4GHz BSSID on my now dual-band access point. The APs are on the same Netgear WAX206 running OpenWrt 23.05.3. It’s dual-band just by virtue of using identical SSID and passphrase on both radios; 802.11{r,k} are not enabled. The 5GHz BSSID is on a clear (no other APs in scans) 80MHz channel. The 2.4GHz one is on a 20MHz channel with lots of neighbor noise. Speeds are predictably much higher on the 5GHz one.

I ran a couple of experiments and so far the default NetworkManager/wpa_supplicant combo does behave correctly:

• DFS “outage” simulation:

  • Drop the 5GHz AP. NM/wpa_supplicant “instantly” switches to the 2.4GHz AP.
  • Wait a while, then bring the 5GHz AP back (and wait another 1 minute for it to do its DFS scan).
  • The Pixel phone switches from 2.4GHz back to 5GHz “quickly”.
  • After roughly 3-4 minutes, so does NM/wpa_supplicant.

• Suspend/resume: “Correct” 5GHz AP picked up again.

I’ll keep an eye for a while to see how consistent this is, but for my use case and AP hardware the Mediatek card on Fedora 40 defaults seems to do alright.

[Melroy_van_den_Berg]

I’m also considering moving to Intel AX210 after 2 days of using my Framework 13 AMD. The download speeds are so slow on both 2.4Ghz and 5Ghz. Around 30-40Mb/s max, while the upload speeds are looking much better.

I easily get 100Mb/s with other devices in the same room, same access point, same speedtest test server. So I start blaming Mediatek MT7922 (just call it was it is, instead of “AMD RZ616” lol).