Measure actual download speed #47
Comments
|
Nice suggestion/feature request. I'd say, to do this fairly, the process should:
|
|
Indeed. Especially the randomized part is also quite useful to test if the server has fast disks and/or lots of disk cache. Although the maximum file size should be configurable I think. A 1MB file might not be a very useful benchmark for connections that go beyond a 100Mbps as that's less than a 10th of a second. |
|
This is an interesting suggestion. It would be ideal to keep it simple and choose a file that doesn't vary across distributions/architectures, maybe something like the list file However, we need to be careful when considering something like this since concurrent tests would need a significant disclaimer attached to them if it saturates the WAN port's bandwidth. That problem could be solved by running the tests synchronously, but could be very slow when testing more than a handful of mirrors...which seems ok given the benefits to the ranking it would yield if implemented as an optional argument. |
|
I would like to propose a slightly different solution. Instead of limiting by size, limit by time. Just download for 1 second and see how much was downloaded in that time. For a slow connection it might only be 1 MB but for a fast connection it could easily be 100MB. So with fast connections in mind, why would 15MB be too big? 100 Mbps connections are widely available in many countries these days and this script would also be useful for datacenters where gigabit connections are really common. |
|
Agreed, limiting downloads by time (like 1 second) is a better approach. 15 MB isn't too big a file for weaker connections if you stop early, and as I mentioned before, it's trivial to stop after a certain size. It shouldn't be difficult to implement stopping after a time interval using threads and timeouts correctly. |
|
This is connected to #46 as it requires using http and ftp connections. |
For the top few results it would be very useful to measure the actual download speed. The latency tells
you the server is close and most likely has good routing, but it could still be taxed to near it's maximum capacity.
To illustrate a simple test using the mirrors fetched from http://mirrors.ubuntu.com/mirrors.txt
A list of mirrors, followed by the latency (5 pings) and the download performance as outputted by curl:
As you can see, several of the mirrors have really low latency but don't offer fast downloads.
For example, the
nl3.archive.ubuntu.comserver has a latency varying from 19.01 to 21.67 which would mean it doesn't end up at the top of the list while the download speed of 31.8MB/s is far more important to me.Similarly,
mirrors.noction.comonly downloads with 15.8MB/s with more favorable latencies (varying between 11.75 and 15.04ms).The text was updated successfully, but these errors were encountered: