Re: New APT Version
On Sat, Apr 04, 1998 at 08:27:53PM -0400, Gregory S. Stark wrote:
> > I would really like to get a list of mirrors in sources.list format ..
> > [would allow a much smarter seutp script]
>
> It should even be possible to have apt ping them all and choose one based
> on the rtt, ttl, and a hard coded list of preferences.
Disclaimer: I haven't looked at what apt-get actually does internally, and
I'm using the default configuration of version 0.0.3.
However, I was thinking of this problem a while ago for an unrelated
project: with a large list of servers, how can you reasonably-well
prioritize them based on speed/efficiency/nearness etc.
The most accurate way to determine how fast transfers will be from a site is
to actually download a (reasonably large) file from that site. However,
with a list of 20+ mirrors, this is unreasonable.
So, we need to find a less correct, but still reasonable solution. It seems
to me that three aspects generally (!) indicate the transfer performance to
a remote site:
- hop count, as measured by traceroute.
- rtt (round-trip-time) as measured by ping.
- number of lost packets, as measured by a continuous ping.
Note that using the ttl (time-to-live) from ping is a bad idea: the remote
end bounces a packet back starting with an arbitrary ttl value, so you can't
tell how long it actually took. Using a simple comparison, it would appear
that a returned ttl of 60 is much worse than a ttl of 240; but some servers
use a _starting_ ttl of 64, so the first one _might_ be only four hops away.
That said, you can measure hop count accurately using a binary-search
version of traceroute. Just start pinging with a large ttl, then divide in
half, half again, and so on until you find the point where you start getting
host-unreachable messages.
To measure rtt and lost-packet count, simply ping each site once per second
for about ten seconds and summarize the results.
Note this can be done for all sites in parallel, thus keeping the total test
time down to about ten seconds, not including DNS lookups (my complaints
about the braindead resolver library are legendary). In fact, apt-get could
even run a task like this while it downloads the (relatively small) package
files from a random server, thereby eliminating the "extra" delay. It might
not be fair to run the test on a busy link, however.
A program that did something like this would be quite useful for anything
that depends on choosing one server over another: IRC, Squid cache, and
standard ftp come to mind. I usually do this type of comparison myself when
trying to choose a server, but I get bored after trying about five of them.
A program could try many more choices and make a better decision.
I should write something like this someday. I probably will end up writing
it for one of my (to be GPLd) projects soon, but don't hold your breath...
Have fun,
Avery
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: