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. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
