[ntp:questions] ntp not updating the time

David Woolley david at ex.djwhome.demon.invalid
Wed Apr 14 08:55:15 UTC 2010


Marc Fromm wrote:
> I am using RedHat 5.2 and running ntp-4.2.2p1-9.el5_4.1.

Obsolescent.

> 
> The server loses 1 second per minute.

As noted by others, that is not realistically correctable.

> I've been checking it since I manually updated the time and after 2 hours it is 2 minutes and 1 second behind.
> 
> ntpq -p produces the following:
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
>  131.107.13.100  .ACTS.           1 u  858 1024  374    4.431  62588.8 21305.0
> *LOCAL(0)        .LOCL.          10 l   16   64  377    0.000    0.000   0.001

This illustrates why the local clock should never be configured as 
distributed, even though every distributor seems to configure it.  I 
cannot guarantee that ntpd will step without the local clock configured, 
but there is a slight chance that it will not back off the poll interval 
and therefore will not reject the real server due to excessive jitter.

The local clock should only be enabled if both the machine is not a leaf 
node and you completely understand its purpose.  It is never needed for 
leaf nodes.

This is, of course, not a proper fix; the proper fix is to change the 
hardware so that it works properly (typically static frequency error < 
50ppm and wander (non-airconditioned) <5ppm.

> 

>  11 
>  12 # --- OUR TIMESERVERS -----
>  13 server time-nw.nist.gov iburst

This is, of course, a poor choice, as it is heavily overloaded and may 
not be close to you in network terms.  It is generally advised to have 
at least 4 independent servers.  I think there is some chance that they 
would have outvoted the local clock, but, as the local clock is a source 
of last resort I have a feeling that the jitter accumulated in the 
pre-step period might still be too great for any of them to be accepted.

You didn't provide the assoc and rv outputs, which would have given the 
precise reason for rejecting the server, although excessive jitter is 
the obvious reason.




More information about the questions mailing list