From: Deepak Jain <deepak@ai.net>
Date: Tue, 17 Mar 2009 15:54:28 -0400>
> As long as the end-user is made aware that the accuracy of said NTP
> clock
> is +/- 30.000 seconds (or whatever jitter might exist). Seems kind
> of
> ridiculous to use an NTP source that is, for many purposes, wildly
> inaccurate. For my purposes, wildly is more than +/- 0.1 seconds.
> Trying
> to troubleshoot a problem, network or server, where the timestamps on
> each
> server/router/device vary inconsistently, is like walking on broken
> fluorescent bulbs -- painful and dangerous to one's health.
>Not being a time geek, since Cisco's were called out for being wild
jitter-mongers... how much jitter are we talking about?Clock is synchronized, stratum 2, xxxxxxxxxxxxxxxxxxxxxxxx
nominal freq is 250.0000 Hz, actual freq is 249.9989 Hz, precision is 2**18
reference time is CD6A7CD4.45A9BB00 (19:47:32.272 UTC Tue Mar 17 2009)
clock offset is 2.0581 msec, root delay is 29.62 msec
root dispersion is 6.81 msec, peer dispersion is 3.30 msecAre we talking about +/- 30 seconds, or a problem bounded by +/- 30 msec?
In my testing about 2 years ago (when we deployed dedicated NTP servers
to our POPs), the jitter was highly variable. On a lightly loaded router
we were seeing a reasonable 1 ms., but, if the router was fairly well
loaded it increased to the 20-30 ms. range and we considered that
unacceptable.
Now days we use NTP for latency measurements and we really want better
than 10 usec. and usually get better than 2 usec. on servers with
attached reference clocks and about 150 usec. on systems syncing over
the network.
Since NTP and ICMP are treated about the same, try running a long term
set or pings from a host to the router and see what you get. The PLL in
ntpd will keep the local time much better than what you see, but it does
not make for a very good time source.