[ntp:questions] Re: Why would xntpd sync to a bad server?
Richard B. Gilbert
rgilbert88 at comcast.net
Tue Feb 1 13:26:59 UTC 2005
Lee Sailer wrote:
>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.
>
>
>
Since you say "xntpd", I have to assume a really old version; xntpd
became ntpd at V4.0. V4.2 is now current.
It might be a good idea to upgrade.
Old as it is, however, xntpd was not supposed to do that!
I would suspect that the configuration with two clocks in Europe and two
in the US might be inclined to instability. Any part of Europe is a
long way away from even the east coast of the US. It's close to half
way around the world from the west coast. Long distances and the
consequent long round trip delays do not work quite so well as shorter
distances. If possible, it might help to add a couple more GPS clocks
to your network; one in the US and one in Europe. If accuracy and
reliability are critical, consider adding two in the US and two in
Europe. With four on each side of the pond everybody has four. more or
less local, clocks to rely on and four, more distant, clocks for
backup. You also have sufficient clocks to defend against two failing
clocks.
More information about the questions
mailing list