netperf.bufferbloat.net is working fine but it doesn't give me full download speed (90+mbps) as it's US based - so it's not good for testing my QoS setup.
I managed to install!!
BusyBox v1.31.1 () built-in shell (ash)
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -| || | | || || |
|_____|| |||||___||| |____|
|| W I R E L E S S F R E E D O M
SuperWRT SNAPSHOT, r11572-0062aad8ec
root@swrt:~# speedtest-netperf.sh -H netperf-west.bufferbloat.net -p 1.1.1.1 --s
equential
2019-11-25 14:12:30 Starting speedtest for 60 seconds per transfer session.
Measure speed to netperf-west.bufferbloat.net (IPv4) while pinging 1.1.1.1.
Download and upload sessions are sequential, each with 5 simultaneous streams.
.............................................................
Download: 371.40 Mbps
Latency: [in msec, 61 pings, 0.00% packet loss]
Min: 11.300
10pct: 12.205
Median: 13.261
Avg: 13.459
90pct: 14.129
Max: 20.407
CPU Load: [in % busy (avg +/- std dev), 59 samples]
cpu0: 21.9 +/- 6.4
cpu1: 27.1 +/- 6.1
Overhead: [in % used of total CPU available]
netperf: 14.7
.............................................................
Upload: 308.72 Mbps
Latency: [in msec, 61 pings, 0.00% packet loss]
Min: 11.225
10pct: 11.400
Median: 12.535
Avg: 12.585
90pct: 13.971
Max: 15.642
CPU Load: [in % busy (avg +/- std dev), 59 samples]
cpu0: 15.5 +/- 4.2
cpu1: 18.8 +/- 4.5
Overhead: [in % used of total CPU available]
netperf: 2.7
root@swrt:~#
BusyBox v1.31.1 () built-in shell (ash)
| |.-----.-----.-----.| | | |.----.| |_
| - || _ | -| || | | || || |
|_____|| |||||___||| |____|
|| W I R E L E S S F R E E D O M
SuperWRT SNAPSHOT, r11572-0062aad8ec
root@swrt:~# speedtest-netperf.sh -6 -H netperf-west.bufferbloat.net -p google.r
o --sequential
2019-11-25 14:20:50 Starting speedtest for 60 seconds per transfer session.
Measure speed to netperf-west.bufferbloat.net (IPv6) while pinging google.ro.
Download and upload sessions are sequential, each with 5 simultaneous streams.
.............................................................
Download: 322.37 Mbps
Latency: [in msec, 61 pings, 0.00% packet loss]
Min: 14.423
10pct: 14.804
Median: 16.035
Avg: 16.333
90pct: 17.300
Max: 23.545
CPU Load: [in % busy (avg +/- std dev), 59 samples]
cpu0: 21.4 +/- 6.7
cpu1: 26.1 +/- 7.2
Overhead: [in % used of total CPU available]
netperf: 14.9
..............................................................
Upload: 238.46 Mbps
Latency: [in msec, 62 pings, 0.00% packet loss]
Min: 14.055
10pct: 14.194
Median: 15.091
Avg: 15.743
90pct: 17.473
Max: 25.296
CPU Load: [in % busy (avg +/- std dev), 60 samples]
cpu0: 15.2 +/- 4.5
cpu1: 18.1 +/- 5.7
Overhead: [in % used of total CPU available]
netperf: 2.2
Why can't I get the real speed my provider gives me, specifically 1Gbps?
Well, it seems that the server is only connected via gigabit ethernet in the first place, so unless you are a) the only concurrent user and b) the VPS instance is not already sharing the NIC with other VPSes on the same host, getting 1 Gbps speedtest results is going to be tricky.
These servers are generously supplied for by private volunteers so there are no guarantees that it will work at all, let alone with a 1000/500 FTTH-class of link...
I guess the server isn't designed to test against gbit speeds but it could also be related to your location and/or the peering of your ISP.
I wonder if we could use this as a means to help adjust the line to a comfortable level for a first time sqm setup. Basically take the average of 5 pings a second with a set average response time of say 10ms difference(adjustable) goal for bufferbloat. Keep reducing the bandwith @ 1% (again adjustable) till that =/<10ms average time is met? This means about a give or take automation of four changes to the interface bandwidth? I'm spitt-balling here. If I knew enough about programming I would surely make this happen!
- Establish base average ping times
- Begin speedtest
- If avrg ping time of 5 pings is >10ms, reduce 1% and try again. rinse and repeat till target is met.
- Ability to jiggle parameters
- Apply the same technique to Ingress as well as Egress
- Log these steps ( possibly to a file for graphing?)
2 Likes
The challenge with this kind of automation is that you need to be able to differentiate between saturating the access link (what you likely want to measure) and overloading the test server (say because a 1Gbps connected server can not saturate two 1Gbps access links simultaneously. In essence that means that you either need a Speedtest with access control (like Breitbandmessung.de, which has a mandatory questionnaire at the beginning asking for your internet plan's Tarif/speed, but alas only for known ISP and plans in Germany, that way the server can predict whether it has enough available resources to run a test against the requesting client computer, that question are however is probably tricky to automatically fill out) or a private Speedtest hosted on your own VPS. None of these options are particularly beginner friendly. But please let this not stop you. As far as I know eventoute have set up their own measurement infrastructure for automatic Speedtest for their paying customers which could serve as a reference for your idea actually working in reality (and also the challenges that need to be overcome).
1 Like
Speedtest.net has a few ways of running their test from the command line for Windows, Mac, & Linux. Maybe their is a way to incorporate this into a script. https://www.speedtest.net/apps/cli
- does a generic one size fits all starting config... exist?
- what would be a good starting point?
If there were to be a "pre-wizard" what would be the minimum amount of questions?
- Select geo region ( aka "apt like server selection" )
- Select connection type
- Select Maximum up + down speed
- Select learning frequency and duration ( every 2 hours for 2 days run "auto adjustment" based on X reports <-hysteresis )
- Select long term reporting frequency ( after initial setup every 7 days at X time check and report assessment or go ahead and keep micro-adjusting longer term ... )
Well, to participate in their test server network all one needs is a 1Gbps connection, and without proper access control a single customer can max out that server. In Europe the best bet would be to use the regulatory required Speedtest system, as that can be expected to be of higher quality than your average speedtest.net server (as failed Speedtest can have legal contractual consequences between user and ISP each national regulator is required to bless official Speedtest servers, which are held to a high(er) Standard). But at least the German seems hard to automate...
Except for the two bandwidth and the overhead settings, the defaults, while not optimal should work reasonably okay (sqm tries hard to use sane defaults and is willing to change defaults if data merits that).
But measuring the available bandwidth reliably is simply hard. For example, the router itself might not have the CPU cycles to initiate and terminate large data transfers (while still being capable of routing and shaping these) resulting in reduced throughput by way of being limited by the router's CPU and not by the link, now it is possible to also monitor CPU load during a test (a monitoring which itself has a CPU cost) but it certainly complicates things.
And don't get me started on per packet overhead which is really hard to measure from the end-users vantage point... (we could simply default to 48 Bytes which would be enough for almost anybody), and what about encapsulations like ATM?
One option certainly would be a binary search starting at some arbitrary numbers, but then the user will need to leave the router and internet basically alone while the measurement are on going until a reasonable set is found.
In theory the router could simply run, say a continuous ICMP probe against, say 8.8.8.8 r anything else reliably close by, while repeatedly sampling the traffic counters of the configured SQM-interface 9with SQM not running) that way the user could generate the actual load any way he/she pleases (on a beefy router the router could do it on a puny one the user just runs speedtest on a connected client), while the router still has a measure of the bandwidth and the latency under load.
All of this seems theoretically possible, but given that typically sqm needs to be set once and maybe re-assessed every 4 weeks (if at all) automating this seems a lot of work for little gain, no?
This is a decent idea, as it would allow some sanity checking, but it gets close to the recommended way to set things up.
Update: I guess it's as simple as the default netperf server is not responding.
Any thoughts on how one finds a working netperf server to use?
On 19.07.0-rc2 I get:
2020-01-09 19:55:13 Starting speedtest for 60 seconds per transfer session.
Measure speed to netperf.bufferbloat.net (IPv4) while pinging gstatic.com.
Download and upload sessions are sequential, each with 5 simultaneous streams.
...................................................................................................................................
WARNING: netperf returned errors. Results may be inaccurate!
Download: 0.00 Mbps
Latency: [in msec, 132 pings, 0.00% packet loss]
Min: 45.949
10pct: 79.030
Median: 156.078
Avg: 185.193
90pct: 348.744
Max: 597.760
CPU Load: [in % busy (avg +/- std dev), 129 samples]
cpu0: 5.9 +/- 8.7
Overhead: [in % used of total CPU available]
netperf: 1.3
.....................................................................................................................................
WARNING: netperf returned errors. Results may be inaccurate!
Upload: 0.00 Mbps
Latency: [in msec, 133 pings, 0.00% packet loss]
Min: 45.349
10pct: 70.364
Median: 115.066
Avg: 166.269
90pct: 267.019
Max: 1498.482
CPU Load: [in % busy (avg +/- std dev), 130 samples]
cpu0: 5.8 +/- 8.4
Overhead: [in % used of total CPU available]
netperf: 1.3
How can I get any more information on the errors that netperf returned?
Some kind of verbose/debugging mode would be useful.
I fear, setting up one's own on a VPS/hosted server is the most reliable (but least convenient) option.
on 9 Jan 2020 brianjmurrel wrote:
The default netperf.bufferbloat.net server was offline because it was being hammered by people who run a speed test every 5 minutes, 24 x 7.
I have a script that scans the log files and black holes the IP addresses, but some months there's a huge tidal wave of traffic that uses up my (4 TBytes) of traffic and the server gets shut off. This month was one instance - 90% of my limit was used up by 6 Jan, so I shut off the netperf server.
It's turned back on now, but you can also use:
Or stand up your own VPS, install netperf, and you can run your own tests...
2 Likes
Good Job @guidosarducci! Thanks a lot!
..............................................................
Download: 45.94 Mbps
Latency: [in msec, 62 pings, 0.00% packet loss]
Min: 8.640
10pct: 8.735
Median: 8.924
Avg: 8.953
90pct: 9.151
Max: 9.643
CPU Load: [in % busy (avg +/- std dev), 60 samples]
cpu0: 5.3 +/- 5.1
cpu1: 9.7 +/- 13.0
Overhead: [in % used of total CPU available]
netperf: 1.7
...............................................................
Upload: 39.91 Mbps
Latency: [in msec, 62 pings, 0.00% packet loss]
Min: 8.875
10pct: 9.517
Median: 14.997
Avg: 19.364
90pct: 37.751
Max: 42.688
CPU Load: [in % busy (avg +/- std dev), 61 samples]
cpu0: 3.9 +/- 3.4
cpu1: 9.6 +/- 9.8
Overhead: [in % used of total CPU available]
netperf: 0.4
Do you have idea to put this in the Luci interface in future? Will be awesome!
Regards!!
opkg update
opkg install python-light
opkg install python-pip
pip install --user speedtest-cli
/root/.local/bin/speedtest-cli --no-pre-allocate
[root@OpenWrt ~]# /root/.local/bin/speedtest-cli --no-pre-allocate
Retrieving speedtest.net configuration...
Testing from Fastweb (93.56.75.113)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Melita (Milan) [0.63 km]: 31.258 ms
Testing download speed................................................................................
Download: 28.45 Mbit/s
Testing upload speed................................................................................................
Upload: 5.23 Mbit/s
simple mode:
[root@OpenWrt ~]# /usr/bin/speedtest-cli --no-pre-allocate --simple
Ping: 16.286 ms
Download: 19.69 Mbit/s
Upload: 8.66 Mbit/s
or:
[root@OpenWrt ~]# /usr/bin/speedtest-cli --no-pre-allocate --no-upload | grep Download
Download: 18.73 Mbit/s
[root@OpenWrt ~]# /usr/bin/speedtest-cli --no-pre-allocate --no-download | grep Upload
Upload: 8.20 Mbit/s
4 Likes
Finally!!! someone who speaks plain instructions. I hate reading most of the github instructions as the developers write that in such a way (short hand) they can only understand. Thank you for laying out plan and simple to setup and understand.
1 Like
Thank you again!!! you are awesome. Clear and plain instructions. Why cant most github developers just give good instructions without jumping in halfway through the process and writing shorthand. THANK YOU!!
1 Like
Not sure if it was a typo but your last three commands used a different directory, They only worked for me if I used
/root/.local/bin/speedtest-cli --no-pre-allocate --simple
NOTE: your command was "/usr/bin/speedtest-cli --no-pre-allocate --simple"