Hi all, do you have any recommended tools that can measure latency/delay hop by hop basis? Preferable the tools can measure the running (live) traffic.
Regards,
Steven Lee
Hi all, do you have any recommended tools that can measure latency/delay
hop by hop basis? Preferable the tools can measure the running (live)
traffic.
mtr ? - MTR
its an ncurses app.. output like to:
Host Loss% Snt Last Avg Best Wrst
StDev
1. 89.202.212.124 0.0% 7 0.4 0.5 0.4 0.6
0.0
2. xe-7-1-0-0.ams-koo-score-1-re0.i 0.0% 7 0.3 2.9 0.2 18.9
7.0
3. po1.ccr01.ams03.atlas.cogentco.c 0.0% 6 1.3 3.8 1.3 16.0
6.0
4. te2-4.3490.ccr01.ams03.atlas.cog 0.0% 6 1.1 1.1 1.1 1.2
0.0
5. te2-3.mpd02.lon01.atlas.cogentco 0.0% 6 8.0 9.9 7.9 19.6
4.7
6. te9-3.ccr02.jfk02.atlas.cogentco 0.0% 6 91.9 91.9 91.8 91.9
0.0
7. te8-3.ccr01.dca01.atlas.cogentco 0.0% 6 92.0 95.0 91.7 111.2
7.9
8. te9-1.ccr02.dca01.atlas.cogentco 0.0% 6 92.1 92.2 92.1 92.4
0.1
9. vl3896.na32.b001806-1.dca01.atla 0.0% 6 92.3 93.1 92.3 94.1
0.7
10. 38.104.30.102 0.0% 6 92.0 92.0 92.0 92.1
0.1
11. www.joost.com 0.0% 6 92.0 91.9 91.8 92.0
0.1
thanks
Andrew
perfSONAR is another, more long term solution for performance monitoring (if that's what you happen to be looking for).
FWIW, Mtr measures latency/delay and loss based on ICMP messages heard back from the routers on path. As a result, in almost all cases, the real hop-by-hop latency of actual end-to-end data packets is better than it can report.
I don't know if it helps, but anyways. There is another tool called Iperf (
http://sourceforge.net/projects/iperf ). It's usually used to report
bandwidth between two hops which you define, but it can be also used to
measure jitter, datagram loss, and a lot of other things, one in all it's
very handy if you want to get some idea regarding the network performance.
This and others mentioned here by other posters can all be found (once again) at:
http://kb.pert.geant2.net/PERTKB/MeasurementTools
Not all tools are listed on that page. You need to go into the specific sub-pages:
http://kb.pert.geant2.net/PERTKB/TracerouteLikeTools
http://kb.pert.geant2.net/PERTKB/BandwidthMeasurementTools
Regards,
Hank
mtr has a recently added '-u' option to use UDP instead of ICMP echo requests.
Lee, Steven (NSG Malaysia) schrieb:
Hi all, do you have any recommended tools that can measure
latency/delay hop by hop basis? Preferable the tools can measure the
running (live) traffic.
Try Smokeping for long-term latency stats: SmokePing - About SmokePing
Fredy
But that doesn't change the gist of my message: it's still relying on ICMP ttl exceeded messages sent by the routers on the path to check the delays etc. As such it suffers from basically the same limitations as ICMP probing.
A tool which I have heard of is Chariot. I have not used this tool
myself and am not aware of its capabilities.
I would be interested if anyone else has heard of it and can make any
sort of recommendation.
Christine
Mtr is even less usefull then that, in its default mode it does a traceroute and then proceeds to ICMP Ping flood each IP in the list generated by the traceroute, the result is usually completly useless on WAN topologies due to asym-routing, ICMP node protections by carriers and punting etc..
And using UDP will not really provide better results due to the same thing, and IIRC Cisco from 12.0 has a standard setting of no more then 1 ICMP Unreach per 500ms..
If the question is to measure hop by hop latency from source to destination, perhaps across routers you don't manage, how can this be done without using the ICMP time exceeded messages? End to end latency is easily done with Smokeping and the use of TCP (SYN, SYN ACK, ACK, RST) and them timestamp it. This gives you a very clear idea on application latency on any tcp port. Hop by hop is a different story and the only option I know of is with the reliance on the ICMP mechanism. One additional question on this; how do you measure hop by hop when the path dynamically changes, and then record the path change (time/date and the differences in latency on the new path)?
Mike
Well, to be somewhat cynical about it, you don't.
Either you have an SLA with a delay component, if that is the case the delay is either end-to-end if everything is in the same AS, or host-to-border if the other end is in some other AS. If this is the case you would already have an agreed upon measuretool (ex. SLA probes) and specified measuring points.
If you dont have a specified delay clause in your SLA then it is best effort and irrelevant, in either case the hop by hop delay seen is academic at best..
So as long as your delay is lower then specified by the SLA the only result from trying to be "smart" and complaining about large hop to hop delay is that the engineer you talk to will call you names after he/she hangs up, or if it is over it is still very little/nothing you can do but wait and let the carrier engineers fix it.
then connect to a udp service with something like nsping
Lee, Steven (NSG Malaysia) wrote:
Hi all, do you have any recommended tools that can measure latency/delay hop by hop basis? Preferable the tools can measure the running (live) traffic.
Regards,
Steven Lee
Not necessarily hop-by-hop, and measures RTT rather than one-way delay,
but if you can packet-sniff at two points in your network our SPP
(Synthetic Packet Pairs) tool for passive round trip time estimation
might be of interest - Synthetic Packet Pairs (SPP) - Tool for passive round trip time measurement
Key benefits - you don't need tight clock synchronisation between
measurement points, and you can measure RTT using existing traffic
flowing across your network (no additional traffic needs to be
injected). Key downside - its a research project, only tested under
FreeBSD, and may be entirely unsuitable 
cheers,
gja
Lee, Steven (NSG Malaysia) wrote:
Hi all, do you have any recommended tools that can measure latency/delay
hop by hop basis? Preferable the tools can measure the running (live)
traffic.
Tools like smokeping, mtr, traceroute and all that will give you highly
skewed results, whose accuracy will usually depend entirely on how busy the
CPU is which responds to host IP packets (whether icmp, udp or even tcp).
As most large routers push everything through hardware, if you measure your
hop latency using inline router response times, your results will be trash.
If you want to do this properly, you will need to install dedicated
measurement hosts hanging off each router and measure response times to
them instead. RIPE TTM boxes are pretty good for this:
Nick
Lee, Steven (NSG Malaysia) wrote:
Hi all, do you have any recommended tools that can measure latency/delay hop by hop basis? Preferable the tools can measure the running (live) traffic.
One other freeware/open-source tool you might want to look at is pchar which attempts to characterize available bandwidth on each link.
Antonio Querubin
whois: AQ7-ARIN
intersting never heard of 
Mtr is even less usefull then that, in its default mode it does a traceroute and then proceeds to ICMP Ping flood each IP in the list generated by the traceroute, the result is usually completly useless on WAN topologies due to asym-routing, ICMP node protections by carriers and punting etc..
No, it doesn't try pinging the routers in the middle, at least not anymore (I just re-checked with 0.71 and 0.75). I vaguely recall behaviour like that in the past, however, so it's possible that long time ago mtr did behave that way.
And using UDP will not really provide better results due to the same thing, and IIRC Cisco from 12.0 has a standard setting of no more then 1 ICMP Unreach per 500ms..
This is true and the point I was getting at, though I believe the bucket is much larger in any recent software release (also in 12.0 series). Actually, 5 years ago, you could see spot Cisco routers in "traceroute6" because they dropped the rate-limiter didn't respond to the middle packet and it resulted in a star. The rate-limiter has long since been fixed to be more lenient.