From: Albert Cahalan <acahalan@gmail.com>
To: Lee Revell <rlrevell@joe-job.com>
Cc: linux-kernel@vger.kernel.org, s0348365@sms.ed.ac.uk,
safemode@comcast.net
Subject: Re: athlon 64 dual core tsc out of sync
Date: Sat, 4 Feb 2006 20:45:42 -0500 [thread overview]
Message-ID: <787b0d920602041745k65504414taaaef7f6d75b364c@mail.gmail.com> (raw)
In-Reply-To: <1139101243.2791.78.camel@mindpipe>
On 2/4/06, Lee Revell <rlrevell@joe-job.com> wrote:
> On Sat, 2006-02-04 at 15:24 -0500, Albert Cahalan wrote:
> > There have been far too many other problems with i386 timekeeping as
> > well. Really, it's crazy to not use the pmtmr if the pmtmr is
> > available. The next best choice would be HPET. After that, pre-SMM
> > systems should count clock ticks and post-SMM systems should read the
> > RTC or PIT registers. Until we accept this, we'll always be suffering
> > clock problems.
>
> Well, I wouldn't say it's crazy - the TSC is several orders of magnitude
> cheaper than the PM timer, and the only common hardware where it's
> completely useless are Athlon X2 systems.
"the only"???
You clearly haven't been paying attention. Lots of computers vary the
clock rate. They do this several ways.
There may be sudden long-term changes, as when a laptop is unplugged.
The OS will not be told; there will just be timing errors.
Transitions may be gradual. The Opteron documentation describes a
procedure that involves stepping voltage and frequency, bit by bit,
waiting at each stage for the frequency to stabilize.
There is often a sawtooth wave wobble, added to spread the spectrum
of RF emmisions.
Clock ticks get lost all the time. The BIOS may decide do grab the
CPU in SMM (system management mode) for many milliseconds at a time.
It's cool to have a faster way to do things, but not if that way is
typically defective and enabled by default. The default should just
work, no "if"s "and"s or "but"s about it.
next prev parent reply other threads:[~2006-02-05 1:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-04 20:24 Albert Cahalan
2006-02-05 1:00 ` Lee Revell
2006-02-05 1:45 ` Albert Cahalan [this message]
2006-02-05 2:08 ` Lee Revell
2006-02-05 3:02 ` Ed Sweetman
2006-02-05 5:08 ` Alistair John Strachan
2006-02-05 2:24 ` Lee Revell
2006-02-05 5:06 ` Alistair John Strachan
-- strict thread matches above, loose matches on Subject: below --
2006-02-04 2:10 Ed Sweetman
2006-02-04 19:03 ` Lee Revell
2006-02-04 19:52 ` Alistair John Strachan
2006-02-04 21:55 ` Ed Sweetman
2006-02-04 19:16 ` Lee Revell
2006-02-05 16:32 ` Andi Kleen
2006-02-06 1:12 ` Ed Sweetman
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=787b0d920602041745k65504414taaaef7f6d75b364c@mail.gmail.com \
--to=acahalan@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rlrevell@joe-job.com \
--cc=s0348365@sms.ed.ac.uk \
--cc=safemode@comcast.net \
/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
all inboxes | Powered by JetHome®