I decided to do a little check on this article:
http://www.phuketgazette.net/archives/articles/2011/article10972.html
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.
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.