[ntp:questions] Hardware clock fails to update.
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