check fastest mirror

[Jean Michel Bruenn]

Hello,

> 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.

Tracerouts gives us the nearest Server. The nearest server will be to 90%
the fastest reachable server (it doesn't matter how fast the server really
is.) 

> 
> 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.
> 

As described ago, we can remove mirrors limiting bandwith from the list of
checked mirrors by this script. Users with a dialup can choose the mirror
manually, there's no need to use this script.

> 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.
> 

thats the only problem we have. i described it. I know no way to work
arround. But other distributions are using netselect, too. They seem to
ignore this.

> 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).
> 

ack. But we aren't talking about a videogame.

> 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

at least striker is right, but, other distributions are using it, why we aren't?
Whats with other developers, no one wants to say something to this here?

i'll give it up at this point.

Cheers Jean