Daniel Senderowicz wrote:
Robert,
'Twould appear that something is eating enough processor time to cause
it to miss clock interrupts, and cause the clock to "run slow". Next
I don't understand this. I thought that the hardware clock is a
piece of logic (counters) totally independent of the CPU, therefore
whether the CPU runs busy or not wouldn't make any difference. What
should be running on interrupts is the transfer of the data from
the hardware clock registers to the system clock and if the system
is busy, then it may miss a few transfers but whenever it gets it,
it will be OK, or am I missing something here?
Speaking as a kernel geek, the hardware clock is, essentially, a big
counter that's clocked by either the CPU clock source or an internal
crystal). As long as the clock source is stable AND the scaling
between clock cycles and the counter are correct, it should be fairly
accurate (the clock runs when power is off via the lithium battery on
the mobo--it doesn't simply keep your BIOS settings alive).
The software clock is a software counter that's clocked by an
interrupt, typically the one on IRQ0. If the system spends an
inordinate amount of time in interrupt handlers of higher priority
(IRQ0 is the lowest priority), you may miss clock increments.
Many graphic cards make use of IRQ9, normally tripped during vertical
retrace. If your X driver is inefficient, this can also lead to
lost clock increments. There are certain DMA operations that can
cause interrupts to occur, and again, ineffecient coding can lead to
lost clock increments. And so on and so on.
So, either resynchronize the software clock to the hardware clock
on a regular basis, or use something like ntp to keep it in line.
Of the two, I prefer ntp but that depends on your ability to get to
an ntp server.