Try this
"The most common cause of this problem is the CMOS battery, which also
backs up the date and time so it isn't lost when the machine is turned
off. A weak CMOS battery can lead to problems with the real-time clock
even if the battery isn't weak enough to cause the loss of BIOS
settings. Some motherboards apparently disable the clock as a
power-saving measure when the battery voltage gets low."
HTH
Harry
The CMOS battery provides power for a 32KHz clock circuit in the
Southbridge. The timing circuit in the Southbridge is never shut
down, and consumes about 2 microamps while it keeps time. (That is
the current necessary to keep a typical 32KHz clock oscillator
running.) But OSes tend to keep time via a clock interrupt,
something which can run every time the scheduler is run. If the
kernel of the OS happens to remain uninterruptable for longer than
a clock tick period, then a clock interrupt can get lost, and the
software clock will run slow. I cannot think of a plausible mechanism
for a clock running fast, unless drift compensation software of some
kind is involved.
This article gives an idea of how messy all this stuff can be.
I presume somewhere you could find a description for how Windows
does it.
http://paddok.com/how-to/Linux-mini-HOWTOs/Clock
I think the original reason the RTC was separate from the software
clock, was the RTC was very slow to read, so you couldn't possibly
extract time_of_day info in a timely manner. As long as the software
clock is synchronized to the RTC, by listening to IRQ8 and incrementing
a counter for each interrupt, the clocks should stay aligned.
Different strategies can be used, when software like NTP is involved.
Any software that uses drift compensation, can be applying corrections
to the clock, over and above the basic time keeping which is limited
to the accuracy of the 32768Hz crystal located next to the Southbridge.
If the drift compensation used in the OS is wrong, the clock can go
way off.
For time periods finer than one click tick apart, processors generally
have a bus clock based counter. On a FSB800 Pentium, the processor
is clocked by a 200MHz clock, and some number of those clocks would
probably be used to increment a bus clock. The 200MHz clock comes from
a clockgen chip, and the crystal on that is generally only good for
100 part per million accuracy. Such a clock needs to be calibrated
against the RTC, in order to determine how much of an offset there
is between the 32768Hz crystal and the clockgen's crystal. The rdtsc
instruction is used to read the 64 bit counter that is counting bus
clocks. You could even build a software clock based on the high
resolution time stamp, but the accuracy of the clock would be limited
by the 100ppm crystal typically used on the clockgen.
In terms of time keeping problems, the Nforce2 must hold the record
for worst time keeping. You should be able to find the sorry saga
of Nforce2 over on nforcershq.com forums. Here is an example:
"Real Time Clock not so real"
http://nforcershq.com/forum/viewtopic.php?t=19631&highlight=nforce2+clock
On page 10 of that thread:
"WOO HOO!
Thanks to this guy who found a German site that shows how to fix
this problem.
I've tested this in three (ASUS, MSI, Chaintech) nForce2 motherboards,
and this fixed them all.
Ok... This is what I did to get my clock working.
DO THIS AT YOUR OWN RISK (as in back up data, etc.)
And I'm not responsible! This worked for me, I don't know if it will
for you. Go to the "device manager" in windows xp, click on "Computer"
there it will say "Uniprocessor PC", right click and update driver, then
update it to "Advanced Configuration and Power Interface (ACPI) PC".
Restart the computer, then go into the BIOS, then "disable" the APIC
function in the BIOS. Boot into windows, from there it will find your
devices again (CD-rom, IDE, etc.) and your clock should work.
It worked for my brother and I, hopefully it will work for you people
out there, too."
You can do more searching here:
http://nforcershq.com/forum/search.php
HTH,
Paul
