Messages in this thread | | | Date | Sat, 4 Feb 2006 20:45:42 -0500 | From | Albert Cahalan <> | Subject | Re: athlon 64 dual core tsc out of sync |
| |
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/
| |