[lkml]   [2000]   [Nov]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: rdtsc to mili secs?
On Wed, Nov 15, 2000 at 01:05:27PM -0800, H. Peter Anvin wrote:

> > > Intel PIIX-based systems will do duty-cycle throttling, for example.
> >
> > Don't think so. My toshiba is PIIX-based, AFAIC:
> Interesting. Some will, definitely. Didn't know that wasn't universal.
> Clearly, on a machine like that, there is no hope for RDTSC, at least
> unless the CPU (and OS!) gets notification that the TSC needs to be
> recalibrated whenever it switches.
> > Still, it is willing to run with RDTSC at 300MHz, 150MHz, and
> > 40MHz. (The last one in _extreme_ cases when CPU fan fails -- running
> > at 40MHz is better than cooking cpu).

I believe that pulsing the STPCLK pin of the processor by connecting it
to a say 32kHz signal and then changing the duty cycle of that signal
could have the effect of slowing down the processor to these speeds.

Somehow I can't believe a PMMX would be able to run at 40MHz. Which in
turn means that STPCLK also stops TSC, which is equally bad.

Anyway, this should be solvable by checking for clock change in the
timer interrupt. This way we should be able to detect when the clock
went weird with a 10 ms accuracy. And compensate for that. It should be
possible to keep a 'reasonable' clock running even through the clock
changes, where reasonable means constantly growing and as close to real
time as 10 ms difference max.

Yes, this is not perfect, but still keep every program quite happy and

Vojtech Pavlik
SuSE Labs
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:45    [W:0.058 / U:5.340 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site