Re: bandwith measurement

[Randy Bush <randy at psg.com>]

>> again, use patchar
> It happens to come with a strong warning that it is ALPHA and not yet
> ready for use in the README. It also comes with no instructions whatsoever
> about command line arguments to use with it. Simply typing pathchar
> elicits a number of question marks from the program. Any suggestions on
> how it is used?

well, the msri talk gives some clues.   some good computer science in it.

i will append two notes i have.

as to its alpha status, it turns out to be a very hard problem.  and if you
don't like it, i will see you get a full refund :-)

it is not good at measuring big pipes behind small ones, e.g. it does poorly
on the oc48 in

  pathachar ---T1--- router ---OC48--- router

i think caida has some copycat tools that are probably better documented.

randy

---

Date: Mon, 21 Apr 97 06:19:16 PDT
From: Van Jacobson <van at ee.lbl.gov>
To: ietf at ietf.org
Cc: rem-conf at es.net
Subject: pathchar - a new tool for characterizing Internet paths

For the past 6 years, I've been working on a tool to figure out
more about an Internet path that just what routers you go through.
I've developed a tool called `pathchar' (for `path characteristics')
that tells you the bandwidth, distance from previous hop, average
queue, and drop rate for every hop on the path (*not* just the
bottleneck hop).  This is a typical output:

    % pathchar ka9q.ampr.org
     mtu limitted to 1500 bytes at local host
     doing 32 probes at each of 64 to 1500 by 32
     0 localhost
     |   8.7 Mb/s,   292 us (1.97 ms)
     1 ir40gw.lbl.gov (131.243.1.1)
     |    29 Mb/s,   132 us (2.64 ms)
     2 er1gw.lbl.gov (131.243.128.11)
     |    91 Mb/s,   189 us (3.15 ms)
     3 lbl-lc1-1.es.net (198.128.16.11)
     |    25 Mb/s,   6.92 ms (17.5 ms)
     4 gac-atms.es.net (134.55.24.6)
     |    11 Mb/s,   424 us (19.4 ms)
     5 CERFNETGWY.GAT.COM (192.73.7.163)
     |   7.0 Mb/s,   1.20 ms (23.5 ms)
     6 sdsc-ga.cerf.net (134.24.20.15)
     |   ?? b/s,   -263 us (22.8 ms)
     7 mobydick-fddi.cerf.net (134.24.252.3)
     |    46 Mb/s,   -51 us (22.9 ms)
     8 qualcomm-sdsc-ds3.cerf.net (134.24.47.200)
     |   9.0 Mb/s,   17 us (24.3 ms)
     9 krypton-e2.qualcomm.com (192.35.156.2)
     |   5.5 Mb/s,   1.04 ms (28.6 ms)
    10 ascend-max.qualcomm.com (129.46.54.31)
     |   56.7 Kb/s,   6.19 ms (253 ms)
    11 karnp50.qualcomm.com (129.46.90.33)
     |    10 Mb/s,   -50 us (253 ms),  +q 3.32 ms (6.58 KB) *2
    12 unix.ka9q.ampr.org (129.46.90.35)
    rtt 32 ms (253 ms), bottleneck 56.7 Kb/s, pipe 4706 bytes

The lines starting with `|' are the characteristics of the link
between the hops listed above & below.  The first number is the
link bandwidth, the 2nd is the one-way prop time (i.e., for a
zero length packet) & the number in parens is the round trip
time you would get if there were no queues and you sent a
path-mtu sized packet from the source to this hop (i.e., the
unloaded data rtt).  If there's a queue larger than 1 packet,
its size in both time & bytes is printed.  If the drop rate is
more than 1%, it's printed.

Note that it successfully found the LBL FDDI dmz (hops 2-3) &
SDSC-Qualcomm T3 (hops 7-8) even though I was running it behind
a 10Mb/s ethernet.  And that the long hop from San Francisco to
San Diego is clearly visible (3-4).  (Also note that I was
running this at 1am this morning so the normal cerfnet queues
were missing & only Phil's P50 ISDN box showed a queue.)

We're hoping to release pathchar sometime in the next two weeks.
I'm giving a talk on it today at 4pm PDT for MSRI Math Awareness
Week and the talk should be mboned.  I've put the viewgraphs
from the talk (which are the only existing documentation) at

  ftp://ftp.ee.lbl.gov/pathchar/msri-talk.ps.gz

If you really deperately want to play with a very flakey, alpha
version of pathchar, there are binaries for freebsd, linux and
solaris in the same directory (but you are totally on your own
when running this -- we'll answer questions once the beta release
goes out but right now we're putting all our energy into getting
it out).

Cheers..

 - Van


----


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
week or so until we release the source so this is only for the brave
(or foolish).  Please report problems to pathchar at 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.

 - 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).

-----
This is the afnog mailing list, managed by Majordomo 1.94.4

To send a message to this list, e-mail afnog at afnog.org
To send a request to majordomo, e-mail majordomo at afnog.org and put
your request in the body of the message (i.e use "help" for help)

This list is maintained by owner-afnog at afnog.org