From: Pavel Machek <pavel@suse.cz>
To: Vojtech Pavlik <vojtech@suse.cz>, "H. Peter Anvin" <hpa@transmeta.com>
Cc: "H. Peter Anvin" <hpa@zytor.com>, linux-kernel@vger.kernel.org
Subject: Re: rdtsc to mili secs?
Date: Sat, 18 Nov 2000 21:12:31 +0100 [thread overview]
Message-ID: <20001118211231.A382@bug.ucw.cz> (raw)
In-Reply-To: <3A078C65.B3C146EC@mira.net> <E13t7ht-0007Kv-00@the-village.bc.nu> <20001110154254.A33@bug.ucw.cz> <8uhps8$1tm$1@cesium.transmeta.com> <20001114222240.A1537@bug.ucw.cz> <3A12FA97.ACFF1577@transmeta.com> <20001116115730.A665@suse.cz>
In-Reply-To: <20001116115730.A665@suse.cz>; from Vojtech Pavlik on Thu, Nov 16, 2000 at 11:57:30AM +0100
Hi!
> > > > 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.
Why not? From 300MHz to 40MHz... 10 times, that is not that big
difference. (I've ran k6/400 at 66MHz, IIRC, while debugging -- I'm
not really sure, and don't want to open machine, but it should work).
> 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
> running.
No. Udelay has just gone wrong and your old ISA xxx card just crashed
whole system. Oops.
BTW I mailed patch to do exactly that kind of autodetection to the
list some time ago. (I just can't find it now :-( -- search archives
for 'TSC is slower than it should be'.
Pavel
--
I'm pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2000-11-18 22:31 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-05 23:09 rdtsc to mili secs? Sushil Agarwal
2000-11-06 0:10 ` Andrea Arcangeli
2000-11-06 0:28 ` Alan Cox
2000-11-06 0:34 ` Andrea Arcangeli
2000-11-06 0:46 ` Alan Cox
2000-11-06 17:17 ` Anton Blanchard
2000-11-06 17:27 ` Alan Cox
2000-11-07 5:00 ` Antony Suter
2000-11-07 6:10 ` H. Peter Anvin
2000-11-07 12:18 ` Alan Cox
2000-11-10 14:42 ` Pavel Machek
2000-11-10 21:38 ` H. Peter Anvin
2000-11-10 22:23 ` Rogier Wolff
2000-11-10 23:00 ` H. Peter Anvin
2000-11-14 21:22 ` Pavel Machek
2000-11-15 21:05 ` H. Peter Anvin
2000-11-16 10:57 ` Vojtech Pavlik
2000-11-16 23:09 ` H. Peter Anvin
2000-11-18 20:13 ` Pavel Machek
2000-11-18 23:48 ` H. Peter Anvin
2000-11-19 9:21 ` Vojtech Pavlik
2000-11-18 20:12 ` Pavel Machek [this message]
2000-11-18 22:13 ` Vojtech Pavlik
2000-11-19 20:24 ` Pavel Machek
2000-11-19 21:46 ` Vojtech Pavlik
-- strict thread matches above, loose matches on Subject: below --
2000-11-06 8:15 ming_l
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=20001118211231.A382@bug.ucw.cz \
--to=pavel@suse.cz \
--cc=hpa@transmeta.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=vojtech@suse.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.