There is a 
wiki page for a new addon - speedtest.
The new addon was released as part of Core Update 137. Feel free to comment or add to it.
3 Likes
Hi @jon, I was just testing out speedtest via the console and comparing the results to those received from running speedtest in a browser. There appears to be a wide discrepancy and I was wondering if you also experience this and have any idea why that might be?
Avg Down/Up (Mbps)
Console: 340 / 21
vs.
Vivaldi: 635 / 21
I’m using the same server for all tests and I switch back and forth from the console and browser. The console consistently shows 340 while the browser holds steady around 635.
I turned off the IPFire QOS (menu Service > Quality of Service) and gave things a try.
This is the speedtest addon running on my IPFire box:
ping: 17.541 ms
Download: 181.33 Mbit/s
Upload: 12.07 Mbit/s
This is the speedtest-cli running on the console on my Mac:
ping: 17.015 ms
Download: 182.24 Mbit/s
Upload: 12.15 Mbit/s
I’m not a Vivaldi user but the test results for Safari running on my Mac:
ping: 11 ms
Download: 239.56 Mbit/s
Upload: 12.01 Mbit/s
And here is the Speedtest app loaded on my Mac:
ping: 11 ms
Download: 241 Mbit/s
Upload: 12.1 Mbit/s
All tests are to the same server.
So I see similar odd results and they seem to point to Speedtest-cli. But I do not know why. Maybe the author could provide more clues than me. https://github.com/sivel/speedtest-cli
1 Like
Just an FYI, it appears that speedtest-cli cannot really be relied upon for accurate results…from: https://github.com/sivel/speedtest-cli
" There is the potential for this tool to report results inconsistent with Speedtest.net. There are several concepts to be aware of that factor into the potential inconsistency:
1. Speedtest.net has migrated to using pure socket tests instead of HTTP based tests
2. This application is written in Python
3. Different versions of Python will execute certain parts of the code faster than others
4. CPU and Memory capacity and speed will play a large part in inconsistency between Speedtest.net and even other machines on the same networkIssues relating to inconsistencies will be closed as wontfix and without additional reason or context."
1 Like
Good find!
That is obviously a normal problem that you have when benchmarking something.
So this speedtest is just as reliable as any other ones. But they are reproducible, easy to run and give a good idea about where you are ending up.
So is speedetest limited by IPfire QoS or not?
Edit: it seems so, at least a test revealed this. Question: is there a cmd to stop QoS while running the speedtest and restart it afterwards?
Something besides the IPFire WUI menu Services > Quality of Service, then click Stop?
I see a command /usr/local/bin/qosctrl. I’ve not used it before so I really don’t know if this helps.
[root@ipfire ~]# /usr/local/bin/qosctrl
No argument given.
qosctrl (start|stop|restart|status|generate)
EDIT: see https://forum.ipfire.org/viewtopic.php?f=27&t=20266
Yes, that is the job of the QoS, to limit certain traffic.
I know, Michael, however, when executing speedtest on IPFire’s console, I thought this would probably not be affected by QoS.
Anyway, I’ve already found that QoS interferes there, too…
Thx,
Michael
So… two options:
- disable QoS while testing
- do not speed test
Latter is not that useful… Could a Qos rule override Qos management for speed test starting from IPFire?
Idea behind is to create a script that stops QoS at night, run the speedtest and restart QoS afterwards.
The result in CSV format should be inserted into a database for monitoring.
I will see if this works, reliable, besides the mentioned measuring inaccuracy.
Sorry, I am completely missing what you are trying to do here.
Why do you need to run the speedtest once every night?
Benchmark the provider during the days/weeks. Most of ISP are in overbooking 
And having some stats for understand/know the real performance, QoS can be adjusted and you can bug your ISP asking “Please improve my service”
1 Like
Hey! I just came across this while looking for something else. Ookla came out with their own Speedtest CLI. Much more better™ then the sivel version.
https://www.speedtest.net/apps/cli
Installed on my iMac:
iMac3:~ me$ speedtest -s 5900
Speedtest by Ookla
Server: aFastServer - Arlington Heights, IL (id = 5900)
ISP: myFastISP
Latency: 10.95 ms (0.31 ms jitter)
Download: 240.29 Mbps (data used: 223.9 MB)
Upload: 11.98 Mbps (data used: 9.5 MB)
Packet Loss: 0.0%
Result URL: https://www.speedtest.net/result/c/bb62347f-3562-47f5-8277-1234567890
Note 1: This is with QOS turned off.
Note 2: Be aware if you have the sivel speedtest installed. The sivel speedtest will continue to run instead of the Ookla speedtest.
EDIT: https://www.speedtest.net/insights/blog/introducing-speedtest-cli/
Pro for Ookla: widely know, quite “acceptable” for non-tech people.
Pro for sivel: it’s independent (and maybe not twekable) by Ookla
1 Like
This is/was the article I was looking for:
I set up my Raspberry Pi to automatically tweet at Comcast Xfinity whenever my internet speeds drop significantly below what I pay for
https://twitter.com/a_comcast_user
After reading the above I started keeping track of Internet speeds. I was not looking for “blazing fast at all times!”. But when the speeds went low it made it easy to complain. (the breaks in the graph are when there was no Internet service)
Jon, so you are using speedtest-cli as a base for this graph?
I plan to do the same as mentioned above.
Yes. But running on a Raspberry PI and a 100 MB ethernet port. So the max download speed was near 92.
@ms Why did you remove from https://wiki.ipfire.org/addons/speedtest-cli the quote from speedtest-cli Github page that provide users with a heads up about the potential for results inconsistency? I think this is very relevant to anyone who uses speedtest-cli.