pathchar notes

(cobbled-notes-until-we-build-a-better-manpage,
with contributions from Becca Nitzan and Evi Nemeth.

Addendum to caida's pathchar page.)

Pathchar written by Van Jacobson of LBL's Network Research Group.
Select way-alpha-release binaries: ftp://ftp.ee.lbl.gov/pathchar.


Interpreting pathchar output

Part I: first line in output

The first line output looks as follows:


         doing 24 probes at each of 64 to 1500 by 92
               ^^                   ^^    ^^^^    ^^
               a)                   b)    c)      d)

where So for this example output (the default), each hop has ~((1500 - 64)/92 * 24) queries (360).


Part II: dynamic output during execution

Pathchar's execution consists of assessing, in order, each link along the path to the specific destination. While pathchar is running, for the particular link it is assessing at the time, it posts a series of 4 numbers on the screen for each of the probes sent to that hop. Example:

        1:    24          156                0        0
        hop:  round#      size-bytes         drops    rtt
where

Part III: Pathchar execution output descriptions


 3 paloalto-br1.bbnplanet.net (131.119.0.193)
 |    38 Mb/s,   25.7 ms (63.7 ms),  +q 1.24 ms (5.87 KB) *13
     bandwith   propagation (rtt)   queueing (queue size) *hinge
 4 anl-atms.es.net (134.55.24.2)

   
      ---------- ------------ | rtr hop 3| | rtr hop 4 | | |<-------|UUUU:Q3 | ->-|---Q1:UUUU|------->|Q2:UUUU | ---------- ------------

Part IV: command line arguments

notes:
If queue at one hop disappears at next hop, likely the CPU queue at first hop


Part V: sample output

riesling ~ 79% 14:24: pathchar ka9q.ampr.org
pathchar to ka9q.ampr.org (129.46.90.35)
 mtu limitted to 1500 bytes at local host
 doing 32 probes at each of 64 to 1500 by 44
 0 192.172.226.24 (192.172.226.24)
 |   9.3 Mb/s,   269 us (1.83 ms)
 1 pinot (192.172.226.1)
 |    85 Mb/s,   245 us (2.46 ms),  1% dropped
 2 sdscdmz-fddi.cerf.net (198.17.46.153)
 |    45 Mb/s,   -13 us (2.70 ms)
 3 qualcomm-sdsc-ds3.cerf.net (134.24.47.200)
 |   8.8 Mb/s,   1 us (4.07 ms)
 4 krypton-e2.qualcomm.com (192.35.156.2)
 |   5.2 Mb/s,   1.02 ms (8.42 ms)
 5 ascend-max.qualcomm.com (129.46.54.31)
 |   53.2 Kb/s,   4.20 ms (243 ms)
 6 karnp50.qualcomm.com (129.46.90.33)
 |    12 Mb/s,   -172 us (243 ms),  +q 8.96 ms (13.0 KB) *3,  6% dropped
 7 unix.ka9q.ampr.org (129.46.90.35)
7 hops, rtt 11.1 ms (243 ms), bottleneck 53.2 Kb/s, pipe 4627 bytes
riesling ~ 80% 15:30: 

Part VI: Important interpretation Notes

[from van]:
Getting reasonable estimates

It takes many probes for pathchar to ascertain bandwidth of a fast link (>50Mb/s). Since we don't yet have method for pathchar to automatically decide its fit estimate is `good enough', you need to manually set the number of probes (via the -q flag) based on a guess about the path bandwidth & workload. The default of 32 probes leads to ~2 minutes/hop of probing, sufficient for links up to 10Mbs.

Rough guidelines:

  1. use -q 64 for relatively quiet, fddi or slower paths.
  2. use -q 128 for busy (especially for fast link beyond a busy, slower link), fddi or slower paths, or quiet and faster than fddi.
  3. use -q 256 or -q 512 for links faster than fddi on a busy path (i.e., not the fast link(s), but upstream busy links -- the most damage is done by slow busy links upstream of the fast link you're trying to measure).
parenthetical stickiness on one hop
If at a given node, pathchar prints something like

   9:   6  1208  28     102       ->206.34.78.27 (54358) 
it means that the source address has changed in the ICMP time exceeded reply. Pathchar remembers the first address it encounters for this hop, and prints this message (and otherwise ignores the response) when that address doesn't reply. The number in parentheses is the total number of responses from the 'wrong' address(es). Once this hop completes, pathchar prints out the list of 'wrong' addresses & the number of replies from each, together with the estimates for the first address. If the first address pathchar sees was a low probability alternate path, it can take a long time to do a full cycle of probes to it (the round number would decrement slowly).
last updated 28 may 97, kc@nlanr.net
questions, feedback: info@caida.org
nd a busy, slower link), fddi or slower paths, or quiet and faster than fddi.
  • use -q 256 or -q 512 for links faster than fddi on a busy path (i.e., not the fast link(s), but upstream busy links -- the most damage is done by slow busy links upstream of the fast link you're trying to measure).
  • parenthetical stickiness on one hop
    If at a given node, pathchar prints something like
       9:   6  1208  28     102       ->206.34.78.27 (54358) 
    
    
    it means that the source address has changed in the ICMP time exceeded reply. Pathchar remembers the first address it encounters for this hop, and prints this message (and otherwise ignores the response) when that address doesn't reply. The number in parentheses is the total number of responses from the 'wrong' address(es). Once this hop completes, pathchar prints out the list of 'wrong' addresses & the number of replies from each, together with the estimates for the first address. If the first address pathchar sees was a low probability alternate path, it can take a long time to do a full cycle of probes to it (the round number would decrement slowly).
    last updated 28 may 97, questions, feedback to info@caida.org
    page maintained by Ray Matthieu