I’ve had a good experience with both, however the AX210 definitely consumed a lot of power during idle.
The RZ616 did as well. However on Linux 6.8 it’s calm down and runs very efficiently now.
Bluetooth has been acceptable on both however I’ve only used them for Teams calls.
Weird, mine use barely any power at idle even when connected. During iperf the ax210 seems to use quite a bit less power but also did perform a bit worse on 80mhz wifi6, on 160mhz both saturate the gigabit uplink of the accesspoint.
As a brief update, I did a couple of experiments but the situation is still the same – horrible random lagging of wireless touchpad/keyboard when headphones are playing audio, and I don’t understand what is causing it and how to debug it.
On a related note, I have replaced PulseAudio with PipeWire (should have been using it from the beginning, not sure why NixOS doesn’t enable it by default) and this solved all the video/audio sync issues with both adapters.
I just swapped over to the AX210 and speeds are slower than the MediaTek - both the down and up link.
However, it did fix the issue I was experiencing with the MediaTek where it was knocking out my 5GHz radio on the AP (which drops all of my devices that was on that radio). With the Intel, this doesn’t happen.
This is very useful. I really want the RZ616 to work. But without any more useful information, I’ll be installing the AX210. I would love someone to talk me off that cliff. I see @Techie_Zeddie and several others went to the AX210 after having serious inconvenience and pain, which I can’t afford.
I’ll be on Arch with an entirely Ubiquiti Unifi WiFi network, with 5 access points of different types throughout my house, running in 2 Ghz and 5 Ghz mode on different channels, all on the same SSID. Can we say that RZ616 is probably going to give me pain?
I have both WiFi adapers and about a week before I’ll be assembling it. Really don’t want to go through pain and have to make time to break the system back down and replace the RZ616 with the AX210.
Matt’s directions in his replies in this thread may be helpful: [TRACKING] WiFi drops out (especially when downloading a lot) but fixes instantly by reconnecting (AMD) - #22
For reference, I have both cards - ax210 (oops! not ax201, ax210) and rx616 on 13" 11th gen Intel, and rz616 on 16" AMD, with an Asus router and mesh access points, running the merlin firmware, and all is well here. Yay me. Best of luck.
Super useful, @lbkNhubert , thanks. This makes me think I should keep the MediaTek. 
Please don’t make me hate my life, gods
Happy to help (I hope!) if and when I can. I have gotten and continue to get so much more from this community than I can give back, but I have to try to balance things out when I can. Have a great day!
Based on my experience, yes, absolutely. My setup is a two-level apartment with one 5Ghz AP on each of the floors. The TX powers on both are experimentally tuned so that one becomes stronger than the other as walk up/down the stairs, so the net result is that the devices that I have smoothly transfer in the middle of the staircase. The RZ616 though just refused to transfer and keeps clinging to the barely visible AP from the other floor even as I am at the furthest wall of the room, so I have to manually disconnect/connect the WiFi, which makes it associate to the stronger AP.
I’ve been going back and forth between the two adapters to experiment over the past couple of months. It takes like three minutes after you’ve done it for the second time, although yeah, the part where you disconnect and reconnect the antenna is a bit nerve-wracking, as the connectors are pretty delicate, so I would not recommend switching often, but I would not worry too much about having to do the switch once.
By the way, as far as my experiments go, I’ve started getting bad input lag (with headphones connected and watching a video) with the RZ616 as well, so not really sure what is going on at this point. Due to this I’ve decided to stick with the Intel adapter and just accept that my Bluetooth audio will suck and I would just have to play my background YouTube videos on the phone.
Thanks for chiming in again, @kirelagin. Isn’t the RZ616 the same one they’ve used in the Framework 13 since the beginning? 
The joys of Linux. Either buggy behind the times window managers with NVIDIA or buggy behind the times WiFi with AMD. Pick your poison.
Not kirelagin, but I can answer the question. The AX210 is what came with my 11th gen 13" machines. I swapped it in one of them for the rz616 as the 6e(?) band got disabled with a later kernel and requires a change in the bios to fix. The amd machines come with the rz616.
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.
iwd can be used as a replacement for wpa_supplicant in OSs that use NetworkManager (e.g. Fedora). It is supposed to be better at band selection with the BandModifier5Ghz config setting allowing for tuning its preferences.
I have very little experience with it myself, just started playing with it as time permits as part of a plan to have an automatic 2.4GHz fallback for the very occasional DFS (radar detection) false positive induced 1-minute drops of my main 5GHz WLAN. So pinch of salt etc.
I have used NetworkManager for a few years, now, so that’s useful confirmation. Hard decision ahead of me. I have both and could go either way, at this point.
Just to be clear, it’s only the wpa_supplicant back end that you’d have to switch to iwd (easy via 2 config lines). NM can stay as the general network config management front end.
Oh, damn. I’m totally using wpa_supplicant, didn’t realize NM was just a frontend. I will remember to use iwd. Looks like I should consider using it anyway, even on my current laptop. Thanks for the tip.
No worries. What I’ve found so far (on Fedora anyway) is that you want both of the settings described here In a file like /etc/NetworkManager/conf.d/99-use-iwd.conf:
[device]
wifi.backend=iwd
wifi.iwd.autoconnect=yes
i.e. let iwd handle the autoconnect decision (and further configure that in its global and/or network-specific config files if needed). As far as NM is concerned, I’ve left its autoconnect to yes.
I will definitely do that. Even the laptop I’m upgrading doesn’t pick the better AP sometimes.
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.
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
<...>
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)