I am having an issue, I titled this because I noticed the slow wireless perf in Fedora 36 as well, but I didnt run this level of test. I need to run Debian anyway so these tests were run on the gen 12 with these specs; if you look at the iperf3 results below, you can clearly see that the >10 year old Dell Latitude running the same OS is clearly faster over wifi. I installed with the back port kernel 5.18 but I am not sure where to go next.
My 5G connection drops to 2MiB/s after a while . I need to sudo systemctl restart netctl-auto@wlp166s0.service to restore the speed. Haven’t figured out the reason.
I’m having a similar issue on an 11th gen setup. Fedora 36, fully updated. When doing a simple test on speedtest.net, I get well over 20 Mbits/sec on my several year old Android phone as well as an older Macbook Pro. However, my Framework laptop with Fedora 36 yields about 5-7 Mbits/sec, despite reboots. Any suggestions from the community or Framework folks would be wonderful as I have an exam coming up soon and really need the bandwidth.
The problem only happens when I connect to my Dell D6000 docking station (via the USB-C connector). Unplugged, I get full download speed from speedtest.net like all my other devices. Plugged in, it immediately degrades to a half to a quarter of the download speed.
I’ll do some more testing and post here. @James_Ruddy, are you using a docking station?
Connecting my external monitor (LG 32UN650-W) to my USB-C expansion card on my Framework laptop (11th gen Intel) with AX210 using a Silkland USB-C to Displayport 6.6ft cable (Amazon.com) with nothing else connected to my laptop (not even a power cable), caused my Wifi to drop completely in Fedora 36 (the little wireless icon on the desktop system try disappeared and iw dev wlp170s0 link returned “Not connected”).
So I disconnected the USB-C to Displayport cable and reconnected. This time, the wifi stayed connected, but doing a speed test dropped the download speed to around 1 Mbit/sec. Trying again on a server that is owned by my ISP yielded an even slower download speed of about 500 Kbit/sec.
I have no idea how this is happening.
More testing to come…
I have no idea what would cause such a thing.
EDIT:
Disconnected everything, re-added the docking station with nothing connected to it, tested, and then kept adding peripherals one at a time. Hardly a scientific test, but so far, it seems like when anything is connected to the laptop (aside from the original Framework supplied power cable), the wifi performance degrades considerably. The USB-C expansion card connected to a high resolution external monitor causes it to disconnect at times, and if it manages to stay connected, the performance is 90+% decreased.
I’m wondering if this is some kind of PCIe throughput / prioritization issue? In the " 1TB expansion card disconnects randomly" topic, @Danny_Goff does some PCIe math and I wonder if this is related to that? I was thinking maybe a power consumption issue of some sort, but the monitor and docking station have their own power supplies. When the docking station is connected to the USB-C expansion card of the Framework laptop, it supplied the Framework laptop power (the docking station has its own AC power supply).
I’ll keep testing, but so far, it seems like throughput is being taken away from the the AX210 when other peripherals are connected.
@Alexis Yes I was using a thunderbolt dock, so with the added information I ran a couple tests, I wanted to add results from speedtest-cli from my server, but its giving me issues finding my ISPs server. I reliably get greater than 900mb up and down on my fiber. Here are the results from testing with and without the dock; One item to note is the last test, when I moved to the living room about 10ft from the AP.
thunderbolt dock wifi
17.29 down
41.33 up
undocked wifi
30.38 down
110.73 up
undocked pluggable 2.5gb usb ethernet
304.31 down
878.53 up
undocked wifi 10ft from accesspoint
155.56 down
305.62 up
@Fraoch - interesting theory. What’s odd is the on-battery laptop <-> USB-C expansion card <-> USB-C to Displayport cable <-> Monitor scenario vs. the other (e.g. dock only, dock + peripheral, etc.) scenarios. The “on-battery direct to monitor” scenario almost completely annihilates the Wifi performance and in once case just killed it all together. I also do not have any electrical engineering experience, but if the ground were being “defeated”, you’d think it’d be all or nothing when something was connected to the laptop (i.e. you’d get a similar outcome with the dock or the monitor, rather than varying degrees of signal loss).
Perhaps it’s more like interference and the effectiveness of the ground is being reduced at some scale depending on what’s connected and how it interacts with the ground of the laptop?
Would be interesting to get more samples from other people to see if it’s affecting the community at large.
Deleting my previous post, because it was incorrect.
The issue appears to be the position of the laptop lid. If it’s closed, wifi performance degrades significantly. If it’s open, speed is 100%. I did 10 tests, switching only between an open and closed lid and keeping all other factors the same.
I’ll keep an eye on it and test periodically to make sure this is in fact correct. I believe with all of my previous tests, when I operated the laptop with the the battery only (and wifi worked normally) I naturally had the lid of the laptop open. And, naturally, closed the lid when I connected it to the dock / monitor. I skewed my own testing by not keeping all test factors the same
Hopefully others can chime in with their own testing (speedtest numbers with lid open/closed), and once confirmed, and assuming this is related to the wifi antenna, we can come up with a solution to retaining performance while the lid is closed.
I’m actually seeing the same thing, on a framework AMD 13. I close the lid while docked (I’ve instructed systemd to not suspend in this case), and my wifi becomes unusable. I don’t have to do any exact measurements to show a “degradation” — the difference is night and day.
After googling, my guess is that it might be relate to the chassis blocking the signal. Alternatively, it might that the BIOS is trying to put the wifi module in low power mode — not entirely unlikely, since GPU heavy games also seem to react to lid events, even with HandleLidSwitchDocked=ignore added to /etc/systemd/logind.conf.
In any case, it would be nice to know the actual root cause. Perhaps starting a new thread about this specific issue will help in getting it some attention?
Multiple non-tested distros mentioned here, so I will share the following:
Please file a bug report against your affected distro.
Keep it simple with testing, ie; no docks in tests.
If something is happening on tested/officially supported distros, please open a support ticket against Fedora 39 or Ubuntu 22.04.3 OEM D kernel as shown in our guide.
Since my last post, I’ve since upgraded my WiFi access points and router, changed my internet service provider, as well as moved my office much closer to an access point. This has, for the most part, resolved the issue for me. I’m not a WiFi hardware expert, so take this with a grain of salt, but my guess is that the lid being closed attenuates the antenna in a way that reduces its effective distance such that signal degradation occurs earlier than if it were open. I could probably test this again by simply moving further away from the access point. I also have two Framework laptops (11th and 12th gen Intel). Let me know if you’d like me to test again.
I think the solution is to simply move closer to an access point if you have the lid closed. It’s not ideal or possible in all scenarios, and in that case, you can just leave the lid open (if possible). Aside from that, some sort of external antenna.
I’m on the latest version of Fedora on both laptops.
