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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
