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