Mon Apr 21 05:25:31 PDT 1997

This is an *ALPHA* test version of the LBNL Internet path characterization
tool, pathchar.  There's essentially no documentation & it will be a
while until we release the source so this is only for the brave
(or foolish).  Please report problems to pathchar@ee.lbl.gov.  But
please don't ask questions -- if it doesn't make sense, wait for the
beta release.  Thanks.  Have fun.

 - Van Jacobson

Some misc. notes
----------------

 - the PC pathchar has to be run on a pentium or better -- it will
   run but give useless numbers on a 386 or 486.  this is because 
   pathchar requires a very high resolution clock (1us or better)
   and the pentium is the first intel chip with a halfway decent
   clock.

 - pathchar's MTU discovery doesn't appear to work with our linux
   kernel (redhat Linux version 2.0.30).  If pathchar appears to
   hang after starting or prints a lot of "sendto: msg too long"
   errors, you may need to give it a "-m 1500" flag to get it to
   work under linux.

 - because of kernel brokeness, pathchar's mtu discovery doesn't work
   either to or from solaris.  When you run pathchar from a solaris
   machine, it assumes a path mtu of 1500.  If you're absolutely,
   positively sure that the path mtu is larger (or smaller) than
   1500 bytes, use the "-m <path mtu>" to tell pathchar the mtu
   (on real operating systems this is unnecessary because pathchar
   will figure out the path mtu).

 - if you run pathchar *to* a solaris machine, be prepared to wait
   a *long* time for things to start -- some clever person decided
   that solaris should rate limit icmp responses to 2/second so
   pathchar's mtu discovery requires a lot of length timeouts and
   retransmissions.  If you can't run pathchar to a machine running
   a reasonable operating system, try adding a "-m 1500" flag to
   bypass mtu discovery.

 - the kernel networking code in freebsd improved a lot between
   2.1 & 2.2.  pathchar works badly under 2.1 and quite well under
   2.2.

 - The pathchar defaults do a fairly good job of finding the bandwidth
   of links 10Mb/s or slower.  If you need to find the bandwidth of
   a fast link on a busy path (particularly a fast link downstream of a 
   busy slow link) you will probably have to tell pathchar to do more
   probes (add a "-q <nprobes>" flag).  -q 64 or -q 128 will usually
   resolve a T3s and FDDIs if the bottleneck link is 10Mb/s or faster.
   Because of clock resolution limits, you probably can't resolve OC-3
   or faster links unless the path mtu is at least FDDI size (4K).
