[ntp:questions] ntp not updating the time
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.
> 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
> 126.96.36.199 .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
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.
> 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