Unruh wrote: > [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. >
Then it is a bug because, as previously mentioned, no command line argument or tinker can disable this behavior. I suppose the solution is to skip the CLOSETIME check in clocktime() when '-g' is specified. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
