[ntp:questions] Why would xntpd sync to a bad server?

Lee Sailer lee.sailer at direcway.com
Tue Feb 1 03:28:58 UTC 2005


Let me describe what I think happened, and you all can tell me I am
crazy...

FYI  HP-UX 11.x.  I'd love to show you the output of ntpq -p and so on,
but my company is unusually security conscious, so I cannot.  We are
not military or government, just really careful.

We have 4 GPS clocks (stratum 1), two in Europe and two in the US.
Highly reliable network.  One of the GPS hardware (call it NTS4) in
Europe went bad, so it was about 2.4 seconds different from the other
three.

xntpd is running on a couple of hundred hosts, mostly HP-UX 11.x.  All
stratum 2, no stratum 3, no peers, just clients of the 4 GPS clocks.
The ntpq -p command shows the selection algorithm usually working just
fine, and the xntpd: message in syslog.log looks OK.  That is, xntpd
periodically syncs to one of the "good" clocks.

BUT...every once in awhile, there is a message in the syslog.log file
that xntpd is sync'ing to the bad clock, NTS4.  Why would it do that?
So far as I can see, the other three clocks are all reachable.  Is
there some known circumstance where the algorithm would suddenly decide
the bad clock is the one to use?

Then, the hardware went completely bad, and the bad clock was 461
seconds out of sync with the other three.  The next time xntpd tried to
use the bad clock, I got the "way too large" message and xntpd died all
over the place.




More information about the questions mailing list