Return to FORMATS CVS log

Up to [ELWIX - Embedded LightWeight unIX -] / embedaddon / mtr

Annotation of embedaddon/mtr/FORMATS, revision 1.1

1.1     ! misho       1: 
        !             2: The "split" format is for a separating the gui from the main program.
        !             3: The main program can be installed setuid, and you don't want to link a
        !             4: gui-library with a setuid program.
        !             5: 
        !             6: 
        !             7: The split format is:
        !             8: 
        !             9: <pos> <host> <loss%> <rcvd pckts> <sent pckts> <best> <avg> <worst> 
        !            10: 
        !            11: 
        !            12: The "raw" format is:
        !            13: 
        !            14: hostline|pingline|dnsline|timestampline
        !            15: 
        !            16: hostline:
        !            17: h <pos> <host IP>
        !            18: 
        !            19: pingline:
        !            20: p <pos> <pingtime (ms)>
        !            21: 
        !            22: dnsline: 
        !            23: d <pos> <hostname>
        !            24: 
        !            25: timestampline:
        !            26: t <pos> <pingtime> <timestamp>
        !            27: 
        !            28: 
        !            29: Timestampline is not  yet implemented. Need to find out how to do
        !            30: ICMP timestamping first. :-)
        !            31: 
        !            32: 
        !            33: Someone suggested to put the following text here. As to context: Some
        !            34: people are wondering why mtr sometimes reports hosts beyond the
        !            35: destination host. 
        !            36: 
        !            37: 
        !            38: The FINAL host will occasionally be mentioned at position n, n+1, n+2
        !            39: etc.
        !            40: 
        !            41: You know traceroute, right? It sends a packet, waits for the reply to
        !            42: come back and when it comes back, it sends the next packet.
        !            43: 
        !            44: If say hosts 5-8 do not send "time exceeded" packets, you'll wait a
        !            45: 4*3 = twelve seconds extra before you get any results on hosts 9 and
        !            46: further. MTR doesn't work like that.
        !            47: 
        !            48: In theory we could send out a probe for host 1-40 all at once. But
        !            49: this would pose an unnecessary burden on the network. So what we do,
        !            50: is we send out probes for a max of 5 hosts beyond where we've seen a
        !            51: reply. So in the example above, we'd see a reply from router at
        !            52: position 4, then we'd send out 5-9 (and because the max-host is now at
        !            53: 9, we'll send them out at 1s/9 = 111ms intervals). When the reply from
        !            54: host 9 comes back, we'll start probing for host 10-15 (at about 60ms
        !            55: intervals). But suppose the network delay upto host 9 is already 200ms
        !            56: and suppose our destination host is at position 11. Then by the time
        !            57: the packet from host 11 comes back, we'll already have sent probe
        !            58: packets for position 12, 13, and 14! Those will come back as
        !            59: "destination reached" and be reported by the "raw" mode.
        !            60: 
        !            61: Curses mode will stop showing hosts with position numbers beyond the
        !            62: first reply of the destination host. It could gather the information
        !            63: about replies to packets sent as probes FURTHER than it actually is
        !            64: into the line displayed at its true position, but it doesn't (yet).
        !            65: 
        !            66: In fact the above example is almost completely true:
        !            67: 
        !            68: % mtr -r -n -c 2 152.179.99.218 | tail -5
        !            69:  13.|-- 144.232.18.238 0.0% 2 94.8 95.4 94.8 96.0 0.8
        !            70:  14.|-- 152.63.16.182 0.0% 2 95.1 95.5 95.1 95.8 0.5
        !            71:  15.|-- 152.63.64.106 0.0% 2 163.9 163.9 163.9 164.0 0.1
        !            72:  16.|-- 152.63.50.89 50.0% 2 163.7 163.7 163.7 163.7 0.0
        !            73:  17.|-- 152.179.99.218 50.0% 2 168.2 168.2 168.2 168.2 0.0
        !            74: % mtr -l -c 2 152.179.99.218 | grep -v "^[dp]" |tail -7
        !            75: h 10 144.232.1.41
        !            76: h 11 144.232.4.96
        !            77: h 16 152.179.99.218
        !            78: h 17 152.179.99.218
        !            79: h 18 152.179.99.218
        !            80: h 12 144.232.18.238
        !            81: h 13 152.63.16.182
        !            82: 
        !            83: As you can see we get the reply from the destination host at position
        !            84: 16 AFTER we've sent probes for position 17 and 18. When those come
        !            85: back, they are reported. That's what raw mode does. It reports the raw
        !            86: information.
        !            87: 
        !            88: If you write a backend for the raw mode, it's up to you to
        !            89: filter/display the results.
        !            90: 
        !            91: h 10 144.232.1.41
        !            92: h 11 144.232.4.96
        !            93: h 12 144.232.18.238
        !            94: h 13 152.63.16.182
        !            95: h 14 152.63.64.106
        !            96: h 15 152.63.50.89
        !            97: h 16 152.179.99.218
        !            98: h 17 152.179.99.218
        !            99: h 18 152.179.99.218
        !           100: