[time-nuts] Low-long-term-drift clock for board level integration?

Hal Murray hmurray at megapathdsl.net
Wed Feb 22 11:59:31 UTC 2012


Is this discussion wandering too far off topic for time-nuts?  If so, where 
should we move it to?


I've been collecting NTP log files for a while.  Here are some graphs.

These are all round trip times rather than one way.  That makes the data a 
lot cleaner.  I'll work on some one-way graphs tomorrow.

One system collected all the data.  It's clock is good, not great.  (but 
shouldn't matter for these graphs)

My link to the internet is a 384K (S)DSL line.  Most of the time it's idle.  
I've seen queuing delays of 3.5 seconds.

I'm in Menlo Park, California.  (Silicon Valley)

First, the simple case.  This is a pair of local systems connected to the 
probing system by a 100 megabit switch.
  http://www.megapathdsl.net/~hmurray/net-timing/hist-local-rtt.png

This is a nearby NTP server at ISC.
  http://www.megapathdsl.net/~hmurray/net-timing/hist-isc-rc-rtt.png
It's about 3.5 miles from here as the crow flies.  Traceroute says 9 hops.

This is another nearby server, a USNO system at HP Labs.
  http://www.megapathdsl.net/~hmurray/net-timing/hist-usno-pa-rtt.png
It's roughly the same distance in the other direction.  Traceroute says 8 
hops.

This one is more complicated.  The differences in timing between the red and 
blue graphs are probably due to some change in routing.  I expect if I search 
around I can find a time in 2011 when it happened.

I think those two systems represent about as good as you can expect if you 
plan to use nearby stratum 1 systems.  You could probably do slightly better 
if your ISP had a good time server as long as it was close rather then back 
at headquarters.

There is another quirk in that graph.  Note the green tail on the left.  It 
goes all the way to 0.  It went negative until I filtered out some bogus 
samples.  (Obviously, I didn't get them all.)  I think the OS clock on that 
system was broken for a while.


This is to the NIST system in Gaithersburg MD, across country from here:
  http://www.megapathdsl.net/~hmurray/net-timing/hist-nist-md-rtt.png
I don't see anything strange.

This is the NIST system in Boulder CO:
  http://www.megapathdsl.net/~hmurray/net-timing/hist-nist-co-rtt.png
I think all the split peaks are routing changes.

This is a USNO box in Texas (University of Houston):
  http://www.megapathdsl.net/~hmurray/net-timing/hist-usno-tx-rtt.png
Initially, it attracted my attention because the routing was normally very 
asymmetric.  The peaks on the right are the asymmetric mode.  I think the 
packets were going by Chicago and returning by Los Angeles, or something like 
that.  Occasionally, something would happen and it would switch to a shorter, 
symmetric mode for a while (few hours to several days).  I assume some link 
broke and switched some traffic to an alternate path that was good for my 
case (but probably bad for many others).

The blue peak is now the normal case.  I assume somebody tweaked the routing 
or added another link.


This is a cluster of 4 servers that are all in/near Boulder CO.
  http://www.megapathdsl.net/~hmurray/net-timing/hist-co-2012-rtt.png
The first 3 are all within a few miles of eachother.  WWV is outside Ft 
Collins, an hour and a half north.  From here, they are all equidistant.  One 
might expect the timings to be similar.


I also filtered out a few samples with round trip times over 5 seconds.  I've 
seen times over 30 seconds.  I think some box is rebooting or playing with 
its routing tables and another box is hanging on to packets that it should be 
dropping.


-- 
These are my opinions, not necessarily my employer's.  I hate spam.






More information about the time-nuts mailing list