Re: Apt + Netselect Server choosing
On Thu, Oct 22, 1998 at 02:12:10PM -0400, Stephen J. Carpenter wrote:
> netselect works now:
> [sjc@lenny sjc]$netselect -vv helix stat1 stat3 hedwig
> helix 2 ms 2 hops 100% ok (10/10) [ 2]
> stat1 2 ms 2 hops 50% ok ( 5/10) [ 6]
> stat3 3 ms 3 hops 100% ok (10/10) [ 3]
> hedwig 2 ms 2 hops 50% ok ( 5/10) [ 4]
> 2 helix
Hmm, those 50% thruput ones are interesting. I don't see that effect on my
network. Is your connectivity to those hosts really that bad?
If not, then you may have run into one of netselect's optimizations. To
save time, it will stop after 75% of hosts in the list have "finished." The
logic is that the remaining 25% are the slow ones anyway; and furthermore,
some of them might be dead and we don't want to bother waiting to make
absolutely sure. This produces strange results on fast networks with few
hosts -- I should document it somewhere or perhaps adjust the algorithm.
Note that it rounds down, so with <= 3 hosts on the command line, you only
get to 75% when all three are done.
> [sjc@lenny sjc]$netselect -vv helix www.debian.org
> helix 1 ms 2 hops 100% ok (10/10) [ 1]
> www.debian.org 9999 ms 30 hops 0% ok
> 1 helix
> --- of course...traceroute doesn't work past our firewall either
Oh. netselect uses exactly the same technique as traceroute to find the
hopcount (although it uses a binary, rather than linear, search). If it
can't find the hopcount, it won't work at all.
There are two reasons traceroute might not work: problems with the TTL, and
firewalled UDP ports. netselect does some pretty strange tricks with UDP
ports, so it may not be easily fixable if that's the problem... hmm.
If it's just a TTL thing, that should be easy enough to work on.
> Is there perhaps some other way this could work (maybe that the test could
> fall back on in case there isa firewall problem)?
Could you send me the netselect output if you use "-vvv" instead of "-vv"?
Hopefully that will reveal something.