
Run an Internet Speed Test from the Command Line - dragondax
https://www.putorius.net/speed-test-command-line.html
======
dspillett
Note that some ISPs prioritise traffic to known speedtest targets, turning off
traffic shaping rules that might otherwise slow bulk transfers. When this
happens it means you are testing the likely maximum throughput of your
connection not necessarily the throughput you will see more generally.

This is why Netflix started fast.com - because it draws data from the same
distribution points as their video streaming apps it means you can't
prioritise the speedtest without also doing so for the video traffic or (more
likely) you can't de-prioritise the video traffic without also getting bad
scores in that particular speedtest. From Netflix's point of view it is an
answer to people contacting support with "my speedtest results are fine, the
problem must be your servers" when they are experiencing video lag/drops and
other such problems and the issue is due to ISP traffic shaping or the ISP
simply not having enough backhaul bandwidth.

A more reliable test might be taking part in a busy public torrent: that way
you are testing against arbitrary locations so your ISP can't be setting
different shaping rules for them. Just remember to throttle upstream when
testing downstream and vice-versa or saturation in the other direction will
slow control packets that will in turn give you lower results for the one you
are testing. This may fall into another trap though: unless you limit the
number of active streams it may be an unrealistic test as more generally most
processes use a small number of streams (or just a single one), and if you
limit the number of streams too much you might get a lower result because each
swarm member you connect to may be fairly saturated and sharing its bandwidth
amongst many connections.

~~~
mholt
My free Google Fiber connection (5 Mbps down) always scored ~100 Mbit speeds
at fast.com, but was 5 Mbps on speedtest.net.

[https://twitter.com/mholt6/status/999425756198387713](https://twitter.com/mholt6/status/999425756198387713)

~~~
dspillett
I've seen similar on a 100mbit line that was actually a faster line throttled
to that speed, the effect was particularly upstream rather than down.
Essentially some content (or more likely content from some locations) is
allowed to bypass the throttle.

This might be deliberate but not malicious: through Netflix's Open Connect
program ISPs can host a local cache of Netflix content to reduce their peering
costs while still offering full service to many concurrent users. If the main
throttling effect you are experiencing is applied topologically close to their
peering lines such that it would apply to the Open Connect equipment too,
rather that the Open Connect kit setting between the throttle point and the
peering lines, then to make it useful in the case of new or otherwise not
recently accessed data the traffic shaping rules would need to let Netflix
traffic (including your speedtests) through relatively unhindered. The path
between the Open Connect equipment and your line is unlikely to need
throttling because that will be an internal matter with very different cost
dynamics than external peering.

------
dfsegoat
Surprised no-one has mentioned `iperf` on linux [1,2] for what that is worth.

It lets you roll your own speed testing infrastructure basically: Run it as a
server on one end you want to test, then run it as client against that server
IP/hostname on the other end.

It is very handy for measuring throughput between two boxes in a network (or
anywhere for that matter).

Several big ISPs have endpoints for testing it as well for a speedtest like
experience [1].

[1] - [https://iperf.fr/iperf-doc.php](https://iperf.fr/iperf-doc.php)

[2] -
[https://manpages.ubuntu.com/manpages/bionic/man1/iperf.1.htm...](https://manpages.ubuntu.com/manpages/bionic/man1/iperf.1.html)

~~~
jeanl
Iperf is really useful to test your own LAN. Didn't know you could use it to
test your ISP speed (in some cases)

~~~
KingMachiavelli
Well, you need a endpoint outside your LAN to test. But there are some public
servers[0] but not that many so it's hard to get good average speed unless you
are willing to pay for some EC2 bandwidth.

[0] [https://iperf.fr/iperf-servers.php](https://iperf.fr/iperf-servers.php)

------
virtuallynathan
speedtest-cli is _garbage_ if you have >100Mbps Speeds. The dev refuses to
acknowledge this: [https://github.com/sivel/speedtest-
cli/issues/226](https://github.com/sivel/speedtest-cli/issues/226)

Also not just me: [https://github.com/sivel/speedtest-
cli/issues/649](https://github.com/sivel/speedtest-cli/issues/649)

[https://github.com/sivel/speedtest-
cli/issues/648](https://github.com/sivel/speedtest-cli/issues/648)

[https://github.com/sivel/speedtest-
cli/issues/641](https://github.com/sivel/speedtest-cli/issues/641)

[https://github.com/sivel/speedtest-
cli/issues/616](https://github.com/sivel/speedtest-cli/issues/616)

[https://github.com/sivel/speedtest-
cli/issues/601](https://github.com/sivel/speedtest-cli/issues/601)

[https://github.com/sivel/speedtest-
cli/issues/588](https://github.com/sivel/speedtest-cli/issues/588)

[https://github.com/sivel/speedtest-
cli/issues/546](https://github.com/sivel/speedtest-cli/issues/546)

~~~
felipelemos
He locked all above issues.

~~~
metalliqaz
this project is the first time i've ever seen this kind of thing in problem
reports. i've already seen enough to stay far away from that software.

------
davewood
there is a standard package available in the debian repository

apt install speedtest-cli

Description: Command line interface for testing internet bandwidth using
speedtest.net Speedtest.net is a webservice that allows you to test your
broadband connection by downloading a file from one of many Speedtest.net
servers from around the world. . This utility allows you to use the
Speedtest.net service from the command line. . Note: This tool accesses
speedtest.net over http, while the web-based client uses websockets. This tool
has shown to become increasingly inacurate with high-speed connections. For
more information, see the readme on: [https://github.com/sivel/speedtest-
cli](https://github.com/sivel/speedtest-cli)

~~~
croon
Might concern some users:

I had an issue on my 250/250Mbps-line using speedtest-cli in that it showed
the correct download speed, but only 4Mbps upload.

Googling suggests it could be an issue with slow CPU/low RAM.

My (now old) server was by no means a beast as it had a throttled i3-3220T
with 8GB RAM, but it should be plenty fast for that task.

The solution I came across on reddit/stack was to use this [0] instead, which
solved the discrepancy for me:

[0]
[https://github.com/taganaka/SpeedTest](https://github.com/taganaka/SpeedTest)

~~~
mfontani
Indeed, my own raspberry pi was returning weird results with the python-based
one; I switched to this one and it is more consistent. I had to add an
"\--output json" option to it to not have to redo all my tooling around
tracking the speedtest results, but forgot to make a pull request to the repo,
and I've just done that: same json format as the python-based version.

~~~
walrus01
a raspberry pi 3/3b+ or whatever (not v4) should by no means be used for any
sort of speed test, not only is the wifi weak/slow but the wired ethernet
interface is also hanging off a usb2.0 bus.

~~~
Fnoord
> A raspberry pi 3/3b+ or whatever (not v4) should by no means be used for any
> sort of speed test

You make a valid point though you could test the speed of the Raspberry Pi in
question. As long as you take the caveats you mentioned into account, that's
an OK context. Which is the problem with GP's post to begin with.

------
simon_acca
maybe it's not as accurate, but on a lot of systems where wget is already
installed one can do with a lot less hassle:

wget -O /dev/null [http://speedtest-
ams2.digitalocean.com/100mb.test](http://speedtest-
ams2.digitalocean.com/100mb.test)

Nota bene:

\- change the datacenter to a closer one when appropriate.

\- Unit is MB/s, rather than Mb/s, which is more common for this kind of test

~~~
qplex
I've been using the wget method for a long time also.

I think the only downside is that you need to know what you're fetching and
from where.

Edit: And for latency, there is /bin/ping

~~~
dragondax
Can't use wget for upload speeds...

~~~
qplex
While strictly true, if you can download at link capacity it usually means the
upstream is okay too.

------
jlgaddis
A few suggestions:

1\. look into what /usr/local/{,s}bin/ and ${HOME}/.local/bin/ are for (and
how to add them to your ${PATH}, if necessary)

2\. look into why you shouldn't recommend things like "sudo wget ..." (at the
least, use "wget" followed by a "sudo mv").

------
bfred_it
For those who are more familiar with npm, there are two packages for this by
Sindre Sorhus. You can run them without preinstalling them with npx, if you
wish:

    
    
        npx speed-test
        npx fast-cli
    

The second one uses fast.com

~~~
CallMeMarc
Also speedtest-net is a great one, it also has an programmatic API.

------
teddyh
Users in Sweden might be better served by this:

[http://www.bredbandskollen.se/en/bredbandskollen-
cli/](http://www.bredbandskollen.se/en/bredbandskollen-cli/)

~~~
wwn_se
Should work fine for most of europe or at least the north. All servers are in
sweden

------
mjlee
If you need to do this, you may also need to get your external IP address from
the CLI. Two ways I like are:

    
    
      dig +short myip.opendns.com
    
      curl icanhazip.com

~~~
mlrtime
A little bit easier to remember: curl ifconfig.me

------
raldu
Run speed test with ssh and pv:

    
    
      $ yes | pv | ssh your_server "cat > /dev/null"

~~~
jolmg
You can also

    
    
      pv /dev/zero | ssh your_server "cat > /dev/null"
    

Both yours and this one check upload speed.

To check download speed:

    
    
      ssh your_server 'cat /dev/zero' | pv > /dev/null
    

or based on your suggestion:

    
    
      ssh your_server yes | pv > /dev/null
    

And if you don't have a server to login to, you can find a big file on the web
and use that to check download speed:

    
    
      curl -s http://some-place.com/big-file | pv > /dev/null
    

Though curl also reports speed, so I guess you may as well just:

    
    
      curl http://some-place.com/big-file > /dev/null

------
teekert
Hmm, it reports about a 10 times lower upload speed allthough my subscription
is 50/50 symetrical. I can confirm that I usually do get to the correct speeds
(~50 Mbit/s) when downloading things of my server... Where could this mismatch
come form?

~~~
reacweb
Maybe MB/s rather than Mb/s. The ratio is 8.

