How slow is too slow?
/Directly following on from my previous post TPG: a scourge to society, this post could be entitled
TPG: a scourge to society II. The quality of our internet connection was appalling, but TPG would not believe me. I saw this as a challenge, and subsequently set out to prove to them our connection was junk. Previously, I was monitoring if I could connect to google; however, I also wanted to monitor our internet speed. Using speedtest.net I was able to create a picture of what was happening with our connection, but the results were not entirely clear.
For anyone that has not encountered speedtest.net, it is a benchmarking service for internet connectivity, providing a range of data, but notably upload and download speeds, in addition to latency. By writing some code to execute this test periodically, I could build up a picture of what our connection was doing as a function of time.
The code
A repository of the code can be found here. It is written in python and makes use of the speedtest module to get the results of a speedtest and write them to a .csv for analysis. This is scheduled to run done every 10 minutes, which over the course of 6 months will generate a 30 mb .csv file. The analysis is done in a jupyter notebook but is very straightforward.
The results
The simplest thing to do was to look at the average upload and download speeds over an extended time period. Given the density of the data, it was down sampled such that a single point represents the average speed over a 12-hour period.
Looking at the plot, there are a few notable features. Firstly, it is clear that there are some discontinuities, the largest of which is over a month, whereby the code was not running. Secondly, it is clear that there is a high degree of correlation between upload and download speeds, especially for the the “dips” in connection quality. An interesting trait of the download speeds are the plateaus of connection speed, with discrete jumps occurring from time to time, altering the average achievable download speed.
The next thing I thought might be interesting to look at was the speed of the internet connection as a function of hour, as I suspected there would be a clear dip in quality in the evening. Even though we were on ADSL 2+, it was my experience that the internet was less reliable between 1800 and 2200.
Shown above are plots which show the likelihood of measuring a given speed as a function of the time of day, with a dark shading meaning the result is less likely. Unsurprisingly, there is a large band of “stable” connection speed across all hours, but it is more fruitful to look at the uncommon areas. For example, one can see that from 0500 until 1400, it is highly unlikely that bad upload speed would be measured, however after about 1500 this changes until about 2200. The download speeds paint a slightly less clear picture, but overall show more stability; notably the individual plateaus of speed are visible.
The plot above shows a similar visulisation; however now the data are shown on a wheel depicting the time of day and week. My hypothesis was that one would be able to see a decrease in the quality of internet on Friday nights, potentially also on the weekends. What is interesting is that the decrease on a Friday night is clear, but the quality of internet on the weekend is much higher, potentially due to limited commercial usage. Once again, the plateaus in download speed are clearly visible, but also the relative stability in download speed as compared to upload speed.
In the end, there was not much I learned from this data that I didn’t already know: our internet quality was bad, especially our upload speeds. It is nice to see it borne out visually, but it doesn’t give me back the lost hours of waiting for things to upload…