strange system clock issues

[Thomas Charron]

On Wed, Aug 26, 2009 at 4:08 PM, Paul Lussier<p.lussier at comcast.net> wrote:
>
> Hi folks,
>
> I just noticed that my system clock doesn't seem to be working correctly
> all of a sudden.  I wasn't running ntpd, but now I am.  And when I run
> it, it keeps things up to date for a bit, but watching the "seconds"
> tick by seems very slow, I can actually count 5 "mississippi"s between
> "seconds" on the clock.
>
> After the clock gets about an hour (maybe it's 2) out of sync, ntpd
> fails to sync and gives up.  Is this a system clock battery problem ?
> The system in question is about 10 years old...

  Does the dmesg output complain at all about a real time timing
source?  Ben is correct, that the hwclock command will interigate the
real time clock directly, which shouldn't be confused with the system
clock, which is maintained by the kernel.  At startup, the RTC is
interogated to set the system clock, and then is only used again if..
Actually, I can't think of much that would requery it unless it is
specifically opening it to do something outside of the kernel.

  However, the RTC itself will generate a system time interupt every
second.  This interrupt is used to maintain the time by using the
leading edge of the signal.  If the RTC is acting wacky, then this
could describe the behavior of what you are seeing.  The counts that
Ben refers to below are the interrupt count of that once a second bang
of the RTC interupt.  It *should* go off once per second.  If it
doesn't, then the system time could get out of wack.


  ** HOWEVER **

  Most RTC clocks *can* generate an interupt, but the kernel itself,
once it has gotten the time FROM the rtc, may use one of MANY system
clocks to maintain the system time.  Many times I've seen the kernel
report that a given clock source has become unstable, and it reverts
to another one.  Do you have any messages in dmesg complaining about a
clock source being out of wack?

-- 
-- Thomas