System clock running too fast

My system clock seems to be jumping ahead a few minutes when I leave the system on for several hours. My hardware clock works just fine (checked hwclock) and the time reported by the real time clock in /proc/drivers/rtc is correct as well.
I am running Slackware 10 with my own configured 2.6.10 kernel. RTC is on, and, as I said before, works fine.
Any possible reasons for the system clock to be different than the RTC? Are they at all related?

Elad

Originally posted by elahav Any possible reasons for the system clock to be different than the RTC? Are they at all related?

Only insofar as the system clock is set to the RTC when you boot up.

Normally the system clock is more accurate, because it is software-compensated, while the hardware clock relies on the resonant frequency of an unknown oscillator in an unknown (and badly maintained) environment. If you use NTP (or some other mechanism) to set the system clock, then it will also update the hardware clock, so it looks like we can be safe in saying that your system clock is drifting on its own and it's not being set to keep time with some faulty timepiece.

The “system clock” can actually get its time from a number of different sources; you might want to changing the source. From /usr/src/linux/Documentation/kernel-parameters.txt:

clock= [BUGS=IA-32, HW] gettimeofday timesource override. Forces specified timesource (if avaliable) to be used when calculating gettimeofday(). If specicified timesource is not avalible, it defaults to PIT. Format: { pit | tsc | cyclone | pmtmr }

e.g. try booting with the command-line option clock=tsc

I am absolutely certain that I can remember reading somewhere that you can apply a factor to speed up or slow down the Linux system clock, but after searching high and low I just can't find any information on it. However, the most accurate way to keep the clock speed correct is to connect the system to a network and configure it to use NTP. (Linux as an NTP client is surprisingly good at compensating for the different lag times caused by network traffic; NTP will keep the clock accurate to well within a second).

first sorry for long post !
i think /proc/driver/rtc amd /dev/rtc is actually hwclock
the whole kernel system clock thing seems like a bit fudged right now
but my understanding of it is quite limited
i think it uses RDTSC see
/arch/i386/kernel/timers/timer_tsc.c
now i think this is possibly true but don't know
/dev/rtc provides irq interupt signals which can be used for a soft sequencer or something but the systime is using RDTSC because in can be very fine grained without any interupts or i/o overhead at all ? so it doesn't clog up soft irq and get lost in sceduling latency but rather is direct access to the cpu itself.
(i think RDTSC is sometimes refered to as programmable rtc but have nothing to do with hwclock -- which is what we used to call (still do call) rtc but i might be wrong)
i love looking at this code timer_tsc.c it even has a section /* lost tick compensation */
and is full of fudges and calculations
anyway i think (for instance) amd uses 4 different programmable cpu performance counters
when you set the counters you write to model specific registers inside the cpu
for amd
eax, ebx, ecx, edx
and intel uses two
and the kernel sysclock uses two
eax ,edx
and the things arent in any way comatable or the same
they recognize a substantially different set of events.
so full cross platform here is going out the window in favor of the intel stadard in this and the kernel implementation of acpi
anyway (works better with intel inside) might be the way to put it
to add to the mix is acpi that can actually throttle back cpu frequency at idle or high load for temperature consistency. and since the sysclock is using
RDTSC or number of cpu clock cycles since reset and then fudging around with delay times i think it's just kind of inaccurate.
some people are reporting sysclock on certain systems actually running in multiples to actual time
so there is still some work to do for all architectures to work right.

Thanks for the replies, I appeciate them.
I do use NTP to adjust my clock. The only problem is that I used to do it once a week, and now I have to do it every hour to keep my system time fairly accurate
I have one more question: There appears to be a kernel option called HPET, which, supposedly, gives the kernel access to a more relaiable timer. Is there anyway I can tell whether I have this timer in my PC? It's an AthlonXP 2600 with an ASUS A78NX-X motherboard.

Elad

yes you processor does support that so one would assume so does modo and bios
this is in drivers/char/rtc.c i think

try
dmesg | grep timesource

mine says
Using tsc for high-res timesource

it may be that there are other choices
(my hpet timer is not turned on)


unfortunately as far as i know hpet is like the rtc only as a interupt device for software timing not for the sysclock but i might be wrong

read this
http://groups-beta.google.com/group/...1456?hl=en&lr=

they talk about switching to older pit or something called pmtimer
i have heard of people using a 2.6.x kernel boot option clock=
possibly that will help

read this
http://www.vmware.com/community/thre...4254&tstart=75

someone there definitely thinks sysclock can use hpet
they say the default order of sysclock timers is
cyclone, hpet, pmtmr, tsc, pit

don't know about that one
tink i'll try to find parsing of the clock= option in the kernel later for fun