Hardware clock fails to update. - NTP

This is a discussion on Hardware clock fails to update. - NTP ; >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." ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Hardware clock fails to update.

  1. Hardware clock fails to update.

    >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.

    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.

    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.

    >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.

    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.


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

    --
    Bryan Henderson Phone 408-621-2000
    San Jose, California
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: Hardware clock fails to update.

    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
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  3. Re: Hardware clock fails to update.

    >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.


    I think that's a Microsoft "feature". I think I've seen comments
    about some other not very common OS doing it that way too.

    All of the systems I work with run the HW clock in UTC. I think
    there are options to run it in local time if you want to dual boot
    a MS OS, but I've never paid attention to that.


    --
    The suespammers.org mail server is located in California. So are all my
    other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
    commercial e-mail to my suespammers.org address or any of my other addresses.
    These are my opinions, not necessarily my employer's. I hate spam.


+ Reply to Thread