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