[ntp:questions] ntp not updating the time

Richard B. Gilbert rgilbert88 at comcast.net
Wed Apr 14 14:03:01 UTC 2010


David Woolley wrote:
> 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.

I don't think you mentioned the evils associated with using two time 
sources.  It is written that a man with two clocks can never be certain 
what time it is!

The magic numbers for a robust configuration are four, five, or seven 
sources.  These numbers allow the failure of one, two, or three clocks, 
respectively.  "Failure" can mean no response or incorrect response. 
The last NTP Survey turned up one clock that was responding with the 
wrong year!  This sort of thing does not happen often but it is 
something you should be prepared for.




More information about the questions mailing list