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
_______________________________________________
questions mailing list
[email protected]
https://lists.ntp.org/mailman/listinfo/questions
