Leap second tonight

Wed Mar 18 19:31:52 UTC 2009

> > 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 msec
> >
> > Are we talking about +/- 30 seconds, or a problem bounded by +/- 30
> msec?
> 
> 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