linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: George Anzinger <george@mvista.com>
To: Praedor Atrebates <praedor@yahoo.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: System clock speed too high - 2.6.3 kernel
Date: Sat, 27 Mar 2004 08:09:10 -0800	[thread overview]
Message-ID: <4065A726.50506@mvista.com> (raw)
In-Reply-To: <200403261657.22738.praedor@yahoo.com>

Praedor Atrebates wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Friday 26 March 2004 04:46 pm, George Anzinger held forth thus:
> 
>>Praedor Atrebates wrote:
>>
>>>In doing a web search on system clock speeds being too high, I found
>>>entries describing exactly what I am experiencing in the linux-kernel
>>>list archives, but have not yet found a resolution.
>>>
>>>I have Mandrake 10.0, kernel-2.6.3-7mdk installed, on an IBM Thinkpad
>>>1412 laptop, celeron 366, 512MB RAM.  I am finding that my system clock
>>>is ticking away at a rate of about 3:1 vs reality, ie, I count ~3 seconds
>>>on the system clock for every 1 real second.  I am running ntpd but this
>>>is unable to keep up with the rate of system clock passage.
> 
> [...]
> 
>>Try this in the boot command line "clock=pmtmr".  If that fails, then try
>>"clock=pit".
> 
> 
> What is the difference between the two settings?  I used the latter and it 
> worked (didn't try "clock=pmtmr").
> 
There are three clock sources in the x86 kernel, the PIT (programmable interrupt 
timer), the TSC, and the pmtimer (power management timer).

The PIT has been in the hardware since, well, day one.  It almost always works 
and it is clocked by a special Xtal.  The down side is it is accessed with 8-bit 
I/O instructions and so is dog slow to change or look at.

The TSC (time stamp counter) is a newer thing so is not available on all 
hardware although, now, most boxes that don't have TSCs are in land fills :). 
It is accessed via a machine register.  It is usually the cpu clock and so is a 
direct indicator of the cpu speed.  The boot report of cpu speed comes from a 
comparison of the TSC and the PIT, and, in fact this comparison is used to 
calibrate the TSC so it can be used to interpolate between PIT interrupts.  So, 
even here, the PIT is still the tick generator, while the TSC is used to replace 
the reading of the PIT to interpolate between interrupts.  The down side is that 
prior to the pentium 4, the TSC frequency was exactly the processor clock and 
was subject to change to control heat and power usage in the cpu.  I.e. the TSC 
was slowed down to cool the cpu (and to save power).  This makes it an 
unreliable time source for those cpus that do this, in particular lap tops that 
are very much into saving power.

The pmtimer is part of the ACPI hardware.  It is clocked by the same xtal as the 
PIT.  It does not interrupt, so again, the PIT is the interrupt source for time 
ticks.  It has a resolution of three times the PIT (same clock, different 
divider).  It is called the power management timer as it is was designed to 
provide a stable time reference for all power states (except off, of course), so 
is not subject to the slow downs the TSC is.  The down side is that it is 
accessed with an I/O instruction and so is slow.  I have measured a 3 times 
difference in gettimeofday() on an 800MHZ PIII between the TSC and the pmtimer, 
for example.  (And this was with just one read of the pmtimer per 
gettimeofday(), were as the kernel now does three because some hardware gets it 
wrong.)

So, you may ask, if the PIT is the interrupt source, why does the pmtimer being 
off cause my clock to run fast?  It would seem that only the interpolation 
between ticks would be fast, not the whole clock.  The answer to this is the 
"lost tick" detection code.  This code uses the pmtimer or the TSC to check for 
lost ticks and adjusts the clock based on this.

Questions?
-- 
George Anzinger   george@mvista.com
High-res-timers:  http://sourceforge.net/projects/high-res-timers/
Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml


  reply	other threads:[~2004-03-27 16:09 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-26 19:30 System clock speed too high - 2.6.3 kernel Praedor Atrebates
2004-03-26 21:22 ` john stultz
2004-03-26 21:54   ` Praedor Atrebates
2004-03-26 23:09     ` john stultz
     [not found]   ` <200403261800.32717.praedor@yahoo.com>
2004-03-26 21:57     ` john stultz
2004-03-26 22:05       ` Praedor Atrebates
2004-03-26 22:18       ` Praedor Atrebates
2004-03-30 15:25     ` john stultz
2004-04-06 21:46       ` Dominik Brodowski
2004-03-26 21:46 ` George Anzinger
2004-03-26 21:57   ` Praedor Atrebates
2004-03-27 16:09     ` George Anzinger [this message]
     [not found] <1E4zj-77w-69@gated-at.bofh.it>
2004-05-25  9:22 ` Joris van Rantwijk
2004-05-25 20:53   ` john stultz
2004-05-25 20:58   ` john stultz
2004-05-26 22:43     ` Joris van Rantwijk
2004-05-26 23:08       ` john stultz
2004-05-27 13:32       ` Bill Davidsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4065A726.50506@mvista.com \
    --to=george@mvista.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=praedor@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).