[ntp:questions] Automatic time synchronization of local hw clock.
martin.burnicki at meinberg.de
Tue Apr 22 09:24:11 UTC 2014
Jochen Bern 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.
With a properly configured NTP service which is started when the system
boots the system time should be stepped quickly after reboot.
Whenever the system time is stepped (not just slewed) the RTC chip is
updated by the Windows OS, AFAIK.
Also, AFAIK, *setting* the Windows system time is the only way which
updates the RTC chip using a documented Windows API call.
If ntpd would call SetSystemTime() periodically just to update the RTC
chip then the ntpd's filter would always be messed up due to the
latency/limited resolution/execution time of that API call.
If ntpd would try to access the registers of the RTC chip directly via
some kernel driver or so, then
1.) ntpd had to find out first if the RTC chip should be local time or
UTC, if the undocumented registry key had been set
2.) As has been reported by someone else, current Windows versions seem
to remember if they had set the RTC to standard time or DST on shutdown,
and take this into account at reboot. Setting the RTC without notifying
the Windows OS would bypass this, so you the system might come up with
an initial time off by 1 hour anyway.
> (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?)
Never tried this, either.
More information about the questions