On 26 Aug 99, at 15:16, Ken Cornell wrote:

> To Greg, here's a little info from PCGUIDE'S topic page.
>
> The system clock is losing time or not keeping time accurately
> Explanation: The system clock is not accurate; it loses a number of
> minutes each day, or stops incrementing the time when the system is turned
> off.
>
> Diagnosis: The most common cause of this problem is the CMOS battery,

  Reading that again, with emphasis:

> Explanation: The system clock is not accurate; it loses a number of
> minutes each day, or stops incrementing the time WHEN THE SYSTEM IS TURNED
> OFF.

  Now looking at the original question:

> Greg Anderson wrote,
>
> > .... If
> > the customer leaves the computer powered on for over 24 hrs it will
> > begin to loose time, maybe a 4-9 minutes. It will continue to loose time
> > over each succesive day.


  If the system loses time while powered OFF, it is the "real-time clock"
(rarely/incorrectly called the "system clock") that is running slow; this
clock is powered off the same battery as the CMOS storage, and this is indeed
symptomatic of a battery that is starting to fail.  PCGUIDE's diagnosis and
recommendation are appropriate to this case.

  However, that clock is used primarily to initialize the "system clock" when
the machine is booted, or when it returns from a power-standby state.  The
system clock does not routinely check itself against the real-time clock
while the system is running -- and it is THIS clock that is losing time.
  Indeed, in this case the system clock will be seen to reset to the correct
time when the system is rebooted, indicating that the real-time clock is
working fine and the CMOS battery is probably okay -- and so the PCGUIDE
diagnosis does not apply!

  The normal case is for the system clock to be updated every 55ms
(roughly...) by a timer pulse on IRQ 0, which is reserved for this purpose.
Typically, the way the clock becomes slow is for these pulses to be "missed",
which in turn generally means that it (often enough to make a perceptible
difference) is taking the CPU more than 55ms to notice and respond to IRQ 0.
  This probably means that the CPU is spending too much of its time executing
code that cannot be interrupted by IRQ 0.  I'd expect to see such code inside
some kinds of device drivers, or in code associated with virtual memory
swapping or drive compression, and *possibly* virus detection.
  So fixes might include:

- updating to more recent drivers, which might include bug fixes

- increasing installed RAM to reduce frequency of swapping

- installing larger hard drive(s) to allow running without compression

- modifying background virus check settings

- reducing the amount of multi-tasking you try to do

  or, just possibly, installing a faster CPU, so that it executes as much
problematic code, but in a shorter time.


  [I have observed a similar problem on one of my own machines, and have not
yet exhausted all of these possibilities.  Another approach, though, is to
install one of the various utilities to synchronize your PC's clock with some
reliable external signal over the network, and run that every day....]


David G

         The PCBUILD web site always needs good submissions.  If
          you would like to contribute to the website, send any
               hardware tech tips or hardware reviews to:
                           [log in to unmask]