New Speedtest Addon Wiki Page!

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.

1 Like

Just an FYI, it appears that speedtest-cli cannot really be relied upon for accurate results…from:

" There is the potential for this tool to report results inconsistent with There are several concepts to be aware of that factor into the potential inconsistency:

1. 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 and even other machines on the same network

Issues 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

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…


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 :wink:
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.

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:

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.


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

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 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.


sorry for not leaving a comment on this (I need to add that to the wiki when we do a rollback).

I thought that it would be better to either link this discussion or reference it elsewhere. I do not think that we need to have an extra paragraph on the wiki for this, because I consider these speed tests always as unreliable. Benchmarks are always flawed in one way or another. I highly doubt that this is because of the Python implementation.

Speed tests are just some kind of indication about what has gone through your link at a certain point in time. They are not reproducible at all.

1 Like

I agree, however, for me, running IPFire in my home lab, speedtest-cli delivers enough information to get at least an impression what’s going on or if the speed decreases significantly over a a certain period of time.