If I recall correctly, NTP assumes that latency = RTT/2. You might
make it work well for his application *if* you set up your tree so that
your paths are each one hop, or at least symmetric over your network.
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition of "Firewalls" book)
IIRC, NTP actually sends a packet with a local timestamp, sends it to a remote location for a remote timestamp, and then checks the local timestamp when the packet is received to calculate RTT.
-Richard
Steven M. Bellovin wrote:
Chicken-and-egg problem - even WITH the timestamps, you can't calculate the
actual offset of clocks without making some assumptions regarding RTT. The
assumption NTP makes is that the remote timestamp happened exactly halfway
between your own send and receive timestamps (i.e. that the RTT is symmetric)
I've personally seen our 2 stratum-2 servers diverge *wildly* - through sheer
dumb luck and routing updates, ntp-1 had 6 peers all of which were routed
via our NetworkVirginia link, and ntp-2 had 6 peers all of which went via
our Abeline link. So of *course* one night I get a phone call about the
fact that the two were about 7.5 entire seconds out of sync. Run 'ntpq -p'
on each of them, and see that each is reporting millisecond offsets, but
ntp-2 reported huge delay values.
Seems that this particular night, we were seeing high packet drops and a
consistent 15-second (yes, second) delay *outbound* through some ATM fabric.
I never did get a better explanation than "poltergeists"...