Peak time performance is a key issue for people on broadband and it is actually one of the factors that sets apart low cost consumer broadband from leased line connectivity, i.e. on low cost services you don’t expect to see 1:1 contention at all times. In a previous decade contention ratios where published but as unbundled services took off and faster ADSL speeds became the norm these vanished and almost any provider showcasing contention ratios on consumer products is doing it wrong.

We looked at peak time speeds back in June 2015 so we figured it was time to look at them again for the month of September 2015. The methodology has not changed in that time, but we are seeing broadband speed and coverage a lot more in the main stream press and that has meant some very large bursts of people using the speed test, this is usually reflected by lots of anonymous testers while our registered users who are still using our older flash based test never seem to rush to speed test.

We have looked at upload speeds too but nothing unusual seems to be going on, i.e. upload speeds are almost unaffected by the time of day, reflecting the reality that the while for some people upload speeds are critical for the majority of people demand for access to data invariably in the form of video streaming and OTT TV are the critical activity. Online gaming with services like Twitch TV is slowly changing that but that is still a fairly small niche.

So first the results from our single thread testing, which is much more sensitive to issues of congestion and other factors like RWIN, though as this test is usually only visible to our registered users it is likely they have gone through the checking their broadband and computer setup before. A web based single thread speed test is available and any tests from that version are also included in the data, so for those that have removed Flash already they can contribute to future data, or investigate result oddities.

If using this data to compare providers the ratio of customers on the various speed tiers they sell means you cannot use these figures to say BT is faster for any single line than say PlusNet, what the data is showing is the difference between peak and off-peak speeds overall. Even within providers there can be large regional variations in performance too.

Single Thread Median Download Speeds for Providers in September 2015
Provider Daytime (Off-Peak)
7am to 3pm
3pm to 6pm
Evenings (Peak)
6pm to midnight
Daytime/Evening Change
BT 19.1 Mbps 21.8 Mbps 18.2 Mbps -4.7%
PlusNet 16.8 Mbps 13.0 Mbps 19.7 Mbps +17.3%
Sky 14.4 Mbps 12.8 Mbps 12.5 Mbps -13%
TalkTalk 10.1 Mbps 9.9 Mbps 10.9 Mbps +7.9%
Virgin Media 49.1 Mbps 37.7 Mbps 37.8 Mbps -23.1%
Single Thread Mean Download Speeds for Providers in September 2015
Provider Daytime (Off-Peak)
7am to 3pm
3pm to 6pm
Evenings (Peak)
6pm to midnight
Daytime/Evening Change
BT 24.6 Mbps 23.7 Mbps 25.8 Mbps +4.9%
PlusNet 24.8 Mbps 20.9 Mbps 24.9 Mbps +0.4%
Sky 16.2 Mbps 24.4 Mbps 16.2 Mbps 0%
TalkTalk 15.5 Mbps 14.2 Mbps 17.5 Mbps +12.9%
Virgin Media 57.9 Mbps 47.6 Mbps 45.8 Mbps -20.8%

What is interesting is that since June TalkTalk seems to be performing better at peak times rather than off-peak, the sample sizes for registered users running the tests are fairly small so sample size might explain the variation. We could create a system to monitor those who are regular users of the speed test, but this runs the risk of creating a self selecting sample.

The real test is whether our multi-thread test which is the main test we run for all our speed test visitors and partners that use our testing technology shows a similar pattern. Multiple test threads are designed to mitigate effects like RWIN size and congestion from local Wi-Fi issues and should also help with congestion at the ISP level. So the same four providers, but with the addition of EE as we have a better sample size.

Multiple Thread of Average Median Download Speeds for Providers in September 2015
Provider Daytime (Off-Peak)
7am to 3pm
3pm to 6pm
Evenings (Peak)
6pm to midnight
Daytime/Evening Change
BT 13.4 Mbps 14.2 Mbps 13.5 Mbps +0.7%
EE 6.8 Mbps 6.7 Mbps 6.3 Mbps -6%
PlusNet 10.9 Mbps 10.1 Mbps 11.0 Mbps +0.9%
Sky 8.7 Mbps 8.9 Mbps 8.6 Mbps -1.1%
TalkTalk 7.7 Mbps 7.2 Mbps 7.4 Mbps -3.9%
Virgin Media 43.6 Mbps 41.4 Mbps 33.8 Mbps -22.5%


Multiple Thread Mean Download Speeds for Providers in September 2015
Provider Daytime (Off-Peak)
7am to 3pm
3pm to 6pm
Evenings (Peak)
6pm to midnight
Daytime/Evening Change
BT 19.7 Mbps 19.8 Mbps 19.2 Mbps -2.5%
EE 11.4 Mbps 11.7 Mbps 10.6 Mbps -7.1%
PlusNet 18.3 Mbps 17.4 Mbps 17.8 Mbps -2.7%
Sky 12.9 Mbps 12.9 Mbps 12.5 Mbps -3.1%
TalkTalk 13.1 Mbps 12.5 Mbps 12.9 Mbps -1.5%
Virgin Media 50.9 Mbps 47.9 Mbps 40.8 Mbps -19.8%

The presence of EE from our main tester shows the difference that FTTC is making to the speeds for BT, PlusNet, Sky and TalkTalk users, EE has the smallest proportion of users on the VDSL2 based service.

The consistent provider throughout the tables is Virgin Media who show a 20% speed drop at peak times almost no matter how we present the data. Of course with an mean speed of 40 Mbps at peak times you should in theory still have more than enough capacity for a UHD video stream, but this all depends on how the provider manages the congestion, e.g. if packet loss and jitter increases at peak times the evil spinning buffering wheel may show up.

The means and median while useful often mask the upper and lower speeds and so we are showing for the first time the figures for the slowest 10% and fastest 10% at peak and off-peak times of day.

Multiple Thread Download Speed Range for Providers in September 2015
Provider Off Peak Slowest 10% Off Peak Fastest 10% Peak Time Slowest 10% Peak Time Fastest 10%
BT 1.4 Mbps 43.1 Mbps 1.4 Mbps 41.3 Mbps
EE 1.8 Mbps 35.9 Mbps 1.1 Mbps 28.8 Mbps
PlusNet 1.4 Mbps 44.5 Mbps 1.5 Mbps 41.3 Mbps
Sky 1.6 Mbps 31.0 Mbps 1.2 Mbps 30.2 Mbps
TalkTalk 1.7 Mbps 34.7 Mbps 1.6 Mbps 34.0 Mbps
Virgin Media 10.9 Mbps 106.1 Mbps 5.7 Mbps 86.8 Mbps
Off Peak and Peak Mean Latency for Providers in September 2015
Provider Off Peak Latency Peak Time Latency
BT 111 ms 111 ms
EE 141 ms 151 ms
PlusNet 101 ms 101 ms
Sky 110 ms 120 ms
TalkTalk 117 ms 124 ms
Virgin Media 69 ms 89 ms

We should point that our latency measurement is deliberately not called ping, because it does not use ICMP Echo packets but a small TCP packet so while the absolute figures are often not as low as a standard ping they do mirror the rise and fall of overall latency on a connection.

Hopefully this wealth of data will help people to get a better idea of how they are performing relatively and also show that while broadband overall is getting faster, the age of reason for consumer broadband being cheap which is the shared nature of the backhaul networks has not vanished yet. The key part is whether providers manage their network capacity so that it keeps as people as possible happy.

To give you an idea of how things have changed the fastest 10% of users on BT in April 2010 saw speeds of just 6.4 Mbps in the evening and the best 10% at Virgin Media was 13.5 Mbps.

6 Responses

  1. tommy45 on 24 Oct 2015

    I would seriously doubt that actual throughput rates would be higher during peak times than all other times of any day

    Like the oddities in your results for both BT and Plusnet

    It’s more likely that these results are down to those with higher IP profiles /sync rates carrying out speed tests at peak times or those who are using Ethernet cables, and aren’t using the internet for anything else at the time they ran the speedtest, also different browsers can affect the results
    To many variables for the above results to be taken with any more than a pinch of salt, so pointless realy

  2. John B Lee on 26 Oct 2015

    I am with Virgin Media and I am getting a much poorer peak period perfrormance than in the above figures. Up to April I was getting 45 to 55 Mbps off peak and 25 to 45 Mbps at peak times. Since April this year the peak figure dropped to 5 to 10 Mbps. I raised the problem with Virgin and was told that the problem would be reviewed at the end of April. This date passed without any improvement ad a new review date was set in October. I have today been given a new review date in March 2016. There is an admitted capacity problem in my area and nothing is being done to address this. Meanwhile I pay fibre price for wired performance.

  3. Neil McRae on 26 Nov 2015

    you forget that some of the providers above have multi-service networks that do different things and have different concurrencies during different periods of the day…

  4. Just a bloke on 10 Dec 2015

    Well I wish my Virgin connection only dropped 20% at peak. I see variations between 2 and 160 on my 150 Mb connection.

  5. Chris Conder on 06 Jan 2016

    just done a speed test on my connection, and it is no different at peak times. Your tester didn’t measure past 100 meg so I couldn’t make it work, so have done one on dsl reports where they can measure a lot higher.

    • andrew on 06 Jan 2016

      Have hunted high and low for a B4RN speed test done just now and cannot find one. Most recent we can see is if you believe tests are not logging correctly, then you need to let us know the results link after the test has finished so we can backtrack into the results database.

      As for your speeds, did mention in the news comments that there are suggestions that something is congested and I am sure it is not us, based on what I can see of OUR network and also what others are testing at.

      Your test from earlier today has a tbbx1 result that is lower than the HTTP, and this happens when a connection is busy doing something else, or a link is congested. If we increased the number of simultaneous files to the 32 or 24 of the other tester this would probably flood the connection, but there should be no need for some many simultaneous downloads to saturate a 1 Gbps connection.

      Another gotcha with your tests is that the latency looks unduly high, and while Lancashire is not on the door step of London we would expect latency on FTTH to be a lot lower than the 35ms to 100ms you are demonstrating for TCP small packets.

      From running a tracert to various B4RN connections there is a suggestion that something may be congested on a network segment run by since it should not take 30ms for data to travel from London to Manchester.