Librem 5 Wi-Fi performance

I don’t think any other WiFi card will work in the Librem5 since the Librem5 only provides a subset of the normal m.2 Interface with the most noticeable part of those interfaces the PCIe missing which AFAIK is used by most laptop WiFi card.
One of those two cards is using SDIO as the main interface and the other USB 2.0 but I’m not sure if it’s the WiFi or the modem card.
There might even be a chance of something getting damaged in the Phone if you change the card without checking the interface speck quite carefully for compatibility.

Ah, thanks!

I did tried plugging my Intel 3168NGW in, and I suspect there to be a lack of device driver, without realizing that the M.2 is lacking of PCIe interface. The WiFi interface is using SDIO and the LTE should be on the contrary.

Did support come back with anything helpful on this?

Although my service is nowhere near as fast as yours on the download, I’m seeing similar results in that the download speed on the Librem 5 is always notably lower than the upload.

Laptop (WiFi) 68~74Mb/s down, 16~19Mb/s down
Librem 5 (WiFi) 8~9.5Mb/s down, 15~19Mbs down

I’ve provided a range as I’ve ran the tests a few times on different occasions and these are the min/max rates observed.

For me, it looks like the Librem 5 is capable of making use of 100% of available upload capacity but just ~15% of download capacity.

After some back and forth in email, they issued a RMA. They could not find anything wrong but after six weeks sent a new unit anyway. The new unit has the same dismal WiFi download speed, so it appears to be a design flaw, which is very disappointing. This is an Evergreen unit; do the earlier versions have better WiFi download speed?

I have that also (speedtest on Librem 5 Birch):

Download: 18-19 Mbit/s
Upload: 25-26 Mbit/s

Just as I was about to write that the above numbers seemed fairly consistent for me now, when testing again the numbers were suddenly much worse:

Download: 3.77 Mbit/s
Upload: 5.13 Mbit/s

That was when it was locked, with the screen off. Unlocking it and starting the Usage app, then running speedtest again:

Download: 20.06 Mbit/s
Upload: 23.16 Mbit/s

This now makes me think the issue is related to power-saving features interfering with the Wi-Fi performance. That makes sense, I think, if the CPU sometimes works very slowly due to some power-saving thing, then the Librem 5 might for example be slow in sending its next TCP packet meaning the other side does not see an acknowledgment quickly enough, so the other side decides to resend data and/or decrease the TCP window size, things like that could be happening.

It would be interesting, then, to turn any attempts at power-saving to be sure the CPU runs at full speed all the time, and then run speedtest in that situation to see if the performance is then better and/or more consistent. Anyone here know how to turn off all power-saving? Maybe that question is worth an issue of its own.

1 Like

I don’t know if there is something special to the L5 in this regard but you could try “powertop” which you can normally use to decrease power consumption. Should be in debian repos I think. You have to switch to the correct tab and there you can toggle power saving settings.

Thanks for the info, agreed the current transfer rates are disappointing, I pushed and pulled some files to/from my local network and the transfer rates there follow the same pattern of downloads being notably slower than uploads which extends the disappointment a little further.

I have an Evergreen phone also so not sure about performance of previous versions. I am seeing that signal strength seems to be quite decent so I’m hopeful that the issues could be addressed with a software/firmware update.

FWIW we’re all seeing rather disappointing performance of the WiFi module, with downlink oscillating between 10-30Mbps and even worse when power saving is enabled. I wouldn’t be surprised if this was a kernel driver issue - let’s just say that there were more issues with it than just that… ;]

At least in the very worst case where it turns out to be impossible to fix (but hopefully it’s not!) there is always a possibility of switching to a completely different WiFi card - it’s in a M.2 slot after all :slight_smile:


BTW. A new kernel (5.11.4) with updated WiFi driver is coming to amber-phone in a day or two (see In my experience it doesn’t make it faster, but it does fix several stability and AP compatibility issues so make sure to check it out if you had issues with WiFi and/or Bluetooth!


Very good. My old Moto G6 phone has excellent field from my TP-link C7 WiFi router but my Librem 5 has weak field strength in the same place.

1 Like

Would fit?
Board Form Factor: M.2 2230, M.2 1216
Package Size: 22mm x 30mm x 2.4mm, 12mm x 16mm x 1.65mm

I doubt anything recent for WiFi from Intel will work because it will expect to use PCIe pins on the M.2 interface and those pins are presumably not connected.

It’s good to know that it is a recognised issue at least.

I have upgrade to the latest kernel (5.11.4) and it seems to have essentially crippled WiFi for me.

The first thing I am seeing is that the WiFi card is not been seen/registered during power on boot (no mention of the card in dmesg or journal). Once the phone has powered up, “WiFi” is not available from the settings, I have to put the WiFi/BT kill switch into the off/disabled position and then back to on/enabled position, then the card will come up. This, so far, is 100% repeatable for me.

If I choose “Restart” from the power menu/options then the card does come back up when the phone restarts. However, if I choose “Power Off” the card does not come up until I toggle the HKS.

With regards WiFi performance/stability. A previous “reasonably” stable network has become very unstable, the download speeds are also around 30% or previous this makes it unusable. A previously stable but incredibly slow network AP has now become unstable and now connections mostly timeout.

apt-cache policy shows only the current version (5.11.4pureos1~amber1) of linux-image-librem5 installed and available with no previous versions, so no option to downgrade?

Another way of testing performance is to use the iperf3 command, installed via sudo apt install iperf3. This assumes there is another computer on the same Wi-Fi that the Librem 5 can communicate with.

On the other computer, start an ìperf3 server process like this:

iperf3 -s

While that is running, run an iperf3 client process on the Librem 5 for example like this:

iperf3 -c $server_ip -u -b 320000 -t 30 -l 1000

where -c means client and -u means to use UDP instead of TCP, -b 320000 means 320000 bits per second, -t 30 means to run for 30 seconds, and -l 1000 means that the size of each UDP datagram (packet) will be 1000 bytes.

The above command gave this result for me:

[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total Datagrams
[  5]   0.00-30.00  sec  1.14 MBytes   320 Kbits/sec  0.000 ms  0/1200 (0%)  sender
[  5]   0.00-30.00  sec  1.13 MBytes   317 Kbits/sec  2.187 ms  10/1200 (0.83%)  receiver

which I think is interesting because it shows that 10 packets were lost. So already with this fairly small amount of traffic, there was a significant packet loss. That can explain why we get poor performance using TCP because TCP will need to resend things and use smaller “window” size when packets are lost.

The default behavior of iperf3 -c is sending from the client to the server, so the above test indicates 10 of 1200 packets got lost when the Librem 5 was supposed to send them. Next step of troubleshooting could be to figure out what happened to those 10 packets, like if the wifi driver in the kernel (found at I think) decided to not send them for some reason, or they were sent but got corrupted in some way and discarded by the receiving side, or something else. Time for some Librem 5 kernel hacking? :smiley:


Another interpretation of your results is that you’ve transferred a load of data with less than 1% packet loss. I know a number of people, myself included, that would class that, in general, as a good day. I’m never quite sure how useful these types of tests are as they are not indicative of real world usage and do not represent typical network/data traffic.

From the wildly different results I’m seeing across different hardware, I’m inclined to think (wild guess with no basis in facts) the problem lives deep in the bowels of the 802.11 link layer.

But I can compare this behavior to other devices. For example, running the same test on my laptop does not seem to give any packet loss at all, and the same thing for the PinePhone.

For example, running this specific test five times:

iperf3 -c $server_ip -u -b 320000 -t 60 -l 1000

That sends 40 packets per second for 60 seconds, so 2400 packets in total.
For the Librem 5, placed close to the wireless access point, there are some packets lost every time:

4/2400 (0.17%)
6/2400 (0.25%)
3/2400 (0.12%)
1/2400 (0.042%)
13/2400 (0.54%)

The same test run on the PinePhone, again repeating it 5 times:

0/2400 (0%)
0/2400 (0%)
0/2400 (0%)
0/2400 (0%)
0/2400 (0%)

Thanks to Elias Rudberg who did the research, there’s now a kernel change that should improve the performance of the WiFi module:

This kernel can be tried by downloading and installing the linux-image-5.11.0-1-librem5 deb from the artifacts of the CI job:

(of course the build has to be finished first - at the time I’m posting this it’s still building :))

This won’t fix the issue with WiFi not being present at boot until toggling the killswitch though, that’s a different thing tracked in


Thank you for this build, I have downloaded the artifacts zip archive and may install the packages later.

Do these types of builds, and in particular this specific build, see any form of physical verification? i.e. has someone from internal dev or test physically installed this kernel build on a physical phone and confirmed that it installs okay with no obvious issues or adverse effects?

No, they are CI (continuous integration) builds that are automatically run on each commit.

Of course we don’t kniw how much testing @dos has done before he commited this.

1 Like

I have tested those changes on a slightly different tree (containing unrelated changes too) - then rebased it onto our stock tree, pushed and went to sleep :smiley: