Leap second tonight

Kevin Oberman oberman at es.net
Tue Mar 17 22:24:49 UTC 2009


> From: Deepak Jain <deepak at 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 msec
> 
> Are 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.
-- 
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: oberman at es.net			Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4  EADA 927D EBB3 987B 3751




More information about the NANOG mailing list