[ntp:questions] Hardware clock fails to update.

Frans Grotepass fmgrotepass at yahoo.co.uk
Fri Aug 4 09:09:35 UTC 2006

On Friday 04 August 2006 04:32, Bryan Henderson wrote:
> >Various internet searches pointed to the fact that hardware clock syncing
> >being placed under the responsibility of ntp.
> Sort of.  Ntpd on Linux does a system call that tells the kernel "I'm
> keeping the system clock set to authoritative time."  Based on that
> information, the kernel copies the system clock time to the hardware
> clock every 11 minutes in an attempt to keep the hardware clock also
> correct.  If you weren't running Ntpd, you'd have to keep your hardware
> clock correct some other way.

Thanks for the extensive explaination. This is how I understood it, but I 
assumed that there will be a kernel option to turn off the kernel 11minute 
update. U only found the option to keep RTC on UTC ( a nobrainer for an 
embedded system). (Edit: just found it in Character devices)

> The hardware clock, for historical reasons, keeps a local time value
> -- i.e. you have to interpret it in the context of a particular time
> zone and it won't tell you which one -- you have to know
> independently.  Since your error is a whole number of hours, I suspect
> the problem is that someone's idea of that time zone is different from
> someone else's.

Mmm, Timezone is something that I'd rather forget in our application. Working 
with zones and DST always adds confusion. NTP works on UTC for very specific 
reasons. A clearly defined time with clear reference to past and future. DST 
and timezones muddle this in all respects.

> The kernel has no idea what that time zone is, so its every-11-minute
> update adjusts only the sub-hour part of the clock; i.e. it cannot
> recognize or correct a 7200 second error.

Interesting! this I didn't know. This might be my problem. 

> >how can I check that NTP tries to update the hardware clock?
> The canonical program for manipulating the hardware clock is 'hwclock'.
> You can run it with no options to see what time the hardware clock has
> and see whether and when it is 7200 seconds wrong.

Didn't work without /dev/rtc. I will try to set it up soon.

> To confirm that the kernel believes Ntpd is keeping the system clock
> authoritative (and therefore should be updating the hardware clock),
> run 'adjtimex --print' and look at the "status" line.  The value is a
> decimal number.  Expressed as a binary number, the "64" digit should
> be 0.
> >Upon restarting, the clock returns to its 7200 second offset.
> Somewhere in the startup scripts, something should run Hwclock in
> order to set the system clock from the hardware clock to hold it over
> until Ntpd can get going.  Maybe all you have to do is use 'hwclock
> --systohc' once to set it to the proper hour and it will be OK at the
> next boot.

Will check it out. The main probem is a power failure, but with 11minute 
update and RTC on UTC all should be fine.

> There's a lot of information about the hardware clock and this oddball
> kernel updating function in the man page for Hwclock.

More information about the questions mailing list