[email protected] writes: >Andy Helten <[email protected]> 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? uh, ntpdate is severely depricated, and ntpd -g is what is supposed to be used. If ntpd -g fails it is a bug. >-- >Jim Pennino >Remove .spam.sux to reply. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
