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
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%)
4 Likes
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 https://source.puri.sm/Librem5/linux-next/-/issues/264.
10 Likes
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
2 Likes
Yeah, I get that. My question was more wondering if there was an intention for someone in dev/test to physically sanity check the build, in which case I would wait for confirmation of that check. If not, I’ll pass on it, while it may be okay, I don’t have the time to commit to it should any unforeseen issues arise.
Given that it was already merged into the release kernel tree, I would expect the change to trickle onto your L5 in the not too distant future anyway.
1 Like
Happy to report that this has happened now.
Running speedtest 3 times, before update:
Download: 3.30 Mbit/s
Download: 3.39 Mbit/s
Download: 3.51 Mbit/s
After update:
Download: 38.73 Mbit/s
Download: 38.54 Mbit/s
Download: 43.18 Mbit/s
To check if you have the new kernel version you can use this command:
purism@pureos:~$ apt list linux-image-librem5
Listing... Done
linux-image-librem5/byzantium,now 5.11.8pureos1 arm64 [installed]
I was confused first because uname -a shows the same info (5.11.0-1-librem5) both before and after the update, but the apt command above shows the new version number 5.11.8pureos1.
Anyway, significant improvement!
5 Likes
Good for you, I got tons of these in my “dmesg”:
[ 3793.715305] redpine_91x: Packet Dropped as Key ID not matched with both current and previous Key ID
and by tons, I mean once per second. Also, with this kernel I don’t get any mobile connection anymore…
[
Hm, I don’t get anything like that. Here is my dmesg output mentioning redpine:
purism@pureos:~$ sudo dmesg | grep redpine
[ 7.022834] redpine_91x: rsi_probe: ***** 9116 Module *****
[ 7.023243] redpine_91x: redpine_hal_device_init: oper_mode = 13, coex_mode = 2
[ 7.069727] redpine_91x: ***** Loaded Firmware *****
[ 11.703323] redpine_91x: ================================================
[ 11.703352] redpine_91x: ================ RSI Version Info ==============
[ 11.703357] redpine_91x: ================================================
[ 11.703362] redpine_91x: FW Version : 1.2.20.0
[ 11.703373] redpine_91x: RSI FW Version : 0000.1.2.0.0502
[ 11.703382] redpine_91x: Driver Version : RS9116.NB0.NL.GNU.LNX.OSD.2.0.0.0024
[ 11.703388] redpine_91x: Operating mode : 13 [Wi-Fi STA + BT DUAL]
[ 11.703394] redpine_91x: Firmware file : (null)
[ 11.703400] redpine_91x: ================================================
[ 11.707108] redpine_91x: rsi_send_bt_reg_params: Sending BT reg frame
[ 11.708431] redpine_91x: HCI module init done...
[ 11.714601] redpine_91x: RSI HCI DEVICE "hci0" open
[ 11.838100] redpine_91x: <==== Interface UP ====>
[ 11.838183] redpine_91x: rsi_mac80211_bss_info_changed: Change of ERP INFO: 0
[ 11.838193] redpine_91x: rsi_mac80211_bss_info_changed: Sending vap updates....
[ 11.856638] redpine_91x: <==== Interface DOWN ====>
[ 11.858754] redpine_91x: <==== Interface UP ====>
[ 11.858820] redpine_91x: rsi_mac80211_bss_info_changed: Change of ERP INFO: 0
[ 11.858829] redpine_91x: rsi_mac80211_bss_info_changed: Sending vap updates....
[ 15.777232] redpine_91x: <==== Interface DOWN ====>
[ 15.780110] redpine_91x: <==== Interface UP ====>
[ 15.780171] redpine_91x: rsi_mac80211_bss_info_changed: Change of ERP INFO: 0
[ 15.780182] redpine_91x: rsi_mac80211_bss_info_changed: Sending vap updates....
[ 19.463627] redpine_91x: EAPOL 4 confirm
Network info:
purism@pureos:~$ iw dev
phy#0
Interface wlan0
ifindex 4
wdev 0x1
addr [...]
ssid [...]
type managed
channel 36 (5180 MHz), width: 40 MHz, center1: 5190 MHz
txpower 20.00 dBm
For me, the mobile connection works. I wonder what is different, why you get trouble when all works for me. I am using byzantium – you too?
Yep, unmodified byzantium here.
I get them too. Lots of them. This isn’t a recent change. WiFi still works however.
I’m using amber.
…and it has just migrated into the amber-phone repository.
1 Like