clock offset is 2.0581 msec, root delay is 29.62 msec root dispersion is 6.81 msec, peer dispersion is 3.30 msec
Are we talking about +/- 30 seconds, or a problem bounded by +/- 30 msec?
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
I've actually been gathering some statistics on this using Munin (http://munin.projects.linpro.no/) on my linux server. There's currently 10 ntp servers being monitored and one of them is a 7600- series Cisco, which is handling quite a bit of traffic (CPU load around 20%). Here are the Munin graphs for it http://dx.fi/alt/ntp/7600.png (times in Finnish time, UTC+2).
In comparison, here are the same graphs for time1.mikes.fi (a stratum-2 clock provided by the Finnish Centre for metrology and accreditation) http://dx.fi/alt/ntp/time1.mikes.fi.png and for Netnods stratum-1 clock in Stockholm http://dx.fi/alt/ntp/ntp1.sth.netnod.se.png
In an NTP scenario, where each device is keeping its own time, and being "disciplined" by several others... don't these spikes of jitter get wiped away -- especially when multiple NTP sources are used? Perhaps I'm mistaken, but I thought that was the point of trying to keep precise time via an imprecise network [the jitter could easily be congestion in the case of long haul links] was that this can be mathematically worked out to a level of precision. Is a Cisco device lying when it says it has 2^18th precision? Are we just comparing and stating that between each sample from any one NTP device we might see wildly differently levels of accuracy/precision and the truly diligent time keeper will discipline his clocks with multiple readings over time? Thanks, Deepak