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

jimp at specsol.spam.sux.com jimp at specsol.spam.sux.com
Mon Jan 5 17:45:01 UTC 2009


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?


-- 
Jim Pennino

Remove .spam.sux to reply.




More information about the questions mailing list