Re: athlon 64 dual core tsc out of sync

[Albert Cahalan <acahalan@gmail.com>]

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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/