Tracking my Internet with a Raspberry Pi (Part 2)

I've been having Internet trouble.

In part 1, I set up a regular ping and speed test on a Raspberry Pi using cron and the Ookla Speed test CLI. After running it for just under 24 hours, I saw enough to be concerned, so I dug a little deeper.

More Testing!

I'm in a Teams chat with a bunch of other Microsofties based in Australia. Topics range from PC builds to software architecture to Lego to (of course) Internet performance.

Given it's a chat full of software developers, we predictably explored how to dramatically over-engineer a solution for testing an Internet connection before paring it back to something a bit more reasonable.

In short, after a bit of hacking around with Python, I now have a script that does a simple HTTP GET request every few seconds.

The source is here, under an MIT license. Feel free to submit a PR!

More Results!

There were three tests running over the weekend. The ping and speed test from about 9:45am Thursday and the HTTP test from about 10:50am Friday. All three finished at around 2:45pm Sunday (the Pi seemed to freeze after that... I should probably look into that particular issue). The tests were:

  • A 65kB ping to my provider's website every 1 minute
  • An Ookla Speed test via the CLI every 10 minutes
  • An HTTP GET to my provider's website every 10 seconds (about 108kB)

I won't bore you with the raw data, but the graphs below show the results. The tests started and finished at slightly different times, but I've tried to line up the graphs... believe it or not.

Three graphs showing regular pings, speed tests, and HTTP GET requests. Observations are described below.

Some observations:

Just by looking, there seems to be very little correlation between a failed ping, a slow speed test, or a slow HTTP GET.

Pings seem to fail in blocks, while performance drops with the speed test and HTTP GET seem far more regular.

Pings either fail completely, or return fairly quickly. Meanwhile, there's a huge variation in response times in the speed test and HTTP tests. The best performing speed tests are over 100 mbps (which is great), but there are plenty in the 50-60 mbps range. HTTP responses are most commonly 200-300 ms, but there are plenty that take a second or more.

So, what now?

Now I speak to Aussie Broadband again. I'm hopeful something will come of it - they've been excellent in the past - but there's always a very good chance NBN will take a look and decide that data looks fine to them. Fingers crossed again.

Damian Brady

I'm an Australian developer, speaker, and author specialising in DevOps, MLOps, developer process, and software architecture. I love Azure DevOps, GitHub Actions, and reducing process waste.