[ntp:questions] Automatic time synchronization of local hw clock.

William Unruh unruh at invalid.ca
Thu Apr 17 23:42:33 UTC 2014


On 2014-04-17, Jochen Bern <Jochen.Bern at LINworks.de> wrote:
> On 17.04.2014 14:00, questions-request at lists.ntp.org digested:
>> From: Martin Burnicki <martin.burnicki at meinberg.de>
>> 
>> Usually it is sufficient to set the RTC on system shutdown, so that it 
>> keeps time while the machine is powered off
>
> That is, of course, assuming that the machine in question *has* an
> *orderly* shutdown every now and then. Servers in well-protected
> internal networks may well see far more crashes (and "WTH is the RTC set
> to!?" questions by not-yet-initiated operators) than intentional shutdowns.
>
> (Never tried it, but wouldn't laptops that get suspended and then
> somehow are forced to go through a full reboot instead of a wakeup
> circumvent that sync "schedule", too?)
>
>> From: William Unruh <unruh at invalid.ca>
>> 
>> I do not believe that ntp ever considers it its job to write the rtc.
>
> If I'm not *very* much mistaken, very old versions of (x)ntpd (predating
> Linux' support of localtime RTCs to allow for a dual-boot setup with
> Win, if not predating Linux altogether) contained code to do periodic

The kernel has ( and has had probably since 2.2 kernel or earlier) an 11
min mode. If the time system believes that it is synchronized then every
11 min the kernel (not ntpd) writes the system time to the RTC. This is
not something ntpd does. 

chrony, written for non-networked machines in part, has a much more
extensive rtc handling. It disables the 11 min mode ( by telling the
kernel that the clock is never synchronized) but it measures the rate
error and offset error of the rtc, and uses those to compensate when it
is next brought up (eg after a reboot). It also has internally the
ability to adjust the RTC. 

Note that chrony can tolerate an rtc that is off by 8 hours say, it
simply compensates when it next starts becaue it knows about the offset.
Or off by 6123 sec. say. 
ntpd assumes that the system clock is correct unless it measures
otherwise from an outside source, no matter what the rtc says. 
Usually hwclock is used to initially set the system time from the rtc (
and it also has the ability to adjust for the rate and offset of the
rtc) and then ntpd chimes in.


> updates to x86 RTCs directly (assuming them to run on UTC, of course),
> said functionality *missing* in the back-then Unixoid OSes on x86. Of
> course, that went down in flames when non-UTC RTCs came a-knockin' and
> required the OS to join in and do the UTC-localtime conversion for the
> non-zone-aware players.
>
> Regards,
> 								J. Bern



More information about the questions mailing list