1. Not exactly an answer, but conceptually relevant:
Your ISP is selling you a speed from your house to their border router situated at the edge of The Internet. Your ISP has no control over what happens to your packets once they're out 'mongst the tubes.
The metrics you're describing are actually tracking latency between servers well outside your provider's network. Information like that is not at all relevant to the speed your provider is selling you, and can easily be obtained at places like internettrafficreport.com.
I assume the software you're describing was always meant for people managing networks, and not for end users who would confuse latency with last mile speed performance as you have.
2. Not a software solution, but still a way to get the information you want:
To test the health of your connection, run a tracert to some random server on the internet. Find the last hop on your provider's network: that's their border router, and the last point over which they have any control. Run a ping -t to that IP for up to a week: there's your real last mile performance metric.
If you're on a shared resource like cable, expect packet loss during peak hours (when everyone's online) and bursts of awesome performance when all your neighbors are at work or asleep. If you're on a private connection like DSL, expect a fairly uniform response over time.
3. A way to approach your provider with information they'll listen to:
If you think you're not getting the speed you're paying for, find your provider's own speed test (it will be on a server on their network and not out on the internet like the speed tests you mention). Perform this test ten or fifteen times over the course of a week. Calculate the average of all these tests.
Your final number should be roughly ten percent under the speed your provider sold you. (The missing 10% is protocol overhead.) If the end result is much lower, contact your provider and have them fix the problem.
Command line interface for testing internet bandwidth using speedtest.net.
https://github.com/sivel/speedtest-cli
speedtest-cli works with Python 2.4-3.4
wget -O speedtest-cli https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
chmod +x speedtest-cli
$ speedtest-cli -h<br>
usage: speedtest-cli [-h] [--bytes] [--share] [--simple] [--list]<br>
[--server SERVER] [--mini MINI] [--source SOURCE]<br>
[--version]<br>
optional arguments:
-h, --help show this help message and exit<br>
--bytes Display values in bytes instead of bits. Does not affect<br>
the image generated by --share<br>
--share Generate and provide a URL to the speedtest.net share<br>
results image<br>
--simple Suppress verbose output, only show basic information<br>
--list Display a list of speedtest.net servers sorted by distance<br>
--server SERVER Specify a server ID to test against<br>
--mini MINI URL of the Speedtest Mini server<br>
--source SOURCE Source IP address to bind to<br>
--version Show the version number and exit<br>
Best Answer
That is a known problem, I had to talk to my ISP multiple times over 3 weeks in order to convince them that something is off with the connection. My solution was to automate speedtests so that they run every 30 minutes using a docker container made by Henry Whitacker. Set is up on a raspberry pi, an old laptop or a NAS, and let it run for a week. After that you have a very good base of measurement data to show your ISP. It even is presented in a way any normal person can understand so you don’t need to find someone more competent than the last time.
To set it up, follow the instructions on the GitHub page, I recommend using docker-compose as it is much easier than anything else. If you want to have a look at it first, there is a running demo version on Henry Whitacker‘s personal website here.