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
_______________________________________________
questions mailing list
questions@lists.ntp.org
https://lists.ntp.org/mailman/listinfo/questions
