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

More information about the questions mailing list