[ntp:questions] Why can't clocks do inital synchronization?

Richard B. Gilbert rgilbert88 at comcast.net
Mon Jan 5 23:49:42 UTC 2009


Andy Helten wrote:
> jimp wrote:
> 
>> Andy Helten <andy.helten at dot21rts.com> wrote:
>>   
>>> Heiko Gerstung wrote:
>>>     
>>>> Juergen Perlinger schrieb:
>>>>   
>>>>       
>>>>> Hi everybody,
>>>>>
>>>>> One of the things that can be annoying is that NTPD cannot do an initial
>>>>> synchronization from (most) reference clocks over a difference of more than
>>>>> 4 hours.
>>>>>
>>>>> The reason is that 'refclock_process()' calls 'clocktime()' which in turn
>>>>> will only accept time stamps that are in a hard-coded window of +/- 4h
>>>>> around the sample time (== system time). This makes it impossible for
>>>>> systems to recover from a loss of power if there is no battery-backup
>>>>> driven hardware clock.
>>>>>
>>>>> I appreciate the fact that there are clock signals that do not transmit year
>>>>> information (IRIG-B, as far as I know...) and that clocks using such
>>>>> signals require some processing of the kind 'clocktime()' does.
>>>>>
>>>>> But it's still a nuisance if you have a DCF77 or a GPS clock and the system
>>>>> does not synchronize after boot just because the CMOS is backed by a
>>>>> GoldCap capacitor instead of a real battery. (And getting different
>>>>> hardware is *not* an option for some of us!)
>>>>>
>>>>> I think that the normal panic threshold ('tinker panic') should be the only
>>>>> limit for the acceptance of time stamps, and a disabled panic threshold
>>>>> would permit the system to synchronize even without a backup CMOS clock.
>>>>>
>>>>> While changing the behavior of NTPD wouldn't be too hard to implement I
>>>>> would like to know *why* the clock processing is implemented the way it is.
>>>>> Does anybody know an could enlighten me?
>>>>>
>>>>>     
>>>>>         
>>>> Juergen, did you see the -g command line switch? This one will allow for 
>>>> a one-time correction of the clock even if offsets are greater than the 
>>>> panic threshold value.
>>>>
>>>> Regards,
>>>>    Heiko
>>>>       
>>> No, I don't believe any flag or tinker can disable this behavior.  This 
>>> question is referring to the use of the CLOSETIME macro as a rough 
>>> sanity check on the ref clock's time.  In order to truly change this 
>>> behavior you would need to redefine the CLOSETIME macro and recompile.  
>>> On the other hand, we dealt with this problem by always setting system 
>>> time to the ref clock's time prior to starting up NTP.  For us, this 
>>> required writing a simple piece of C code that was integrated with our 
>>> application that starts NTP.  That was the only solution I found without 
>>> modifying NTP (and that was not considered a desirable option).
>>>
>>> Andy
>>>     
>> Have you never heard of calling ntpdate before starting the NTP daemon?
>>
>>
>>   
> 
> Yes, I have heard of ntpdate and I use it when it works.  Unfortunately, 
> maybe you haven't heard it doesn't work with reference clocks?  Observe:
> 
> ntp2 root 10->ntpdate -b 127.127.16.0
>  5 Jan 12:13:30 ntpdate[4691]: no server suitable for synchronization found
> 
> Why doesn't it work?  I don't know for certain but I'm guessing it is 
> because the simplistic ntpdate program thinks 127.127.16.0 is an actual 
> IP address.  What next?  Let me guess -- have I never heard of "ntpd 
> -q"?  That doesn't work for the same reason that ntpd won't use the 
> reference clock time:  the system time and ref clock differ by more than 
> the CLOSETIME value of 4 hours.
> 
> No one has answered the OP question and apparently no one understands 
> the behavior as well as myself and the OP.  I was also curious about the 
> CLOSETIME behavior, but decided on a work around that, in my case, 
> wasn't that big of a deal.
> 
> Andy

ntpdate is deprecated!  Which is not to say that a lot of people don't 
still use it.  Just expect it to disappear from the distribution one of 
these days!

ntpd -g is the preferred means of starting ntpd.  The -g tells ntpd to 
set the clock, stepping if necessary, on a once only basis.




More information about the questions mailing list