Re: New APT Version
On Sun, Apr 05, 1998 at 10:53:38AM -0400, Raul Miller wrote:
> > > Er.. pathchar is overkill. What you want is a variation on bing (also by
> > > Van Jacobsen, but which we have a package for). The variation should:
> >
> > Hmm. Bing has never worked for me; it nearly always gives nonsensical
> > answers. Stuff like negative delays.
>
> How are you invoking it?
>
> Try:
>
> bing -z localhost ftp.debian.org
>
> Let it run until you have a dozen sample, or for 60 seconds (whichever
> comes first) and hit control-c. Does this not work?
Note that 'bing' sounds like it should measure the bandwidth between
_any_ two places, but that doesn't really work: it can only measure the
bandwidth between two places on the same path from you to a target. That
is, if you 'traceroute' to host2, host1 needs to be somewhere along that
path. If not, you will get screwy results.
bing works pretty reasonably, reliably determining that the speed of my 28.8
modem is the slowest part of the link. However, like pathchar, it is still
mathematical overkill for our problem. From /usr/doc/bing/README.gz:
Bing determines the real (raw, as opposed to available or average)
throughput on a link by measuring ICMP echo requests roundtrip times
for different packet sizes for each end of the link.
We are much more interested in the "available" throughput than the "real"
throughput, when we are trying to choose a good server. For example, I'm
sure the link between me (in Canada) and ftp.de.debian.org (in Germany) has
virtually no "slow" points (except my modem, of course). However, it will
be a very _busy_ link, making it slow(er) to download from.
The way bing seems to work is that it measures raw delay (rtt) for small
packets (mostly due to busy-network lag), and then for large packets (to
find the additional rtt due to actual data transfer). Do something like a
subtraction (not exactly) on the two values and you can find out how fast
the link _really_ is. This assumes, by the way, that the lag is
constant. I guess that's usually rather true.
Anyway, we don't really want to know about that. We're interested in the
actual download speeds we'll achieve. I would use a decision-making process
like this, in order of priority:
- lost packets: if there are many of them, forget this site. TCP
responds horribly to lost packets. Missing packets are the number one
leading cause of internet slowness. (Well, perhaps "faulty application
programs" is actually worse, but APT doesn't have that problem.)
- rtt: lower rtt is generally better, because it means a link is neither
too busy nor too slow.
- number of hops: not too important. Even if it's 30 hops away, if the
rtt and loss are good, you have a good site. We could use this as a
"tie-breaker" because fewer hops generally means you congest the network
less, but maybe it would be more work to implement than a benefit.
It's starting to look like just a parallelized version of 'ping'.
That said, I may write this thing sometime "relatively" soon... it depends
if I can find the time with all of my other projects. Right now, I'm trying
desperately to see if Linux will support this new PCI modem in my alpha...
Oh, incidentally, bing was written by Pierre Beyssac.
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: