[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_lists.febo.com
mailing list