[RESPONDED] Framework 13 AMD Linux slow WIFI

Today it way the first working day for my brand new Framework pc! Everything seems to work fine but I have this issues with being really slow on wifi.

As you can see the Macbook on the same location show a different speed.

Upon investigation I found:

So I’ve tried

sudo sed -i 's/wifi.powersave = 3/wifi.powersave = 2/' /etc/NetworkManager/conf.d/default-wifi-powersave-on.conf

but it dosent seem to work

Any suggestions?


SPECS:

  • Pop!_OS 22.04
  • Framework laptop AMD 13
1 Like

Hi @Fabrizio_Anichini

have a look here:

/herodot

1 Like

Welcome to the community!

Just a quick note, we do not test against Pop, we test against Ubuntu 22.04.3 and Fedora 39 using our install guides.

In looking at your details, you appear to be connecting to 5 GHz which is fine.

Let’s do this.

  • Test this again with a live USB of say, Fedora 39. It will closer match the “newness” of Pop, but will be with a tested distro. Despite missing the updates that come with a dnf update, it will be pretty close to what we might see with Pop.

  • Verify you’re on the latest BIOS - you should be on 3.03. Even running live, dnf should allows you to “install” the needed package to RAM for the live session.

  • If you are still seeing slow speeds, back on your Pop install, we could verify you’re set to the correct region with sudo iw reg get

  • Let’s also verify that your power save is actually off:

iw dev | awk '/Interface/{iface=$2} END{system("iw dev " iface " get power_save")}'
  • Which brand/model router are you connecting to? Is it wifi 6E or older?
1 Like

I’ve tried Fedora 39 and the network speed was good ( at least the same as my MacBook).

I also tried the pop shell and because now is fixed for gnome 45 now I have fedora 39 as main OS.

Probably I’ll try again running Pop when the new Cosmic will be release. In case I’ll refer to this thread as a guideline

Thanks,

Just making sure I am following, did you try the suggestions above? Appreciate you trying Fedora, but we also need to know if you’re on the correct BIOS and what the power save status is?

iw dev | awk '/Interface/{iface=$2} END{system("iw dev " iface " get power_save")}'

That said, certainly worth trying Pop to see if there is different behavior, but, the difference may be something that is a bug that needs to be reported for Fedora.

1 Like

Update: The update indicated here for the slow wifi with the mediatek card, is available on Fedora. Please make sure you are fully updated.

1 Like

I have the similar problems with latest Arch Linux.
I don’t see the connection dropping completely often, but the performance often degrades heavily to just 2-3MByte/s when copying a file from my NAS over a Wifi-6 connection (Wifi-5 works fine and achieves 70-80MB/s).

I have very recent firmware (probably the latest available?):

$ sudo dmesg | grep 792
[   22.949038] mt7921e 0000:01:00.0: ASIC revision: 79220010
[   23.030434] mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240716163242a
[   23.045935] mt7921e 0000:01:00.0: WM Firmware Version: ____000000, Build Time: 20240716163327

and also a very recent kernel:

$ uname --all
Linux spectre 6.10.10-arch1-1 #1 SMP PREEMPT_DYNAMIC Thu, 12 Sep 2024 17:21:02 +0000 x86_64 GNU/Linux

And I think the BIOS version is also the latest available, unless I missed an update:

$ sudo dmidecode -s bios-version
03.05

I’m seeing a lot of messages like this in journalctl:

Sep 17 04:42:45 spectre wpa_supplicant[2074]: wlan0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-50 noise=9999 txrate=1200900
Sep 17 04:42:48 spectre wpa_supplicant[2074]: wlan0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-41 noise=9999 txrate=1200900
Sep 17 04:42:51 spectre wpa_supplicant[2074]: wlan0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-42 noise=9999 txrate=960700
Sep 17 04:42:54 spectre wpa_supplicant[2074]: wlan0: CTRL-EVENT-SIGNAL-CHANGE above=1 signal=-38 noise=9999 txrate=960700

Not sure what this means exactly, but I guess noise=9999 isn’t good?
OTOH, I also get those messages when connected to a Wifi-5 AP, while copying with >80MB/s at 5GHz, so it might be irrelevant.

I noticed the following:

  • This only seems to happen with Wifi-6 Access Points (both with my recent-ish Fritz!Box Cable 6660 and a friend’s Netgear AP) - Wifi-5 APs seem to work fine and have good performance
  • As far as I can tell (from running watch -n1 iwconfig while testing) this only happens at 5GHz (Frequency:5.6 GHz or similar), at 2.4GHz it seems to be more stable and I get 30-40MB/s (which maybe isn’t super-great, but 10x as fast as what I get with 5GHz)
    • This means that the problem can appear resolved if a users current connection happens to use 2.4GHz
  • Usually (at 5GHz) the download or copying starts relatively fast (around 50MB/s or so) and then over time degrades to 2-4MB/s, even though iwconfig shows a high Bit Rate and good Link Quality

When I tested this with my Fritz!Box I was at most 2 meters away from it, without any obstacles in the way.

As this issue doesn’t appear fixable (or at least hasn’t been fixed by the driver developers despite being known for a long time now) I’d like to suggest that Framework starts putting Intel Wifi Cards (which AFAIK don’t have these problems) in the AMD laptops, at least as an option.

Update: By the way, I also tested disabling wifi powersave (sudo iw dev wlan0 set power_save off), it didn’t make a difference.

1 Like

FWIW, I’m experiencing the same, with near exact set up (noise=9999, WiFi 6 AP, Linux 6.11.0).

Firmware:

mt7921e 0000:01:00.0: HW/SW Version: 0x8a108a10, Build Time: 20240716163242a

20240716163242a is the latest.

Unsure why it’s loaded as mt7921e; it’s a RZ616/MT7922. mt7921 has its own firmware.

mt7921e is the name of the kernel module (driver), presumably it was initially written for the MT7921 and later extended for the MT7922.

Good to hear I’m not the only one who still experiences this bug :slight_smile:

1 Like

I guess we’re best reporting this to the mt76 maintainers and/or linux-firmware (although MT7922 on linux-firmware seems quiet (hi Matt :wave:)).

I don’t see anything to post bugreports there - the mediatek mailinglist only seems to be used to review patches?

I found a kernel bugzilla report that probably describes the same issue, but it didn’t get any replies (except from the original reporter with additional information) despite being open for a month now: 219173 – mt7921e very low WiFi speed

The page you linked also mentions an IRC channel, but doesn’t say what server it’s on :upside_down_face:

1 Like

FWIW, I added my info to that kernel bugzilla entry.

The IRC chan appears to be on OFTC, but so far I didn’t get much advice besides “try different firmware versions” and “in general, that radio works well for us in our testing”.

But I guess it might be helpful for them to know which APs this happens with. I described the ones I tested with in that kernel bugzilla entry, maybe other can document theirs as well (if you don’t have a kernel bugzilla account and don’t want to create one, answer here and I’ll post them there)

Thanks for raising it. My AP’s a Sagemcom F@st 3896, which has a Broadcom BCM3390 inside.

Thanks!
By the way, can you do tests with iperf3 between your laptop and another machine in your network, ideally connected by cable, in both directions (normal and with -R), and ideally for two to three minutes or so (-t 180 or -t 0 and then manually cancel it with ctrl-c after some time)?

In my setup, sending data from the laptop over Wifi-6 is relatively fast and stable (around 500Mbit/s on average, and mostly >450Mbit/s), but receiving data on the laptop is slower and the speed heavily fluctuates (down to sometimes 0 bits/second, average was around 90Mbit/s)

I recently got a Batch 3 Framework 13 AMD Ryzen 7040 laptop with the Mediatek WiFi module. I also happen to have a Framework 13 Intel laptop.

Wifi speeds seemed limited to 10mb/s on fast.com at best and <1mb/s when downloading off Steam. Previously I was getting at least 5mb/s on the Intel laptop in the same location.

I’ve read a lot of other threads on this and tried a lot of suggested fixes. One suggestion was to use the Intel AX210 (no vpro) WiFi module on the AMD laptop and that worked for some users but I still seem to have degraded WiFi.

Anyway I have both laptops and both Wifi cards on hand if people have suggestions for tests to do.

I’m using Arch and using iwctl directly (no NetworkManager installed).

The power_saving setting change seemed to have no effect.

EDIT:

$ sudo iwctl station wlan0 show
------------------------------------------------------------
Property              Value
------------------------------------------------------------
Scanning              no
State                 connected
Connected network     removed
IPv4 address          192.168.1.64
IPv6 address          removed
ConnectedBss          removed
Frequency             5180
Channel               36
Security              WPA2-Personal
RSSI                  -74 dBm
AverageRSSI           -78 dBm
RxMode                802.11ac
RxMCS                 2
TxMode                802.11ac
TxMCS                 3
TxBitrate             57800 Kbit/s
RxBitrate             45000 Kbit/s

Getting 20Mbps on my phone but only 3Mbps on the AMD Laptop with the AX210
And 802.11ac isn’t even Wifi6 as far as I know

1 Like

Just throwing in a data point (Intel 11th gen FL13, AX210): Fast.com over 5GHz 1ft away from the router (removing the distance variable), Ubuntu 24.04.1 LTS, kernel 6.8.0-44-generic, Edge v125.0.2535.92: Getting exactly 940Mbps.

Did you happen to test the suggestions from the Arch wiki:
Framework Laptop 13 - ArchWiki (the Wifi section)

So set the regulation domain and try with iwd?

I just switched to a ax210 card right away when i got the Laptop 13 as I have had so much issues with previous AMD advantage laptops with their Mediatek cards.

Yeah I set the reg with iw reg set IE and uncommented WIRELESS_REGDOM="IE" in /etc/conf.d/wireless-regdom.

I do notice however the device reports UNSET, not sure how or if I need to set it for the device also?

$ iw reg get
global
country IE: DFS-ETSI
	(2400 - 2483 @ 40), (N/A, 20), (N/A)
	(5150 - 5250 @ 80), (N/A, 23), (N/A), NO-OUTDOOR, AUTO-BW
	(5250 - 5350 @ 80), (N/A, 20), (0 ms), NO-OUTDOOR, DFS, AUTO-BW
	(5470 - 5725 @ 160), (N/A, 26), (0 ms), DFS
	(5725 - 5875 @ 80), (N/A, 13), (N/A)
	(5945 - 6425 @ 160), (N/A, 23), (N/A), NO-OUTDOOR
	(57000 - 66000 @ 2160), (N/A, 40), (N/A)

phy#0 (self-managed)
country 00: DFS-UNSET
	(2402 - 2437 @ 40), (6, 22), (N/A), AUTO-BW, NO-HT40MINUS, NO-80MHZ, NO-160MHZ
	(2422 - 2462 @ 40), (6, 22), (N/A), AUTO-BW, NO-80MHZ, NO-160MHZ
	(2447 - 2482 @ 40), (6, 22), (N/A), AUTO-BW, NO-HT40PLUS, NO-80MHZ, NO-160MHZ
	(5170 - 5190 @ 160), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-320MHZ, PASSIVE-SCAN
	(5190 - 5210 @ 160), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-320MHZ, PASSIVE-SCAN
	(5210 - 5230 @ 160), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-320MHZ, PASSIVE-SCAN
	(5230 - 5250 @ 160), (6, 22), (N/A), NO-OUTDOOR, AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-320MHZ, PASSIVE-SCAN
	(5250 - 5270 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-320MHZ, PASSIVE-SCAN
	(5270 - 5290 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-320MHZ, PASSIVE-SCAN
	(5290 - 5310 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-320MHZ, PASSIVE-SCAN
	(5310 - 5330 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-320MHZ, PASSIVE-SCAN
	(5490 - 5510 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-320MHZ, PASSIVE-SCAN
	(5510 - 5530 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-320MHZ, PASSIVE-SCAN
	(5530 - 5550 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-320MHZ, PASSIVE-SCAN
	(5550 - 5570 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-320MHZ, PASSIVE-SCAN
	(5570 - 5590 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-320MHZ, PASSIVE-SCAN
	(5590 - 5610 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-320MHZ, PASSIVE-SCAN
	(5610 - 5630 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-320MHZ, PASSIVE-SCAN
	(5630 - 5650 @ 160), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-320MHZ, PASSIVE-SCAN
	(5650 - 5670 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, NO-320MHZ, PASSIVE-SCAN
	(5670 - 5690 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, NO-320MHZ, PASSIVE-SCAN
	(5690 - 5710 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40MINUS, NO-160MHZ, NO-320MHZ, PASSIVE-SCAN
	(5710 - 5730 @ 80), (6, 22), (0 ms), DFS, AUTO-BW, NO-HT40PLUS, NO-160MHZ, NO-320MHZ, PASSIVE-SCAN
	(5735 - 5755 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, NO-320MHZ, PASSIVE-SCAN
	(5755 - 5775 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, NO-320MHZ, PASSIVE-SCAN
	(5775 - 5795 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-160MHZ, NO-320MHZ, PASSIVE-SCAN
	(5795 - 5815 @ 80), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40PLUS, NO-160MHZ, NO-320MHZ, PASSIVE-SCAN
	(5815 - 5835 @ 40), (6, 22), (N/A), AUTO-BW, IR-CONCURRENT, NO-HT40MINUS, NO-80MHZ, NO-160MHZ, NO-320MHZ, PASSIVE-SCAN

I’ve set regdom to GB in modprobe conf, but wpa_supplicant still reports as NL until I set it manually with iw. Anyone else seeing this?

$ cat /sys/module/cfg80211/parameters/ieee80211_regdom
GB

$ iw reg get
global
country NL: DFS-ETSI

wpa_supplicant[1320]: wlp1s0: CTRL-EVENT-SUBNET-STATUS-UPDATE status=0
wpa_supplicant[1320]: wlp1s0: CTRL-EVENT-REGDOM-CHANGE init=COUNTRY_IE type=COUNTRY alpha2=NL
wpa_supplicant[1320]: wlp1s0: Channel list changed: 6 GHz was enabled

I didn’t set the regdom as a kernel module parameter, but by uncommenting the corresponding line (WIRELESS_REGDOM="DE") in /etc/conf.d/wireless-regdom.
$ iw reg get returns country DE, as expected.


Furthermore, this problem somehow disappeared (just half a day before the AX210 I ordered for comparison arrived) - even though I didn’t change/update anything?!

TL;DR: Use wavemon instead of iwconfig or whatever to show connection information, that way you get the sending and receiving bitrates (even above 2GBit) and, maybe even more importantly, the current channel width, which should probably be 160MHz but might have been 40MHz before (though I’m not 100% sure about that).

More details:
The bitrate displayed by iwconfig increased from about 1Gbit to about 2Gbit (or some negative number because iwconfig doesn’t handle speeds above 2Gbit properly due to using a signed int32) and the receiving speed (on the laptop) according to iperf3 increased from an average of 90-100Mbit/s (with streaks of about 30Mbit and some seconds of 0, see above) to 250-350Mbit/s, and the sending speed increased from 650Mbit/s to about 800Mbit/s.

The AX210 achieves even more: About 300-400Mbit/s for receiving and 1.1Gbit/s for sending - so it’s a bit faster, but sending still is a lot faster than receiving, for whatever reason. That’s very weird, but apparently not specific to the MT7922.

I’m not 100% sure but I think that the channel width used to be 40MHz and now is 160MHz, which would probably explain the speedup and probably stability as well.
But I might misremember, because iwconfig doesn’t show the channel width so I only saw it occasionally when looking at my access points configuration UI.
Should’ve used wavemon right from the start…

However, I’m still not convinced that the problem was (is?) entirely with my setup (AP, local interference, whatever), because originally I ran into this at a friends place where copying files to my laptop was really slow, while it worked just fine with his laptop connected to the same AP, even when putting the laptops to the same positions… I’ll have to do more testing next time I visit him.

1 Like