[ntp:questions] Re: Why would xntpd sync to a bad server?
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
> 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
> 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
> 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.
More information about the questions