Internet providers caught inflating speed test results

A work colleague in the UK called me one day to say that his ISP Pulse8 Broadband installed their Fibreoptic service at his house. He went for their 38Mbps package, but suspected wasn’t getting the full speed and asked for my advice on testing his connection. Like most ISPs, Pulse8 recommended checking his speed with its speed test on the Pulse8 website. This speed test is powered by Ookla, the company behind the well-known website.


Personally I prefer the TestMy speed test service for a number of reasons. It performs its test by measuring the time it takes for one or more blocks to download or upload, just like timing a download or upload with a stopwatch to work out its transfer speed. It also runs its test over a single connection to the server, just like streaming or downloading a large file.

So I asked him to run a few download and upload tests through using their UK server, to see how its test results compare. He came back to me saying he is only getting about 4.5Mbps on TestMy’s download test compared to around 20Mbps with both Pulse8’s website speed test and I asked him to this time try a multithread test on TestMy, but that only delivered 7.4Mbps. While I was on a VoIP call to him, that multithread test severely degraded the VoIP call quality which did not happen when running a test on, so TestMy was clearly maxing out his downlink bandwidth despite its lower test result. This got me thinking – Just what is doing differently with his connection to achieve around 20Mbps and without even affecting the VoIP call quality?

As explained in the first post of this thread, Ookla’s uses a rather complex testing process, so in theory, the ISP could fiddle with the traffic flow to trick the speed test into delivering an inflated figure. One important point mentioned is that makes multiple connections (also called threads) to the server. Straight away, this has the potential to deliver a much higher result than let’s say streaming video where most video on demand services only make a single connection to their content server. As I mentioned already, he got 7.4Mbps down in the TestMy multithread test, which is significantly higher than the 4.5Mbps result in the standard TestMy result, but still well short of what reported.


So I decided just to see what happens when runs its test using TCPView. Notice the port number. This port number remained the same, test after test, across multiple server locations:

Ookla is using port 8080

Most web browser based traffic is carried over TCP ports 80 and 443. Port 80 is used for standard HTTP traffic such as websites and file downloads. Port 443 is used for secure HTTPS traffic such as online banking and even video streaming websites such as YouTube where the data is encrypted. There are many other well known ports such as UDP port 53 for domain name look-ups, TCP ports 25 and 110 for e-mail, and TCP ports 20 and 21 for FTP access. However, what about TCP port 8080?


Back in the early days of Internet, port 8080 was commonly used for web caching servers to offer improved browsing performance for dial-up users, particularly for popular websites where frequently accessed webpages are stored in the ISP’s cache. Nowadays, port 8080 is rarely used for real-world traffic apart from operating proxy servers such as inside a company Intranet. So what happens if port 8080 is blocked, such as by a company firewall policy? Speedtest will run its test over port 80, which is http:

Ookla uses port 80 when port 8080 is blocked

So I thought – let’s ask TestMy if they could provide the ability to test over port 8080 to see if there is any speed variation from the standard port with its test service. They had the feature implemented within a day.

Let’s head to the next page where we see how an ISP should not behave…

No posts to display