Librem 5 Wi-Fi performance

Loki · March 17, 2021, 12:48pm

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.

Skalman · March 18, 2021, 8:38am

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%)

dos · March 19, 2021, 6:09am

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.

Loki · March 19, 2021, 2:42pm

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?

spaetz · March 19, 2021, 4:25pm

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.

dos · March 19, 2021, 4:49pm

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

Loki · March 19, 2021, 4:59pm

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.

spaetz · March 19, 2021, 5:10pm

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.

Skalman · March 26, 2021, 5:13pm

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!

spaetz · March 26, 2021, 5:44pm

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…
[

Skalman · March 26, 2021, 10:08pm

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?

spaetz · March 27, 2021, 6:44am

Yep, unmodified byzantium here.

irvinewade · March 27, 2021, 9:51am

I get them too. Lots of them. This isn’t a recent change. WiFi still works however.

I’m using amber.

dos · March 30, 2021, 2:52am

…and it has just migrated into the amber-phone repository.

Skalman · March 30, 2021, 12:02pm

Yes! I just reflashed with amber-phone and after installing updates and rebooting, the new kernel is there. Now my tests using speedtest give download speed around 40 Mbit/s on amber-phone also.

That is for a Wi-Fi network using channel 36 (5180 MHz), width: 40 MHz (info from the iw command)

But I get confused by the version numbers, seems like uname -r shows the same info, 5.11.0-1-librem5 both before and after the kernel upgrade:

purism@pureos:~$ uname -r
5.11.0-1-librem5

Is it supposed to be like that @dos – I was expecting uname -r to show something different after the upgrade?

dos · March 30, 2021, 12:14pm

Yes, that’s normal. dpkg -l linux-image-librem5 will show you the installed package version.

Skalman · March 30, 2021, 12:36pm

Thanks!

But then I think there is a potential for confusion because that command, although it shows the installed package version as you say, does not show which kernel is currently running?

I mean, in the situation right after I installed a new kernel package but while I have not yet rebooted, that command will show the new kernel version but I am still running the old version, until I reboot, I think. If everyone takes the habit of always rebooting directly after installing the new kernel package then there is no problem of course.

dos · March 30, 2021, 12:39pm

Then you can always report the whole output of uname -a, like:

Linux librem5 5.11.0-1-librem5 #1 SMP PREEMPT Mon Mar 22 14:21:27 PDT 2021 aarch64 GNU/Linux

This includes the build date, which can be mapped back to the package version.

Skalman · March 30, 2021, 12:54pm

Great, looking at the build date solves the problem for me. I had actually run uname -a before and after reboot but it didn’t occur to me to look at the date. Now I see the difference there.

Before reboot:

purism@pureos:~$ uname -a
Linux pureos 5.11.0-1-librem5 #1 SMP PREEMPT Wed Mar 17 02:15:51 PDT 2021 aarch64 GNU/Linux

After reboot:

purism@pureos:~$ uname -a
Linux pureos 5.11.0-1-librem5 #1 SMP PREEMPT Tue Mar 23 15:28:50 PDT 2021 aarch64 GNU/Linux

Thanks again for your help. I’m learning a lot on this forum today, as usual.

irvinewade · March 30, 2021, 11:10pm

While we are discussing this kind of issue, I notice that the notes for the update (that it invites me to read each time) are always content free:

Includes performance, stability and security improvements

(This is using the GUI to update.)

I understand that noone wants to devote Purism resources to writing actual release notes. That’s fine. So would it be possible instead to generate release notes automatically with just the updated package versions (although in this case it would seemingly have to specify the build date)?