check fastest mirror

[Jon South]

Jannis wrote:
> I agree with Jean in that the idea in general is a good one. I think we
> don't need to argue about how much sense determining the fastest
> mirrors makes - it simply does make sense.
> 
> While I like the idea of having the option to run such a script (e.g.
> from lunar's Options/Software Mirrors/Detect and use fastest mirrors),
> this should only be performed on demand - not automatically.
> 
> The implementation Jean posted might not be perfect (actually, I don't
> know how all this could be done in a better way), it might do the job
> for now, until we find a better way. Just add it
> as e.g. "/usr/bin/lunar-use-fast-mirrors" and add the mentioned option
> to the "lunar" menu. It would be easy to replace the content of this
> script with something different later.

I will give you a few examples of why this script would not be useful:

1) Traceroute packets only tell you the number of hops and the speed at 
which those hops decide to send back those useless packets. I say 
useless because most routers QoS controls are configured to put any 
packets that do not serve much purpose (icmp, ttl exceeded, etc) below 
any important packets (ftp, http, established connections, etc). This 
causes skew on the timings of how fast *real* packets will return.

2) The *actual protocol* that you're testing for is *not* actually being 
tested. You're testing ping times of a few low priority packets.

3) This test does not take into account rate limiting done server-side. 
Take for example the OSDN SourceForge mirror. Typically, when I'm 
downloading from it, my rate is limited to about 20k/sec; however, OSDN 
is very close to me and has excellent response times, but since your 
little test didn't use the correct protocol to test with, I get the 
wrong results.

4) This goes hand in hand with #1: Some service providers configure 
their routers to completely ignore icmp or traceroute packets because 
they simply dont care to route such useless packets. So if you have some 
blazing 800k/sec mirror right next door to you that drops your 
traceroute packets, "oops" I guess you'll never know now.

5) Just because it's closest, doesn't make it so. You've sent out a 
packet, it's bounced around 8 or 10 times on the internet's busiest 
routers that are already carrying 90% of their maximum load. Your packet 
has just annoyed the hell out of a bunch of routers' QoS, so it bumps 
your packet behind a large amount of more important packets, you've now 
lost 100ms for each of those routers. Wow, this route really sucks...or 
does it? Had you used a more important packet, you wouldn't have had to 
wait that 100ms at each hop.

The moral of this story? If you're going to test something (e.g. video 
games), dont test them with anything other (e.g. 80 year old men) than 
what you plan on using afterwards (e.g. kids, teens, etc).

If you really want to test how well a mirror works, you need to actually 
download something from it; not poke at it with a stick. Your best bet 
is to download a fairly large file (depending on your bandwidth) at 
least twice at two different times (peak/off-peak usage). This will 
obviously take a considerable amount of time, and for the most-part wont 
gain you much benefit. I wouldn't use a traceroute tool to guage my 
HTTP/FTP download speeds any farther than I could throw the damned 
thing, and neither should anyone else.

-Striker