The latest version of our Flash based speedtest actually gives six speed results, four for download and two for upload. At the simplest level the figure you should normally quote is the Avg (Average) HTTP x6 figure.
The average TBB figure is what our testers have previously shown, a new innovation for 2013 is to display the burst figure.
The custom test is based around the speedtest protocol that we have run for some years, this is sometimes managed as peer to peer traffic by providers due to its unknown protocol by some providers and its use of TCP socket 8095.
The HTTP testing uses the standard HTTP protocol for the file transfer and this protocol is normally not managed by any provider. The HTTP test also carries out six downloads at the same time, this can on faster connections result in a faster throughput, particularly in cases where the computer has a small TCP Receive Window (RWIN).
This is referring to the fact that the HTTP test is based around six downloads running at the same time. The use of six downloads should improve the saturation of the connection and give a result closer to the absolute maximum possible on your connection.
By using so many connections it also helps guard against a single email or two skewing the results.
Our old speedtest (custom) generated data dynamically for download, which meant the time for each test varied widely, and if the pre-test gave a false result the size of the payload would sometimes be inadequate to test the connection properly.
Testing for a fixed period of time, allows the software to cope with a very wide variation of connection speeds.
If graph plot is very flat, it is possible that there is no discern-able burst speed, so the average will be used. This indicates that the connection was running flat out during the test.
One small change is that we have adopted the same use of 1,000 for kilo in calculations which is common across other speed testers. This can account for an approximate 5% increase in the result.
We are still working on further changes to how the flash speed test results are handled, but we have added a simple graph that logged in users can view at View Flash Speed Test Results as Graph.
The lines plotted represent your life time average for all the results, so should trend up and down depending on how the speed test results vary.
We will be allowing users to link the Flash results with connections they have defined in the near future.
There are two options for mobiles and tablets or any other device that does not use flash.
We have a new speedtest that is in its final beta stages and is available at labs.thinkbroadband.com/ispa. This new test should run on most modern browsers such as those on the iPhone and most Android devices.
If you have an android phone there is our dedicated Android application that will work on most Android devices and keep a local database of your results.
Ideally we would like people to provide a postcode and the name of the ISP they are using, as this will allow us to plot the results on maps.thinkbroadband.com.
If you do run a test and supply the postcode and ISP, it should be noted that the map page only updates once every 24 hours.
The HTTPx6 test checks to make sure all the threads have started and if not it will re-start.
This failover is also intended to ensure we can reliably test across multiple networks in the future.
The two small PNG files that show your results can be referenced by the URLs shown after the test for a good many weeks. We endeavour not to delete them, but occassionally for we may need to, particularly if we see a high volume of tests. Therefore if you are wanting to keep the images as evidence for your broadband provider we suggest saving the images to local storage.
In the first four weeks of the new speed testers life (until 14th March 2013) we were not plotting the speeds on our maps. As of the 14th March we pushed the backlog of results out to maps.thinkbroadband.com.
Results are added over night, so it can take up to 24 hours for an individual result to appear.
We have identified a problem with Flash on the Mac OSX operating system when using the Safari or Firefox browsers, which means the tbb custom protocol is capped at around 12.5 Mega bits per second (Mbps).
We advise people to use Google Chrome on OSX as this does not exhibit the problem.
This issue does not show up on many speedtesters as they rely on the standard HTTP protocol, but we have found other people using sockets in Flash report problems with throughput.
Some implementations of Linux also appear to have speed limits on throughput when using raw sockets.
An alternative would be to run our new beta test that does not use flash which is running at labs.thinkbroadband.com/ispa.
We released the tester initially with a modest two threads for the HTTP test, and after looking at many tests carried out over the first day or two, decided that for some connections more threads were needed to flood the connection with sufficient data to give the highest possible speeds.
There are many possible reasons, but the most likely issues are that the connection or the provider is experiencing contention. The HTTPx6 test by making six data requests can flood your broadband connection, where as a single download will go through more peaks and troughs if your ISP is busy, or something else is using your connection.
Another possibility is that your computer may be ramping the TCP RWIN size very slowly, or it is set too low. The multiple requests of the HTTPx6 method help over this.
We want to run both tests, so that when looking at the wider dataset we may be able to analyse the wider picture, on contention in the UK, or how prevalent computer issues may be.
The Java tester that we had been running for many issues through various versions has been retired. The increase in vulnerabilities and security alerts were leading to an increase in people who were unable to run Java, and there was an increasing number of issues appearing as new versions of Java were released to plug security holes.
In an ideal world we would love to be able to support both platforms, but with our desire to make significant changes to the speed test meant that we have had to concentrate on one platform for now.
If you provide a rating after a speed test, we will not ask you again until the following month.
If you skip the rating, rather than ask you again the very next time you run a speed test we will wait a week before seeking your opinion on your provider.
NOTE: If you use the test on the same computer, but with a different provider we will ask you for your opinion.
If you are using Firefox then a good chance that the problem is the Firefox Plugin-Container.exe. This container runs each plugin in an individual to reduce the chance of a plugin crashing Firefox, unfortunately this can affect speed test performance.
The solution is to disable the Plugin Container or use an alternative browser. For help on how to disable the container one useful guide is here.
Generally for HD streaming your connection needs a fairly reliable speed over 3 Mbps, your tbbx1 result was below this level and our multiple thread test was relatively slow too. This suggests that you may have trouble with video buffering and switching to a lower quality stream may help.
Ensure your connection is not busy downloading or streaming on another device, since this can also create a similar looking speed test result.
The speed test looks at the average speed of your connection and also how variable the results are. In this case with a single thread download under 1 Mbps it is very likely that your connection may struggle to stream even low quality video streams.
If you were testing using WiFi we recommend you run the test again using an Ethernet connection, since WiFi congestion can slow connections down sometimes.
We look at several factors when testing your broadband connection and if we believe the test we have just run looks like it may have issues when streaming a HD video we warn you.
In this example the single thread test shows the connection may not manage a HD video stream, but the second test using multiple connections is generally OK. Since most video streaming is based around a single thread download we warn you.
If you believe your connection should be faster double check that it is not slow WiFi or other devices using the connection that is the result of the slow tbbx1 speed.
Generally any video streaming needs a connection that tests at 1 Mbps or faster, while the HTTPx6 result was better this does not generally help with video streaming.
Severe WiFi congestion can cause a result like this too, so double check other devices are not using your WiFi. For the most reliable video streaming using an Ethernet based connection in the home is recommended.
The speed test looks at various parameters, and in this case there was a large difference between the two download tests. A common cause for this on older computers (e.g. Win XP) is that the RWIN value is too small, connection tweaking software can improve this. Another reason can be congestion, either with the broadband provider or others in the home using the connection.
If the issue is congestion the two results will generally be better at off-peak times, so try running a test after midnight and before 3pm in the afternoon.
Some anti-virus and malware protection suites inspect traffic coming over the Internet onto your computer and this can result in a burst effect. Generally over a length of time this burst settles down and a good average speed is produced.
We know that some versions of the Kaspersky AV suite cause this behaviour and as such this does not mean there is anything untoward with your connection. We just highlight the issue as many people see it and get confused.
You have done nothing wrong, we simply expect the second test that uses multiple downloads to complete within a certain time window. On some combinations of flash and operating system we have seen the test take slightly longer than expected.
Generally the graphs show no evidence of the test taking too long, but if the test stalls and takes 16 seconds or longer you may see an oddly shaped graph.
Now we are tracking unusual events like this we hope to better identify the reasons why it happens for some people.
While some AV software causes high peaks at the start of the test, we have seen some people with tests that start high and then decrease in speed and in a manner that does not suggest congestion.
The exact cause for this problem is not known, but we believe a combination of AV software and possibly a slow PC may be to blame. Now our database is spotting this issue we hope to profile the problem and find the common factor to overcome this odd behaviour.
Our HTTPx6 test should usually be as fast or faster than the tbbx1 test, because it uses multiple downloads to combat the effects of congestion, but in some cases such as yours and the example shown below, the HTTPx6 result is low.
The causes are sometimes your AV software that is slowing down the throughput while it inspects the traffic to ensure it is not dangerous. On some older computers or ones with limited memory we have seen the extra load of doing six tests slow things down too.
This situation can also arise with some KC FTTH based connections, particularly where you are on one of the slower speed packages. Since it appears that the rate limiting used to cap the product speed can give odd results e.g. sample KC FTTH speed test. This effect may not be visible with other testers since they show you less information.
During a speed test we look at how variable the results are, as well the absolute speeds. When people are warned about possible congestion it means we have seen a variable result for both the tbbx1 and HTTPx6 tests.
If you run a speed test outside peak hours and you do not get this warning, the suggestion is that the provider may just have been busy when you previously ran your test. Another possibility is that someone in your home started a large download shortly after you started the speed test.
A single speed test is a snap shot of how your connection performed and in the example shown here, the connection should still be able to stream HD video, but if your speeds a slightly lower and more variable you may actually find HD video is buffering.
Since video streams are sourced from many locations on the Internet it is impossible to give definitive advice, but if you are using WiFi we recommend seeing if an Ethernet connection will give you a better result, i.e. less variability.
Our speed test carries out two main tests, the first which is the tbbx1 result in your case looks to be a lot more variable than the HTTPx6, suggesting congestion at the ISP or over the WiFi link in your home.
Streaming video usually uses a single download of data which is how our tbbx1 test works, so if your speeds are all over the place during the tbbx1 result, it is likely that video streaming may be marginal. If your average speed is above 10 Mbps, then the impact is likely to be only noticed if you stream at the very high quality levels e.g. 2K or 4K video.
Our speed test monitors how stable the speed is during a test and in your situation while you have great speeds, there are indications that the speed varies a fair amount during the course of the test.
In your case and the above example since the average speed was above 20 Mbps it is very unlikely that you will have problems with HD video streaming. In the future once 4K video streams become more common you may start to see more buffering.
We recommend trying another speed test outside peak hours, and if the warnings vanish and the lines are more stable then it would suggest that it was just a busy time of day when you did your test and this is the nature of the Internet where resources are shared.
While most speed tests only produce an average or burst speed our speed test looks deeper into how your broadband service is performing and we noticed some variability in your speed during the test. This should be noticeable by a more wiggly line for the tbbx1 result and a flatter line for the HTTPx6 result.
If the low points of the tbbx1 test are above 5 Mbps then you should have no problems streaming HD video, but if the variation is wider you may see the odd bit of buffering when watching a long film.
If you are using WiFi you may want to consider repositioning your WiFi router to optimise the speeds for where you usually sit and stream video content.
Our speed test automatically defaults to IPv6 if it detects IPv6 on a connect, for those users who want to force an IPv4 based speed test on their connection they can use a copy that runs from our laboratory server. This can be useful for people use an IPv6 tunnel, but want to test their underlying broadband connection without the tunnel.
There is a corresponding IPv6 only version that will only run if your connection supports IPv6.