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

Ulrich Windl Ulrich.Windl at RZ.Uni-Regensburg.DE
Tue Feb 1 12:28:50 UTC 2005


"Lee Sailer" <lee.sailer at direcway.com> writes:

> 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.

No peers? Why don't you four statum-1 servers with a GPS each peer with each
other?

> 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?

Hard to tell without more facts.

> 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.

Regards,
Ulrich



More information about the questions mailing list