upload speed test problem

Adam Maloney adam at whee.org
Thu May 12 13:25:10 GMT 2005


On Thu, 12 May 2005, Ganbold wrote:

> Result is unbelievable, it is something like 500kbps for 56kbps Dial-Up 
> connection, which is completely wrong.

It looks like the form data that the client is POSTing is all "a", 
correct?  The modem is probably compressing this data.

I wrote a speed test in perl a number of years ago to do both upload and 
download testing.  Here are some things I found, maybe they will help you:

You must use data that doesn't compress well, or, as you've seen, dial-up 
modems will compress it and report speeds much higher than is possible.

It is better to pre-generate the random data, rather than try and read 
from /dev/random on the fly.  I realized that by having my script suck 5 
or 10 megabytes of randomness out of /dev/random every time it ran, I was 
accelerating the heat-death of the universe.  You don't want to cause the 
heat-death of the universe either, do you?  (Actually, either pre-generate 
random files, or read from /dev/urandom, which doesn't block when it runs 
out of randomness)

IE Sucks.

The way my script worked was, I had a form page that the user selected the 
file size to test with, and hit Submit.  This submitted to my CGI that 
generated a new HTML form with a hidden input field containing the random 
data of the size they selected.  It also contained a hidden field with a 
timestamp of when the page began to execute.  I used javascript to 
automatically submit the form when the page load completed.  Mozilla would 
submit this form as soon as page load completed.  For some odd reason, IE 
would wait a couple of seconds before submitting the data.  So I had to 
(oh this is so ugly, I don't want to say it), define an IE fudge factor, 
and subtract a couple of seconds from the upload time if the client was 
IE.

I also realized that I had to add a META tag to cause the pages not to be 
cached.  Furthermore, I had to add something to look at the client's HTTP 
headers and look for signs of an HTTP proxy (proxies usually add a header 
or two, depending on how they're configured).  If a proxy was detected, I 
could either spit out a warning to the user that the speeds reported could 
be inaccurate, or I could simply refuse to continue.

On the plus side, overall the test worked pretty well.

HTH,

Adam


More information about the freebsd-hackers mailing list