Andy Helten wrote: > jimp wrote: > >> 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? >> >> >> > > Yes, I have heard of ntpdate and I use it when it works. Unfortunately, > maybe you haven't heard it doesn't work with reference clocks? Observe: > > ntp2 root 10->ntpdate -b 127.127.16.0 > 5 Jan 12:13:30 ntpdate[4691]: no server suitable for synchronization found > > Why doesn't it work? I don't know for certain but I'm guessing it is > because the simplistic ntpdate program thinks 127.127.16.0 is an actual > IP address. What next? Let me guess -- have I never heard of "ntpd > -q"? That doesn't work for the same reason that ntpd won't use the > reference clock time: the system time and ref clock differ by more than > the CLOSETIME value of 4 hours. > > No one has answered the OP question and apparently no one understands > the behavior as well as myself and the OP. I was also curious about the > CLOSETIME behavior, but decided on a work around that, in my case, > wasn't that big of a deal. > > Andy
ntpdate is deprecated! Which is not to say that a lot of people don't still use it. Just expect it to disappear from the distribution one of these days! ntpd -g is the preferred means of starting ntpd. The -g tells ntpd to set the clock, stepping if necessary, on a once only basis. _______________________________________________ questions mailing list [email protected] https://lists.ntp.org/mailman/listinfo/questions
