» ISP News » 

Ookla Accuses UK Broadband ISP of Manipulating its Internet Speedtests

Wednesday, January 27th, 2016 (10:39 am) - Score 8,592

Ookla, the company behind the popular Speedtest.net service, has accused a broadband ISP in the United Kingdom of “intentional manipulation” by “prioritizing port 8080” Internet traffic in order to return a better performance result for their subscribers. But the reality may be more complicated.

The ISP in question is a smaller provider called Pulse8 Broadband, which has been steadily growing in popularity thanks to its “no contract” approach to FTTC and ADSL based broadband services. However the ISP now finds itself at the centre of a debate over whether some broadband providers are actively manipulating Internet speed testing services.

The situation first came to light after an article on Myce.com (formerly CDFreaks.com), which normally focuses on matters related to digital storage products, spotted that a customer of Pulse8’s FTTC (“Fibre Broadband“) service appeared to be receiving a much more positive result via the ISPs own speedtester (here) than when using the independent TestMy service.

The speedtest on Pulse8’s website is powered by Ookla and upon further inspection Myce.com claimed that the ISP’s test appeared to be prioritising traffic to TCP port 8080, which over the years has been used for all sorts of services from HTTP webcache to multiplayer games and remote web cams.

By comparison most web browser (HTTP) based traffic is usually carried over TCP port 80 or 443 and some tests prefer to use that, although we’ve also seen testers use TCP port 8095 and various others. Ookla itself claims to make use of TCP port 80, although after a quick search we also note that they’re familiar with 8080 (here and here).

Never the less Myce noticed that tests run via the Pulse8 connection on ports 8080 and then 80 via the TestMy service were returning different results. On port 80 the customer would return a result of 4.6Mbps download and 5.7Mbps upload, which suddenly jumped to 6.8Mbps download and 8.2Mbps upload when using port 8080 (consistent over several tests).

Seán Byrne, Myce Author, said:

Straightaway, it’s pretty obvious that the port 8080 test is performing better than the plain HTTP based test. So then I asked him by e-mail to run a multithread test with a fixed 50MB block size and to repeat the multithread test by accessing the website over port 8080. He ran these with his laptop connected directly to his router with an Ethernet cable. By using the same 50MB block size and test server, this is the equivalent to testing the maximum speed of two cars on the same test strip over the same distance.”

The result for the multithread test returned a download speed of 6.5Mbps for port 80 and 38.6Mbps for port 8080. Quite a difference. “So it is obvious that either his ISP or the TalkTalk Wholesale network it resells has given port 8080 special treatment,” said Seán Byrne.

A similar issue was also discovered with another ISP in the USA (Ziggo) and some non-UK mobile operators. However it’s worth noting that the same problem was NOT observed when the tests were conducted on other UK ISPs (e.g. BT Broadband, Sky Broadband and TalkTalk), which all appeared to behave themselves.

However we feel that testing with a single customer’s connection isn’t really enough to support the accusations being made by Myce. Similarly we’re not told any details about the customer’s line, such as what their VDSL profile details are (crucial to establish some context).

Likewise no tests were performed with other speed testing services outside of those mentioned and no direct download tests were performed to test the connection in different environments. Furthermore we would have liked to see the tests performed on different computer hardware, both wired and WiFi etc. It’s also unclear what time of day the tests were performed as this too can be impacted by changes in traffic (peak vs off-peak periods).

In fact there could be any number of reasons why a specific line might return an unusual result (e.g. firewall rules, capacity related problems or traffic management measures etc.), which is why it’s important to test with more than a single customer’s connection. On the other hand the situation has attracted a strong response from Ookla, which seems to agree with Myce.

An Ookla Spokesperson said:

The accuracy of Speedtest results are paramount to Ookla, and we take seriously any attempt to manipulate those results. We have begun looking further into the ISP mentioned in your article, and it does appear that they prioritizing port 8080. Whenever we discover intentional manipulation we work to correct it as well as ensure it does not occur again in the future.

Speedtest does employ measures to prevent manipulation and have new mechanisms coming online soon to further combat this. Luckily, only a handful of the tens of thousands of ISPs worldwide attempt this. Regardless, we never want to see ISPs attempting to manipulate results; this only misleads customers to the actual performance they’re receiving.”

ISPreview.co.uk decided to get in contact with Pulse8 and the ISP responded to say that they were surprised by the news. According to Pulse8, the speedtest on their website uses an iFrame (takes the content from a remote server) to load from the http://www.supportal-test.co.uk site, “which our Back Haul Provider provides so we can record results against customers speedtests.” A quick check shows that the supportal-test.co.uk domain is indeed registered to TalkTalk.

Pulse8 claims that in the past couple of weeks they’ve actually had the opposite happen, with some of their FTTC customers allegedly complaining that the test was returning consistently slower performance than other speedtest sites and as yet they have not identified the cause. The ISP has promised to contact their provider in order to find out what is happening.

In the meantime we are continuing to investigate and have liaised with some other speed testing services to see if we can examine the problem on a wider scale, although no doubt if any manipulation has occurred then ISPs may be quick to stamp it out before we can get any results. Still we would urge caution in laying the blame at Pulse8’s feet as Myce have done, particularly as the test is run off a site owned by TalkTalk, which Pulse8 does not appear to control.

Share with Twitter
Share with Linkedin
Share with Facebook
Share with Reddit
Share with Pinterest
By Mark Jackson
Mark is a professional technology writer, IT consultant and computer engineer from Dorset (England), he also founded ISPreview in 1999 and enjoys analysing the latest telecoms and broadband developments. Find me on Twitter, , Facebook and Linkedin.
Leave a Comment
12 Responses
  1. RLP says:

    The Ookla tests should never be relied upon for accurate results anyway. You should only use them as a guide to the potential performance with the setup that you are testing with.

    Change the computer, how it is connected to your router or even perform the tests at a different time of day and the results will change.

    Simply by performing the test via WiFi and then Ethernet will produce a different result in many cases, especially with a Fibre based connection.

    1. DanielM says:

      they are if not the most reliable for testing.

      and i can confirm this does happen on talktalk network (having been on utility warehouse broadband package)

  2. Dragon says:

    “The accuracy of Speedtest results are paramount to Ookla” – Really so like some of their hosts testing over IPv6 when displaying the IPv4 address (which in the case of tunneled V6 connectivity leads to an incorrect result)

    Or in the event of a load balanced connection it showing the result under one of the IP’s attributing to the wrong provider?

  3. Graeme says:

    I agree ISP’s manipulate the tests and flood the connection to hide congestion, I got full speeds when testing when I was with talktalk then when I used think broadband speed test it showed the true speed

  4. Chris Phillips says:

    if the speed test site is hosted by the ISP the speed would likely be higher as no need to go over expensive contended off net connections.

  5. Skilty says:

    I think people are missing the point. The issue is that Ookla uses a multi-threaded test i.e. more than one connection to pump the test data down. When you see these “amazing” speeds it is because they have saturated your connection. If you use the ThinkBroadband or TestMy test it shows you single threaded and multi-threaded results. Even the SamKnows reporting shows multi-threaded and not single threaded.

    Comparing a mult-threaded to single threaded test result is pointless.

    “By using the same 50MB block size and test server, this is the equivalent to testing the maximum speed of two cars on the same test strip over the same distance.”

    That would depend on when (how far apart) the tests were run and even how the data was routed as you are not in control of the bandwidth available via the backhaul or the route the data takes etc.

  6. Ignition says:

    An ISP with no control whatsoever over the network its subscribers use manipulating speed tests. That’s one hell of a trick.

    As far as accuracy being paramount to Ookla, hmm. A lot of people like Ookla tests as they give higher results than, say, ThinkBroadband. I prefer accurate over high for epenis enlargement. If they were concerned about accuracy they wouldn’t allow hosts to set the number of upstream and downstream threads.

    Is it really that much of a shock if a speed tester hosted by the ISP and load balanced with local caches produces higher results than ones that are offnet?

    PING http://www.supportal-test.co.uk ( 56(84) bytes of data.
    64 bytes from host-78-144-7-18.as13285.net ( icmp_seq=1 ttl=60 time=6.48 ms
    64 bytes from host-78-144-7-18.as13285.net ( icmp_seq=2 ttl=60 time=6.58 ms
    64 bytes from host-78-144-7-18.as13285.net ( icmp_seq=3 ttl=60 time=6.62 ms
    64 bytes from host-78-144-7-18.as13285.net ( icmp_seq=4 ttl=60 time=6.70 ms
    64 bytes from host-78-144-7-18.as13285.net ( icmp_seq=5 ttl=60 time=6.49 ms

    PING cs62.adn.xicdn.net ( 56(84) bytes of data.
    64 bytes from icmp_seq=1 ttl=58 time=12.2 ms
    64 bytes from icmp_seq=2 ttl=58 time=12.0 ms
    64 bytes from icmp_seq=3 ttl=58 time=12.1 ms
    64 bytes from icmp_seq=4 ttl=58 time=11.8 ms
    64 bytes from icmp_seq=5 ttl=58 time=12.0 ms

  7. The thinkbroadband non-flash tester can do single thread, and we tend to only give the URL when people come chasing issues or looking for diagnostic help, but for those interested

    Single thread over HTTP 80

    Single thread over SSL HTTP 443

    Standard multiple thread

    SSL Version

    When using the single thread version it is even more important to not be using wireless.

    Having run a few TestMy tests none of which get close to my actual speed (a mere 14.1 Mbps) and monitoring network interface shows that there may be issues with their bandwidth or the test.

  8. cyclope says:

    Testing using your non flash tester gives poor upstream results that are woefully inaccurate and they always have been the flash based test provides a near accurate result and that too has a single threaded mode, when it comes to HMLT5 ect browsers and o/s can play a bigger part in what results you see,

    Using the speedtest.net tester i get fairly consistent results from the servers that i select, and pulse8 speedtester gives a very similar result to that of the speedtest.net servers, and when compared to actual download/upload speeds, all are quite close on the downstream, but tbb non flash tester is no where near on the upstream it’s on a par with the BTW speedtester

    1. Chris C says:

      Just because a result is low it doesnt mean its inaccurate.

      The test is testing a number of things.

      Your comouter configuration e.g.l rwin and swin size.
      Your netowrk setup e.g. wireless stability. Homeplug quality.
      Your connection to your isp. This includes of course affect of sync speed as well as contention.
      The quality of the transit/peering used between your isp and the test server.
      The test server itself.

      In the case of flash vs html5. Sme flash testers are known to have inadequate buffer sizes which ignore the client’s window preference, whilst html5 will honour the rwin size sent by the client.

  9. cyclope says:

    Well it doesn’t give accurate results for me,i don’t use wireless and there isn’t any problem with sync or isp, And my evidence ain’t based on speed testers alone, because i know what throughput the connection is capable of

  10. Olorin says:

    This has gotten a little out of hand. It has ABSOLUTELY NOTHING to do with the testing service being used, HTML5 or Flash or nil.

    “…the TalkTalk Wholesale network it resells has given port 8080 special treatment”

    No, my lovely, it’s actually the opposite. Port 80 is given the ‘special treatment’ as it is routed through traffic management hardware and web caches. Port 8080 simply passes through or avoids this hardware.
    Port 8080 is not given any special treatment, but in fact, performs natively of the speed of the connection. Port 80 sometimes may not do so, depending on network load (including your own line) and the type of traffic.

    I understand a lot of people face frustration over network management and driving cost savings, but for me personally, I have never experienced a ‘problem’ caused directly or even indirectly by this, so it does not bother me at all.

Comments are closed.

Comments RSS Feed

Javascript must be enabled to post (most browsers do this automatically)

Privacy Notice: Please note that news comments are anonymous, which means that we do NOT require you to enter any real personal details to post a message. By clicking to submit a post you agree to storing your comment content, display name, IP, email and / or website details in our database, for as long as the post remains live.

Only the submitted name and comment will be displayed in public, while the rest will be kept private (we will never share this outside of ISPreview, regardless of whether the data is real or fake). This comment system uses submitted IP, email and website address data to spot abuse and spammers. All data is transferred via an encrypted (https secure) session.

NOTE 1: Sometimes your comment might not appear immediately due to site cache (this is cleared every few hours) or it may be caught by automated moderation / anti-spam.

NOTE 2: Comments that break our rules, spam, troll or post via known fake IP/proxy servers may be blocked or removed.
Cheapest Superfast ISPs
  • Vodafone £19.50 (*22.50)
    Speed 38Mbps, Unlimited
    Gift: None
  • NOW £20.00 (*32.00)
    Speed 36Mbps, Unlimited
    Gift: None
  • Hyperoptic £20.00 (*25.00)
    Speed 50Mbps, Unlimited
    Gift: Promo Code: HYPERFALL21
  • Shell Energy £21.99 (*30.99)
    Speed 35Mbps, Unlimited
    Gift: None
  • Plusnet £22.00 (*38.20)
    Speed 36Mbps, Unlimited
    Gift: £70 Reward Card
Large Availability | View All
New Forum Topics
Cheapest Ultrafast ISPs
  • Gigaclear £24.00 (*49.00)
    Speed: 300Mbps, Unlimited
    Gift: None
  • Vodafone £24.00 (*27.00)
    Speed: 100Mbps, Unlimited
    Gift: None
  • Community Fibre £25.00 (*27.50)
    Speed: 200Mbps, Unlimited
    Gift: None
  • Hyperoptic £25.00 (*35.00)
    Speed: 150Mbps, Unlimited
    Gift: Promo Code: HYPERFALL21
  • Virgin Media £28.00 (*52.00)
    Speed: 108Mbps, Unlimited
    Gift: None
Large Availability | View All
The Top 20 Category Tags
  1. FTTP (3568)
  2. BT (3023)
  3. Politics (1940)
  4. Building Digital UK (1929)
  5. FTTC (1888)
  6. Openreach (1837)
  7. Business (1692)
  8. Mobile Broadband (1480)
  9. Statistics (1410)
  10. FTTH (1365)
  11. 4G (1277)
  12. Fibre Optic (1174)
  13. Virgin Media (1172)
  14. Wireless Internet (1162)
  15. Ofcom Regulation (1149)
  16. Vodafone (846)
  17. EE (835)
  18. 5G (772)
  19. TalkTalk (769)
  20. Sky Broadband (747)
Helpful ISP Guides and Tips

Copyright © 1999 to Present - ISPreview.co.uk - All Rights Reserved - Terms , Privacy and Cookie Policy , Links , Website Rules , Contact