Some users feel the need to test how fast their cable modem is at downloading or uploading. To answer this need, several speed testing sites have sprung up, mostly in the USA. The problem is, none of these tests measure the actual speed of your cable modem: what they measure is the bandwidth between your cable modem and the test site itself, subject to a maximum cut-off at the speed of the modem.

The bandwidth between two points on the Internet is determined by the hop in the path (see Traceroute below) which has the least available spare capacity, and if that limiting bandwidth is less than that of the cable modem, then that is the reading that the speed test will return. This figure might or might not be typical of speeds you could expect to see from other sites, or at other times, depending on where and when the bottleneck is.

If you are fortunate enough to choose a test site where the available free bandwidth on all hops is greater than the speed of your cable modem, then the test site will indeed measure the speed of your cable modem, which is then the limiting bottleneck. But you knew that was 512 kbps anyway, so you are not learning much.

Be aware that most upload speed tests are invalidated by the presence of the transparent web proxy cache, so you should disregard those upload results.

Pay no attention to download speeds reported by Microsoft Internet Explorer, because it will be downloading the start of the file while you are still choosing a download directory and filename, so it often reports impossibly high transfer rates immediately after you click OK.

Speed test web sites fall into two broad categories:

Java applets embedded in a web page:
Pro: they usually use a port other than 80 for carrying the test data, and so the effect of proxy web caches is avoided.

Pro: they usually produce more accurate estimates than other types. Con: they do not copy the received data to disk, so they produce optimistic estimates of download speeds, as the delays introduced by disk systems are not taken into account.

Con: most of these test sites are in the USA, even if they have a .uk host name, and transatlantic links are usually congested, as are USA backbones.



JavaScript timing of a large web page download:
Con: the web download is slowed by the web proxy cache, so speed figures will reflect those of HTTP downloads, but be pessimistic for FTP downloads.

Con: web browsers do such complex tasks during downloads that JavaScript timings are unreliable.

Pro: the web browser does copy the downloaded web page to its internal cache on disk, so the slowing effect of disk systems is taken into account.

Con: most of these test sites are in the USA, and transatlantic links are usually congested, as are USA backbones.

Con: most JavaScript tests fail to take into account that the first few tens of kilobytes of a web page will pass through the cable modem at high speed, before the capping algorithm cuts in, and so give absurdly over-optimistic estimates of download speeds.



A good example of a Java applet test site is http://www.dslreports.com/stest/0,but this site is in the USA, and I don't know of such a site in the UK.

There are many poor JavaScript test sites. Many of the test pages are too short to hit the rate capping of a cable modem. All of them I have seen fail to train the cable modem's rate capping before starting the timings.