NTP peer delay seems wrong

[bbrunette]

I am looking at using NTP statistics as a quick measure of latency in our WAN, but can't make sense of the numbers. For example, I have a router on the same LAN as its NTP peer and 'sh ntp associations' gives this:

address ref clock st when poll reach delay offset disp

+~10.68.50.6 128.252.19.1 2 54 1024 377 1.8 -0.21 0.2

*~10.68.50.5 128.252.19.1 2 466 1024 377 1.9 0.15 0.1

* master (synced), # master (unsynced), + selected, - candidate, ~ configured

My questions are:

1. Is there really 1.8 and 1.9 seconds of delay between these peers?

2. If so, how does that square with ping response times in the 1-4 msec range?

3. Why does a query of the SNMP MIB show 0.127 and 0.116 seconds of delay (MIB var: .1.3.6.1.4.1.9.9.168.1.2.1.1.24 queried using Getif)?

4. Is NTP peer delay a reasonable way to measure network latency or am I barking up the wrong tree?

Thanks in advance.

Bob

[faheyd]

1. I believe that's 'millisecs', see http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/fun_r/frprt3/frd3003.htm#13931 .

2. Switching fabric has different priorities as to which packets it pays attention to first. I think a real Cisco Engineer might be better off explaining this one. 3. See answer number two. 4. See http://www.cisco.com/warp/public/126/performwp.htm , apparently lantency depends on the load and 'type' of packet you are transmitting, aka data vs voice. The reference URL shows that measuring latency alone wont help you reveal everything you need to know about your network. It's a package deal along with the size of the pipes, distance, jitter, traffic type, age of your equipment (components), etc.

I like your idea of using the NTP stats to help show that type of info. However, since ping/traceroute/'sh int' give most responses in milliseconds, that's about as much granularity as I need to make accurate assessments of how my network is 'working'.