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

Martin Burnicki martin.burnicki at meinberg.de
Wed Apr 16 13:50:22 UTC 2014

Mimiko wrote:
> I don't understand, why so much trouble about clocks in linux?

You're wrong. Most trouble with clocks is due to Windows.

> In
> windows systems, there is a default time service which synchronise with
> some time server or domain controller and automatically sets hw (and
> maybe system's internal) clock.

As far as I know Windows only set the time in the RTC chip only when the 
system time is also set to some new time. So always if you go to the 
clock control panel and change the time the RTC is set.

If you run the NTP service then normally the system time is only 
disciplined smoothly, by increasing or decreasing the tick adjustment 
count a little bit. So unless something unexpected happens to the 
timekeeping the system time is never set during operation, and thus the 
time in the RTC chip is never updated.

However, when the NTP service is shut down then it stops disciplining 
the system time anyway and thus calls the Windows API which sets the 
time with the current time as new time. This should force Windows to 
update the time in the RTC chip.

> If system is set to some localtime,
> windows corrects hw clock to localtime also. Here comes problems in dual
> boot.

Exactly. And the main reason for dual boot problems is that Windows set 
the RTC time to local time instead of UTC.

If you have a pure Linux (or other Unix-like) system the RTC chip could 
always keep time as UTC or TAI, as already mentioned elsewhere in this 
thread, and there wouldn't be any problem at all.

> Of course, time servers must have UTC time,

Similar to Unix-like systems all Windows versions since NT distinguish 
between internal system time kept in UTC and local time displayed to the 
user, converted according to user preferences.

> ... but why not correct hw clock
> using localtime if it is configured in system? Anyway, the problem is
> not about localtime or utc standard, but that ntpd does not correct hw
> clock at all. Its related to fact that ntpd can be chroted. But why
> there is no mention in docs of ntpd that it will correct only kernel time.

Usually it is sufficient to set the RTC on system shutdown, so that it 
keeps time while the machine is powered off, and initialize the system 
time from RTC time when the system boots.

Imagine what happens if you shut down Windows *before* DST starts and 
reboot *after* DST has started? Your system time will be off by 1 hour 
because standard time has been written to the RTC at shutdown, but DST 
is assumed to be read from the RTC at boot time, while the RTC in fact 
was still running at local standard time.

If you have a dual boot system where Windows writes local time to the 
RTC chip you can configure Linux (and probably *BSD) to expect local 
time instead of UTC to be read from the RTC.

If that configuration isn't done properly (i.e. Linux expects the RTC to 
run UTC) then of course the initial Linux system time will be off by one 
or more hours whenever you boot Linux after Windows.

If the Linux system is configured properly, i.e. expects local time from 
the RTC, there won't be any problems *except* if different default time 
zones have been configured in Windows and Linux, or if a DST change 
occurred while the machine was powered off.

All these potential problems wouldn't arise if you could let the RTC 
chip always run UTC, so every (dual-booted) OS could always start up 
with the same UTC time, regardless of some time zone setting.

The obvious approach to achieve this would be to convince Windows to 
write UTC to the RTC chip at shutdown, and expect UTC from the RTC at 
startup. There is some registry key which should instruct windows to do so.

However, the last time this was discussed here someone mentioned that 
the registry key isn't honored by the Windows OS as expected. I'm not 
sure if Windows used local time anyway, or if Windows didn't write to 
the RTC at all when the registry key was present. In any case it didn't 
work as supposed to. Google may help you to find this discussion.

> So using that cron job, I hope hw clock will be in sync an no problem
> will arise in future.

Except the ones I've mentioned above.

> Thank you.

You're welcome.

Martin Burnicki

Meinberg Funkuhren
Bad Pyrmont

More information about the questions mailing list