Raspberry Pi WiFi Performance Revisited

Martin 21 February 202121 February 2021 0 Comments Raspberry Pi, Testing, WiFi

Back in 2019, I attempted to characterise the impact on WiFi performance of various different Raspberry Pi 4 cases. The approach I took then was to capture the WiFi signal strength from various Access Points the Raspberry Pi could see. Having recently been using a Pi in an Argon One M.2 aluminium case and experiencing unexpected network drops and lag whilst using ssh from my PC on the Pi. It was apparent that my previous round of testing was too limited.

In late 2020, I changed my home WiFi configuration, moving from 4 x Apple Airports access points of various models to a pair of Ubiquiti UniFi nanoHD access points positioned on each floor of my home. I’ve removed the Airport that was under my desk, within < 1m of the where I test the Raspberry Pi’s, which is probably what has highlighted the issue. The nearest AP isn’t far away, only about 5m, which I expected to be fine, and other devices I’m working with on a daily basis have all been fine.

TL;DR

Despite some fairly extensive testing and adding additional measurements. The only conclusion I can draw is that 5GHz frequencies are more reliable, pings are more consistent, with faster overall transfer rates, even if the reported Signal Quality is lower. The 2.4GHz channels are more crowded which can lead to high retry rates for WIFi traffic.

The specific problem with WiFi connectivity with the M.2 case continued during my testing, but so far I’ve been unable to pin down the cause. Testing in an uncontrolled environment is probably not suitable. In addition it may be necessary to explore potential noise from the USB 3.0 controller which some other users have reported issues with.

Raspberry Pi 4 WiFi Performance Problems

Whilst investigating the problem I was experiencing, I came across a couple of potential Issues:

Several users have had problems with WiFi not working when using specific video resolutions, and fine at other resolutions, or on different WiFi channels:
- The Raspberry Pi Forum – Pi 4 4GB- Wifi not working when resolution is set too high
- The Register – High-resolution display output or Wi-Fi: It seems you can only choose one on Raspberry Pi 4
- ZDNet – Raspberry Pi 4 Wi-Fi problem: Firmware update will fix your screen resolution bug
There has also been suggestions that USB3.0 usage can interfere with the 2.4 GHz WiFi signal:
- Reddit – Raspberry Pi 4’s USB 3.0 ports are causing self-crippling wireless interference
- Raspberry Pi Github: Issue #1430 – USB3 and 2.4 GHz Wifi
- The Rasbperry Pi Forum: Disable USB-3 to improve the wifi range

In my testing, I’m not connecting anything to the HDMI video interfaces, and I’m also only booting to the console. So HDMI related issues shouldn’t be a factor. I’m also not using USB 3.0 for anything other than Argon ONE M.2 case where the M.2 SATA storage is attached via short USB adapter. So for most scenarios USB3.0 isn’t going to be factor either.

If you’re interested in comparing the performance of different network interfaces on different models of Raspberry Pi then you take a look over at NotEnoughTech.com.

Testing Methodology

Starting out I knew there was a problem, but I wasn’t sure how best to detect and characterise it. I decided to I needed to measure the performance of WiFi interface, in addition, if the problem I had with the Argon ONE M.2 case was related to using the SATA SSD storage, or the USB 3.0 interconnect, then writing data may demonstrate the problem. Along with measuring the performance, I wanted to collect metrics that may provide further insights.

Marking out an area on my desk to ensure all tests were performed with the devices in the same location, I scripted the test and ran it on 2.4 GHz channel 1 and 11 and 5 GHz channel 100.

Access Point Channel Selection

It should be possible to restrict WiFi channel selection using settings in the wpa_supplicant.conf file. Either using freq_list to only offer frequencies for the specific channel under test, or by including the bssid which is is unique for each SSID/Channel combination being advertised by the access point. However, in my testing I could see that when the Raspberry Pi had signal issues it would switch to the 5GHz channels in order to maintain a connection, this is either a bug, or these settings are only used as preference hints.

In the end, I had to reconfigure the access point to only enable a single channel for the test SSID I was using. Ensuring that there wasn’t another channel it could move to.

Channel	Frequency	Width
1	2412 MHz	20 MHz
6	2437 MHz	20 MHz
11	2462 MHz	20 MHz
100	5500 MHz	80 MHz

Raspberry Pi 4 Test System

Image: 2020-12-02-raspios-buster-armhf.zip
Updates: All updates as of 7 February 2021
Kernel: Linux raspberrypi 5.10.11-v7l+ #1399 SMP
Firmware:
- Bootloader: Thu 3 Sep 12:11:43 UTC 2020 (1599135103)
- VL805 USB 3.0 Firmware: 000138a1
- Wireless firmware-brcm80211: Jan 4 2021 19:56:29 version 7.45.229

Test Enclosures

Tests were performed with the Raspberry Pi 4 as a bare board, and also enclosed in the following cases:

Argon Forty NEO Raspberry Pi 4 Case — Argon NEO

Argon ONE for Raspberry Pi 4 — Argon NEO

Test 1 – Combined iPerf and File Transfer

Start test log current access point info to aid in identifying test results
Background ping to the router for the duration of tests
Background collection of wireless metrics
Fixed duration (60 seconds) bidirectional WiFi Performance test using iPerf3
Timed File copy of a ~600MB file from ethernet connected storage server to Raspberry Pi

Test script: wifitest.sh

#!/bin/bash
# wifitest.sh
# A collection of performance tests to characterise WiFi performance
# By: Martin Rowan (www.martinrowan.co.uk)
timestamp=$(date '+%d%m%y-%H%M%S')
# Log AP info
iw wlan0 info > apinfo_$timestamp.out
# Background ping to router
ping 192.168.107.1 > ping_$timestamp.out&
PING_PID="$!"
# Background WiFi metric collection
cat /proc/net/wireless > wifimetrics_$timestamp.out
while sleep 1; do awk 'NR==3' /proc/net/wireless >> wifimetrics_$timestamp.out; done &
WIFI_PID="$!"
# iPerf3 Bidirectional measurement
# Requires additional package `iperf3`
iperf3 -c 192.168.107.1 -t 60 -V -bidir --logfile iperf_c2s_$timestamp.out &
IPERF_PID="$!"
# Wait for Test to complete
wait ${IPERF_PID}
# Copy file via SSH
# Requires additional package `time`
# Requires ssh keys on client and server to avoid password prompt
/usr/bin/time --format="%e" --output=scptime_$timestamp.out scp [email protected]:/tmp/testvideo.mkv ./testvideo.out &
SCP_PID="$!"
# Wait for test to complete then end background tasks
wait ${SCP_PID}
kill ${PING_PID}
kill ${WIFI_PID}

Test 2 – 200MB File Copy via SCP

Following analysis of the tests performed in Test 1, simpler tests were decided upon. Measuring the time to copy a ~200MB file vis SCP from my file server to the Raspberry Pi under test. The test was repeated a minimum of 5 times for each of the enclosure and WiFi channel combinations. Some tests failed and timeout completely, these were excluded and the scenario repeated.

Test script: scptest.sh

#!/bin/bash
# scptest.sh
# A simple timed file copy to aid in characterising WiFi performance
# By: Martin Rowan (www.martinrowan.co.uk)
timestamp=$(date '+%d%m%y-%H%M%S')
# Log AP info
iw wlan0 info > apinfo_$timestamp.out
# Copy file via SSH 
# Requires additional package `time`
# Requires ssh keys on client and server to avoid password prompt
/usr/bin/time --format="%e" --output=scptime_$timestamp.out scp [email protected]:/tmp/testfile.zip ./testfile.out 
timestamp=$(date '+%d%m%y-%H%M%S')
/usr/bin/time --format="%e" --output=scptime_$timestamp.out scp [email protected]:/tmp/testfile.zip ./testfile.out
timestamp=$(date '+%d%m%y-%H%M%S')
/usr/bin/time --format="%e" --output=scptime_$timestamp.out scp [email protected]:/tmp/testfile.zip ./testfile.out
timestamp=$(date '+%d%m%y-%H%M%S')
/usr/bin/time --format="%e" --output=scptime_$timestamp.out scp [email protected]:/tmp/testfile.zip ./testfile.out
timestamp=$(date '+%d%m%y-%H%M%S')
/usr/bin/time --format="%e" --output=scptime_$timestamp.out scp [email protected]:/tmp/testfile.zip ./testfile.out
timestamp=$(date '+%d%m%y-%H%M%S')

Test Results

Test 1 sought to perform a wide range of tests in order to see if any specific test/result would highlight a problem specific to how the Raspberry Pi 4 is used, or how it’s enclosed.

Test 1 Results

Ping Times Throughout Test

The first ~60 seconds of each test comprises a iperf test between the Pi and iPerf running on my PFSense router. During this segment of the test the ping time remains mostly quite low. Once the SCP file copy of a 600MB file begins the ping times become a lot more erratic for all the tests using the 2.4GHz channels. For the 5GHz scenarios, pings are more consistent, and remain significantly lower.

The type of enclosure doesn’t appear to have any significant impact, though it should be noted that the Raspberry Pi 3 B+ appears to out perform the newer Raspberry Pi 4. This may provide some support to the theory that the USB 3.0 controller on the Raspberry Pi 4 may be impacting 2.4GHz WiFi, but there are a lot of other changed between these two versions that there is insufficient evidence to draw that conculsion.

Signal Quality Throughout Test

Another ongoing measurement through the test was collecting WiFi metrics available on the Raspberry Pi. Reviewing the data collected, two appear to be of interest. The number of retries during the test and the reported Signal Quality. Note, on 5GHz retries don’t appear to be reported,

For different WiFi channels and enclosures, retries are seen, without any clear pattern. Signal quality shows that 5GHz results report a lower overall quality, I suspect that the lower signal strength is the main contributing factor to this, as higher frequency 5GHz signals will be attenuated more than 2.4GHz signals as the signals pass-through objects between the Access Point and the antenna on the Raspberry Pi.

iPerf3 Test

The retries reported by iPerf3 don’t exactly correlate with the WiFi retries, as before, the retries don’t show a clear pattern between WiFi channel and enclosure. More likely other external factors are contributing to the retries. Neighbouring Access Points on the same channel or other RF noise.

The Bitrate for Sender and Receiver, again show the benefits of the faster transfer rates available when using the 5GHz band, within the 2.4GHz results the transfer rates don’t appear to vary significantly by enclosure.

SCP ~600MB File Test

The SCP tests of a 600MB file support the previous iPerf results, with the 5GHz tests being significantly quicker than their 2.4GHz counterparts. Once again within the 2.4GHz result the enclosure can’t be said to conclusively make s difference.

Test 2 Results

With the test suit used in Test 1, some tests were taking close to 30 mins to complete. As such repeating all test combinations multiple times to try eliminate noise in the test results would have been prohibitive, (I have lots of other things to do). Instead, I opted to reduce the file size to ~200MB and repeat copying the file from the File Server to the Pi a minimum of 5 times.

The most significant outlier in all the results is using Channel 6 in conjunction with the Argon ONE M.2 enclosure, to ensure this wasn’t a mistake, this scenario was run a further 5 times on a different day, yet the results remained consistently high. The same results weren’t seen on the 600MB file test, so once again it suggests something potentially environmental impacted the results.

Conclusions

It’s apparent that there are factors outside the parameters of the test which have a significant influence on the Raspberry Pi WiFi performance. My home-based test environment isn’t controlled enough to eliminate or measure many of these factors.

Using 5GHZ channels where available will give more reliable and greater throughput connections.
2.4GHz channels are more prone to interference, which can impact the stability and performance of your connection.
Using metal enclosures, don’t appear to have a significant impact on WiFi performance.

It remains unclear if the USB3.0 controller, the M.2 control board or the mSATA SSD are contributing to impacting WiFi performance.

Product Links

Raspberry Pi 4 (Amazon) (Pimoroni) (ThePiHut)
Argon ONE M.2 SSD case (Amazon) (Pimoroni) (ThePiHut)
Argon ONE case (Amazon) (Pimoroni) (ThePiHut)
Argon NEO case (Amazon US, UK) (Pimoroni) (ThePiHut)
Ubiquiti UniFi nanoHD Access Point (Amazon US, UK)

Amazon links are affiliate links which help support the site, where possible I’ve used links which should take you to the product in the Amazon store in your region. Links to other suppliers are included for your convenience.