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? 