what i meant was - how many mbits/s are you getting when you dl the image NOT if you can boot from it …
Sorry, but that makes no sense to me. Why would downloading that image be any different than downloading anything else? I started running speedtest because downloading and net access in general seemed very slow, and speedtest confirmed it. Isn’t speedtest generally accepted as a valid metric? What am I missing here?
1 Like
sure but it always helps if you have multilple sources to establish scientific fact-ish 
Been there, done that.
I contacted support and have an ongoing email dialog with Mladen regarding this.
Thanks for the suggestion though!
2 Likes
Similar results:
laptop via wifi: 50.30 Mbps down, 4.54 up
librem5 via wifi: 11.26 down, 4.90 up
I did a test with fast.com (which is a Netflix website), on the same network it reached 12Mbps download and upload, while another phone reached 100Mbps download and 80Mbps upload.
I guess one of the factors might be WiFi 4 vs WiFi 5. I am in a noisy office network.
I will try swapping the M.2 WiFi interface with an Intel AC one and test again for science (?)
Maybe we should try outside the browser as well, just in case if eMMC I/O is one of the bottlenecks.
1 Like
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
4 Likes
BTW. A new kernel (5.11.4) with updated WiFi driver is coming to amber-phone in a day or two (see https://master.pureos.net/migrations/excuse/3f446ca2-4934-4ff7-b866-5e5977b60916). 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!
9 Likes
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 https://ark.intel.com/content/www/us/en/ark/products/204836/intel-wi-fi-6e-ax210-gig.html 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 https://source.puri.sm/Librem5/linux-next/-/tree/pureos/byzantium/drivers/net/wireless/redpine 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? 
6 Likes