[ntp:questions] Re: Synchronisation problems updating to version 4.2.0a on multiple platforms.

Richard B. Gilbert rgilbert88 at comcast.net
Mon Feb 14 03:56:13 UTC 2005


Jacobo.Matute at esa.int wrote:

>Hi,
>
>We have been using without any problem the ntp 4.1.1 in most of our linux
>systems (and in some of our solaris and windows systems) to synchronize with
>two ACOLA NTP servers, that are fed by two GPS Clocks.
>
>We wanted to upgrade to version 4.2.0a on those systems but we are
>experiencing the same problem on all the platforms.
>After ntp boots and the initialisation is done, the client selects a primary
>a secondary ntp server to synchronize. Soon after first synchronisation, the
>ntp servers are marked as falseticker with the status code x1xx, not passing
>the correctness tests ( no intersection interval between the servers).
>
>Also, sometimes, at first sight randomly, the client reselects an ntp server
>and synchronize with it, losing the synchronisation soon after that.
>
>Has somebody experience this problem with the new version? Which would be the
>best way to trace the problem?
>
>Any help would be much appreciated....
>
>Many thanks!,
>
>Jacobo Matute
>
>I attach some info that might help....
>--------------------------------------------------------
>
>We don't use any specific configuration on the ntp.conf file:
>
>
>
>This is the typical ntpq output on a linux box (SLES 9)
>
> # ntpq -p
>   remote           refid      st t when poll reach   delay   offset  jitter
>
>
>==============================================================================
>
> xdgpsas1          .GPS.        1 u   24   64  377    2.017  134.355   1.738
> xdgpsbs1          .GPS.        1 u    2   64  377    2.237  156.553   0.976
>
> # ntpq -c as
>
>ind assID status  conf reach auth condition  last_event cnt
>===========================================================
>  1  5140  9154   yes   yes  none falsetick   reachable  5
>  2  5141  9154   yes   yes  none falsetick   reachable  5
>
>  
>
You have two problems.  The first is that either xdgpsas1 or xdgpsbs1 is 
"insane"!   Two GPS clocks should not differ by more than a few 
microseconds but these differ by about 22 milliseconds.   At least one 
of them is wrong!!!!!  It's quite possible that both are!

The second problem is that there is no way for ntpd to determine which 
one is correct!   Three servers would define an interval from which ntpd 
would select the server nearest the middle of the interval.  A minimum 
of four servers are required to unambiguously vote out one falseticker.  
A really robust design might use as many as nine servers!

Fix one or both of those GPS clocks, as necessary.   Configure at least 
two additional servers as a sanity check.

<big snip>



More information about the questions mailing list