I'd been thinking about making a network speed testing package since first posting about the currently available options, and over the last few weeks have developed, tested, and packaged the
Before making a PR and trying to merge into the openwrt/packages repo, I'd like some more testing exposure, especially on multi-core systems.
The speedtest.sh script measures network throughput while monitoring the latency under load and capturing key CPU usage and frequency statistics. The script can emulate a web-based speed test by downloading and then uploading from an internet server, or perform simultaneous download and upload to mimic the stress of the FLENT test program. It simplifies tasks such as validating ISP provisioned speeds or setting up and fine-tuning SQM, directly on the router. The CPU usage details can also help determine if the demands of SQM, routing and other tasks such as the test itself are exhausting the device's CPUs. This script leverages earlier scripts from the CeroWrt project used for bufferbloat mitigation, betterspeedtest.sh and netperfrunner.sh. They are used with the permission of the author, Rich Brown.
A package for testing can be installed directly from my repo, and should work on LEDE 17.01 on up:
# uclient-fetch https://github.com/guidosarducci/papal-repo/raw/master/speedtest_0.9-7_all.ipk # opkg install speedtest_0.9-7_all.ipk
It is also possible to install and run the
speedtest.sh script on a Linux server connected to your router's LAN interface. This can be useful if running the script on your router consumes too much CPU or fails to meet your speed and latency targets. For example, on Ubuntu:
$ sudo apt-get install netperf wget $ cd /tmp $ wget https://raw.githubusercontent.com/guidosarducci/packages/master-add-speedtest/net/speedtest/files/speedtest.sh
The script output includes network throughput, packet loss, a latency distribution, per-core processor usage and frequency, and CPU consumption of the test program (mainly netperf) itself.
Sample output on an old DIR-835 router (560 MHz single-core MIPS) showing the standard sequential test followed by the more stressful concurrent test:
# speedtest.sh -H netperf-west.bufferbloat.net -p 18.104.22.168 --sequential [Date/Time] Starting speedtest for 60 seconds per transfer session. Measure speed to netperf-west.bufferbloat.net (IPv4) while pinging 22.214.171.124. Download and upload sessions are sequential, each with 5 simultaneous streams. .............................................................. Download: 33.30 Mbps Latency: [in msec, 64 pings, 0.00% packet loss] Min: 9.551 10pct: 11.281 Median: 14.480 Avg: 14.550 90pct: 17.327 Max: 21.308 CPU Load: [in % busy (avg +/- std dev), 57 samples] cpu0: 86.7% +/- 6.5% Overhead: [in % used of total CPU available] netperf: 60.2% ............................................................. Upload: 5.13 Mbps Latency: [in msec, 61 pings, 0.00% packet loss] Min: 8.615 10pct: 9.792 Median: 14.152 Avg: 14.303 90pct: 17.317 Max: 19.934 CPU Load: [in % busy (avg +/- std dev), 58 samples] cpu0: 19.7% +/- 5.7% Overhead: [in % used of total CPU available] netperf: 1.4%
# speedtest.sh -H netperf-west.bufferbloat.net -p 126.96.36.199 --concurrent [Date/Time] Starting speedtest for 60 seconds per transfer session. Measure speed to netperf-west.bufferbloat.net (IPv4) while pinging 188.8.131.52. Download and upload sessions are concurrent, each with 5 simultaneous streams. .............................................................. Download: 31.86 Mbps Upload: 4.53 Mbps Latency: [in msec, 63 pings, 0.00% packet loss] Min: 8.871 10pct: 13.792 Median: 17.480 Avg: 18.427 90pct: 22.292 Max: 57.617 CPU Load: [in % busy (avg +/- std dev), 59 samples] cpu0: 90.0% +/- 9.7% Overhead: [in % used of total CPU available] netperf: 46.6%
In the examples above, my target upload/download speeds are achieved with good latencies. Although the CPU load is high, much of that is due to the
netperf test program itself, so during normal operation there should be more CPU "headroom" available.
For your own testing, please note the script [Usage](https://github.com/guidosarducci/packages/tree/master-add-speedtest/net/speedtest/files#usage) parameters below from the README, and try to run both a **sequential** and **concurrent** test, using a netperf-server geographically close to you.
speedtest.sh [-4 | -6] [-H netperf-server] [-t duration] [-p host-to-ping] [-n simultaneous-streams ] [-s | -c] Options, if present, are: -4 | -6: Enable ipv4 or ipv6 testing (default - ipv4) -H | --host: DNS or Address of a netperf server (default - netperf.bufferbloat.net) Alternate servers are netperf-east (US, east coast), netperf-west (US, California), and netperf-eu (Denmark). -t | --time: Duration for how long each direction's test should run - (default - 60 seconds) -p | --ping: Host to ping to measure latency (default - gstatic.com) -n | --number: Number of simultaneous sessions (default - 5 sessions) -s | --sequential: Sequential download/upload (default - sequential) -c | --concurrent: Concurrent download/upload
Appreciate any usage feedback, and with luck this will make it into OpenWrt proper. Thanks all!
- fix typo causing missing "avg frequency" heading and improve robustness
- cleanup whitespace, clarify wording of netperf overhead & load samples - use clearer, consistent local and global variables - check and warn on netperf errors - more robust frequency calculation, ping summary - use sysfs for better cross-platform CPU frequency summary (e.g. arm)