netselect -vv -s 999 host(s)...
netselect -vv -s 999 host(s)...
Choose the fastest server automatically
an ultrafast intelligent parallelizing binary-search implementation of "ping." You give it a (possibly very long) list of servers, and it chooses the fastest/closest one automatically. It's good for finding the fastest ftp.debian.org mirror, the least laggy IRC server, or the best Squid neighbour.
Usage: netselect [-v|-vv|-vvv] [-m max_ttl] [-s servers] [-t min_tries] host …
$ netselect -vv -s 999 ftp.fceia.unr.edu.ar ftp.kulnet.kuleuven.ac.be ftp.cdrom.com ftp.debian.org ftp.de.debian.org
Running netselect to choose 999 out of 5 addresses.
ftp.fceia.unr.edu.ar 9999 ms 30 hops 0% ok ftp.kulnet.kuleuven.ac.be 9999 ms 30 hops 0% ok ftp.debian.org 27 ms 15 hops 90% ok ( 9/10) [ 75] ftp.de.debian.org 140 ms 20 hops 90% ok ( 9/10) [ 465] ftp.cdrom.com 9999 ms 30 hops 0% ok 75 ftp.debian.org 465 ftp.de.debian.org
-vv Very verbose mode. Displays nameserver resolution and statis-
tics (not just scores) to STDERR and STDOUT.
-s SERVERS
Print this many "top-scoring" SERVERS at the end of the list.
If SERVERS is 0, then this disables printing of high scores.
-m HOPS
Maximum TTL (time to live). Don't accept hosts that are further
than HOPS away.
Newsgroups: gmane.linux.debian.user Date: 2007-06-22
I had been able to use netselect before. When I tried it again just now, all sites end up with "9999 ms 30 hops 0% ok".
I'm wondering why netselect fails on me. My understanding is that netselect uses ping, but ping works fine for me, but traceroute not. That means netselect actually depends on traceroute?
As more and more settings don't allow traceroute to go through, is there any alternatives to netselect?
T
To use it, simply:
% echoping machine.somewhere.org
"echoping" is a small program to test (approximatively) performances of a remote host by sending it TCP "echo" (or other protocol) packets.
Supports IPv6 as well as IPv4,
uses the protocols echo, discard, chargen or HTTP,
uses UDP instead of TCP for the protocols which accept it (like echo),
can repeat the test and display various measures about it,
can use T/TCP on systems which support it.
http://echoping.sourceforge.net/ http://freshmeat.net/projects/echoping/ http://www.gnu.org/directory/All_Packages_in_Directory/echoping.html
echoping assumes the remote host accepts such connections. Experience show that most Internet routers do and many hosts also. However, some Unices are not shipped with this service enabled and, anyway, the administrator is always free to close it (I think they shouldn't). echoping has therefore less chance to succeed than ping or bing. (On a typical Unix box, "echo" service is configured in /etc/inetd.conf but see the CERT advisory.)
echoping simply shows the elapsed time, including the time to set up the TCP connection and to transfer the data (but excluding the time for the - possible - DNS call). Therefore, it is unsuitable to physical line raw throughput measures (unlike bing). On the other end, the action it performs are close from a HTTP request and it is meaningful to use it (carefully) to measure Web performances.
With UDP servers you can have surprises: the first test is quite often much slower since inetd has to launch the process. After that, the process stays a while so the next texts run faster.
There are many, many traps when measuring something on the Internet. Just one example: 'echoping -w 0 -n 4 a-sunOS-machine' and you'll see the first test succeed in a very short time (if you are close from the machine) and all of the others take a much longer time (one second). With '-w 1' (wait one second between tests, the default), everything works fine: it seems the sockets on SunOS need time to recover :-)
To measure performances on the Internet you can also see
bing, a bandwidth measurement tool
ping, probably available with your system
traceroute, idem (otherwise, see LBL)
ttcp, the best measurement tool but it needs some control over the two machines (nothing to do with the T/TCP protocol)
treno (evaluates available bandwidth for TCP)
spray is a tool which I dont't know very well. It is available on some machines (Sun, OSF/1).
I've also heard of but never tried:
Netperf, a suite of Bandwidth Measuring programs from gnn@netcom.com These are several programs that measure bandwidth and jitter over several kinds of IPC links, including TCP and UDP.
TCP Watcher, a very nice "swiss-army knife" tool, to test ping, DNS, echo. It includes an echo server. Available on Info-Mac in "comm/tcp".
(I have little knowledge of that environment and I tested nothing.)
WSNUTIL. Seems to be an echo client and server.
echox32, an echo server
cfinger, an echo client and server
echo and other services can (apparently) be provided within 'Simple TCP/IP Services' which can be enabled through the Network Control Panel
You can ping or traceroute on the Web. See Freenix, fr.net (with Autonomous Systems handling) or Multiple Traceroute Gateway.
Use all of them with care, the result is not obvious to interpret.
And don't forget to read RFC 1470 ("Tools for Monitoring and Debugging TCP/IP Internets and Interconnected Devices"), specially its "Benchmark" section and the Richard Stevens' books (all of them), published by Addison-Wesley.
99661
v20021107
Geolizer is a patch for Webalizer to generate faster and more reliable geographic statistics than using the default DNS suffix method. It uses the GeoIP library. If you disable DNS reverse lookups on your HTTP server, it will work faster and your stats will be more accurate when processed by a patched Webalizer.
Homepage: http://sysdlabs.hypermart.net/proj/log.html#glzr Tar/BZ2: ..er_2.01-10-static-linux.20021107.tar.bz2 Demo site: http://grad.icmc.usp.br/~stas/stats/ freshmeat project page: http://freshmeat.net/projects/geolizer/