[ntp:questions] Re: NTP does not sync; increasing offset - problem with local clock?

Richard B. Gilbert rgilbert88 at comcast.net
Sat Jun 11 19:28:32 UTC 2005


Dr. Torsten Rupp wrote:

> Dear NTP-users,
>
> I tried for a while to make NTP running on a Suse 9.0 based system, 
> but it seems there is strange problem I do not understand: after 
> starting ntpd it took some time to synchronize to a server. The log 
> from ntpc:
>
> *ntp1.ptb.de     192.168.1.20     1   16  377 0.02094 -0.032411 0.00124
> =time-a.nist.gov 192.168.1.20     1   16  377 0.10571 -0.033428 0.00128
>
> This looks nice, but after some time (a few minutes) the reported 
> time-offset is increasing:
>
> *ntp1.ptb.de     192.168.1.20     1   16  377 0.02083 14.481775 0.00075
> =time-a.nist.gov 192.168.1.20     1   64  377 0.09814 12.172259 0.00266
>
> The time on the computer is really quite wrong. It took some more 
> time, then the time is adjusted in a single big step with the 
> following output of ntpdc
>
Your first problem is that you appear to have configured only two 
servers!   Two is the worst possible number of servers!!!   When two 
servers disagree, as they almost inevitably will, ntpd has no means to  
determine which one is more nearly correct or if either of them is 
correct.  Configure one simply to synchronize with whatever time the 
server keeps.  This is adequate for some applications but is not optimal.

Four servers is the minimum number that will protect you against a 
single bad server.  Seven servers will protect you against the failure 
of two of them.

> =ntp1.ptb.de     192.168.1.20    16   16    0 0.00000  0.000000 0.00000
> =time-a.nist.gov 192.168.1.20    16   16    0 0.00000  0.000000 0.00000
>      remote           local      st poll reach  delay   offset    disp
> =======================================================================
> =ntp1.ptb.de     192.168.1.20    16   16    0 0.00000  0.000000 0.00000
> =time-a.nist.gov 192.168.1.20    16   16    0 0.00000  0.000000 0.00000
>      remote           local      st poll reach  delay   offset    disp
> =======================================================================

Now; for reasons unknown (to me), your two servers have become 
unreachable!  The "reach" field is zero.  At each poll interval, a one 
bit is left shifted into the reach field if a reply is received from the 
server and a zero bit if no reply is received.  A value of 377 (octal) 
indicates that the last eight attempts were successful.   The value of 
zero indicates that the last eight attempts were failures.

Also, the poll interval should not be sixteen seconds!  The value 
suggests that you have specified a MINPOLL value of 4,  (2^4=16).  The 
default value of MINPOLL is 6 and should not normally be changed.

Your choice of servers appears to be ill considered unless you are 
located in the middle of the Atlantic Ocean.   time-a.nist.gov is 
located in Maryland and ntp1.ptb.de is located somewhere in Denmark.  
Normally the best servers are the ones nearest to you; e.g. those with 
the lowest round trip delay.

> =ntp1.ptb.de     192.168.1.20    16   16    0 0.00000  0.000000 0.00000
> =time-a.nist.gov 192.168.1.20    16   16    0 0.00000  0.000000 0.00000
>      remote           local      st poll reach  delay   offset    disp
> =======================================================================
> =ntp1.ptb.de     192.168.1.20     1   16    1 0.01979  0.016320 7.93750
> =time-a.nist.gov 192.168.1.20     1   16    1 0.10609  0.012647 7.93750
>      remote           local      st poll reach  delay   offset    disp
> =======================================================================
> =ntp1.ptb.de     192.168.1.20     1   16    1 0.01979  0.016320 7.93750
> =time-a.nist.gov 192.168.1.20     1   16    1 0.10609  0.012647 7.93750
>      remote           local      st poll reach  delay   offset    disp
> =======================================================================
> =ntp1.ptb.de     192.168.1.20     1   16    1 0.01979  0.016320 7.93750
> =time-a.nist.gov 192.168.1.20     1   16    1 0.10609  0.012647 7.93750
>      remote           local      st poll reach  delay   offset    disp
>
> The problem does not disappear, even I wait for a whole day.
>
> My questions:
>
> - Why is NTP not able to keep the time in sync? Is there a problem 
> with my local clock which seems to be too "slow" (more then 500 PPM)? 
> Could there be a problem with the kernel (it is the orignal Suse 9.0 
> kernel 2.4.21-215-athlon, no SMP)? Could there be missing interrupts? 
> How do verify this?
>
> - Why there is a server marked with a "*" even the time offset is 
> quite large?


A server marked with "*" has been selected by ntpd as the server it will 
attempt to synchronize with.  It does not imply that synchronization has 
occurred!

>
> Any help is welcome. Thank you very much.
>
> Torsten
>



More information about the questions mailing list