Update: details for SpeedTest.net are for Los Angeles as well now.

SpeedTest.net

Latency

Get http://ndt.dhspeedtest.com/flash/speedtest/latency.txt?x=<some sort of timestamp> (this request repeats 10 times)

Last-Modified: Fri, 28 Jul 2006 23:31:21 GMT

Download Speed

• Download in 1 thread http://ndt.dhspeedtest.com/flash/speedtest/random750x750.jpg
• Download in 2 threads http://ndt.dhspeedtest.com/flash/speedtest/random750x750.jpg

Note: URL is for Los Angeles server

Upload Speed

• Upload in 2 threads 29705 bytes of random data
• Upload in 2 threads 29705 bytes of random data
• Upload in 2 threads 95251 byte of random data
• Upload in 2 threads 95251 byte of random data

Note: the download and upload patterns differ for different locations!

DSLReports

Latency

Get http://www.dslreports.com/ft?c=gd&o=records&limit=4&f=myuid

Cache-Control: no-cache, max-age=0

Download Speed

• Downloading http://dslreports.linkline.com/SpeedTests/random750x750.jpg?x=0.928372583817691
• Downloading http://dslreports.linkline.com/SpeedTests/random500x500.jpg?x=0.663370833266526

Note: URL is for Los Angeles server

Upload Speed and Compression Check

• Uploading 100009 bytes of zeros
• Uploading 50009 bytes of random data
• Uploading 100009 bytes of random data

Conclusions

Upload and download speed differences are most likely not related to any caching; data downloaded and uploaded is random. Numbers are different because DSLReports uses single thread and SpeedTest.net uses 2-4 threads. One question remains: do both sites do any checksumming on the downloaded data to assure it is really what their servers send them or it’s a stale copy from some cache?

Latency: SpeedTest server does not put the proper Cache-Control: directives in the reply, therefore the latency measurement is more likely to be affected by caching. DSLReports put the proper directive in the reply but that does not mean the latency result cannot be faked intentionally by the ISP proxy. It is possible to configure a proxy server to always use cached result for a given URL, ignoring directives from a Web server; but in that case the proxy would not be RFC2616-compliant anymore.

RFC2616, 13.3 Validation Model

When a cache has a stale entry that it would like to use as a response to a client’s request, it first has to check with the origin server (or possibly an intermediate cache with a fresh response) to see if its cached entry is still usable.

Please note what for the latency measurement the content returned is not important; if proxy complies with RFC2616 it MUST check the resource on the original server before returning the resource and this means HTTP “ping” value would be about right (it will consist of round-trip time from the client to the proxy + round-trip time from proxy to the original server).

On the other hand, if the proxy is not RFC2616 compliant, I do not see any advantage of DSLReports over SpeedTest.net; it seems that DSLReports latency can be faked as well if ISP wishes to do so.

• Cisco EPC2325
• Motorola Surfboard SB6120E

Warning: IP address you will get on WAN interface is from private ip address range (10.x.x.x)! Therefore no port forwarding would be possible (probably the most common use for it on the island is remote access to the CCTV recorders and IP cameras); problems with VPN  etc…