x86 High Precision Event Timers support

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Hello,

As far as I understand (which is not very far, please do single out all
inaccuracies) there is an effort in the x86 world to replace the legacy
x86 timer infrastructure:

o The PIT (Programmable Interval Timer) such as Intel's 8253 and 8254
http://en.wikipedia.org/wiki/Intel_8253
http://www.intel.com/design/archives/periphrl/docs/7178.htm

o The RTC (Real-Time Clock)

o The (Local??) APIC timer
(I didn't find much information on this timer.)

o The ACPI timer, also known as the PM clock
(Any pointers?)

Microsoft provides a rationale for the new infrastructure:
http://www.microsoft.com/whdc/system/CEC/mm-timer.mspx

Intel provides a spec:
http://www.intel.com/hardwaredesign/hpetspec.htm


As far as I understand, the HPET hardware is provided by the southbridge
chipset? For example, Intel's ICH5.

(Would the VIA VT82C686B provide an HPET block?)

My understanding is that the BIOS is supposed to map the HPET addresses
in memory, and provide the information through an ACPI table at
boot-time? If the BIOS does not initialize the HPET hardware, the OS
remains unaware that it is available.

http://www.ussg.iu.edu/hypermail/linux/kernel/0506.1/index.html#0222

Is there, somewhere, a list of hardware with HPET support?

Are there implementations that support more than 3 comparators?

Regards.

Re: x86 High Precision Event Timers support
Quoted text here. Click to load it

You forgot the venerable and still extremely precise RDTSC
instruction available since the original Pentium to read the
CPU's cycle counter.  Typical overhead, 30 clocks vs interrupt
latency of at least 100 clocks.

Accuracy still depends on the clock generator.  iAFAIK,
nanosleep(), gettimeofday() and friends use RDTSC to
interpolate other clocks (APIC prefered over the PIT).

-- Robert


Re: x86 High Precision Event Timers support
On Wed, 21 Jun 2006 13:49:29 GMT, Robert Redelmeier

Quoted text here. Click to load it

RDTSC is nice as long as you stay away from Geode processors, which
seems to enter the SMM in more or less unpredictable ways. Also any
processor doing some dynamic clock frequency changes in various power
saving modes will cause problems.

Quoted text here. Click to load it

The CPU clock frequency is quite temperature dependent. Unless you can
check the time at least once a day from some reliable source, such as
the CMOS clock, NTP or some GPS clock, quite significant cumulative
errors will occur.

Paul


Re: x86 High Precision Event Timers support

Quoted text here. Click to load it

Recent Intel CPUs run the RDTSC cyclecounter at a fixed frequency,
regardless of temporary reductions in core frequency. Eventually, I
suppose AMD will do the right thing too.

--
Mvh./Regards,    Niels Jørgen Kruse,    Vanløse, Denmark

Re: x86 High Precision Event Timers support
Quoted text here. Click to load it
It would be nice if they get around to supporting a high resolution
timing interface that doesn't require a syscall, works in an SMP
environment, and supports virtual timing as well as real wall clock
timing.  It's a known technique and has been around for decades.

Also Intel and AMD need to think about how these things virtualize before
they put these kind of things in rather than five years after the fact.
But that's only important if Intel and AMD think virtualization is an
important part of their business strategy.

--
Joe Seigh

When you get lemons, you make lemonade.
We've slightly trimmed the long signature. Click to see the full one.
Re: x86 High Precision Event Timers support
Quoted text here. Click to load it

But since an OS or library that provides timing services cannot rely on
running on a processor where the RDTSC frequency is fixed, this won't
simplify any such OSes or libraries, until at some point it becomes
practical to ignore older processors.

--20%

Re: x86 High Precision Event Timers support
In comp.os.linux.development.system David Hopwood
Quoted text here. Click to load it

This depends very much on the software quality requirements.
Not everything is a big system that will be used for critical
purposes.  Everything is a compomise -- RDTSC is very fast
and usually good.  OS calls are almost always accurate,
but slower and usually less precise.

Horses for courses.

-- Robert


Re: x86 High Precision Event Timers support
Quoted text here. Click to load it

Yes, a lot of software is of very poor quality ;-)

--

Re: x86 High Precision Event Timers support
In comp.os.linux.development.system David Hopwood
Quoted text here. Click to load it

Agreed.  Sometimes due to a misguided effort at high quality!

-- Robert

Quoted text here. Click to load it

Re: x86 High Precision Event Timers support

Quoted text here. Click to load it

Unless the OS makes good.  If the OS fixes these things up in the other
cases (hard, I've tried it), then not having to do this on some system is a
bonus.

Casper

Re: x86 High Precision Event Timers support

Quoted text here. Click to load it

Currently, MacOS X can assume that. Granted, Marklar was started before
there were fixed frequency RDTSC processors, so there may be some
workaround still in there.

--
Mvh./Regards,    Niels Jørgen Kruse,    Vanløse, Denmark

Re: x86 High Precision Event Timers support
Quoted text here. Click to load it

There are two main problems here:

a) The TSC might not run at a fixed frequency, but an OS can know when
the changes happen, and still use it to provide a fast return value: It
needs a userlevel library routine which just has to take the current TSC
count, multiply by the current scale factor (producing a triple-width
result), shift down by the current shift value, and add the current base
count. Total time for this operation is not much higher than the RDTSC
opcode which can easily take 20-30 cycles by itself on some cpus.

Intuitively, you would like to either reset the TSC count or store the
current value and subtract it out before the multiplication, but the
subtraction can instead be included in the base value to be added in
after the scaling multiplication.

The OS must of course update the base value and the scale factor each
time the TSC frequency changes, but as long as there's only a small
number (two?) of base frequencies to support, the needed scale factors
can be calculated up front, and you might even get away with just a
shift if the slow frequency is a binary fraction of the high.

b) On a multi-cpu/multi-core system, it is quite possible for the TSC
counts to get out of sync, and this is a much harder problem to fix
while still delivering sub-us precision and latency.

Windows punts by using the best available external counter, which might
fall back all the way to the horrible 1.1 MHz keyboard chip/RAM refresh
counter designed into the original 1981 model PC. :-(

Terje
--
"almost all programming can be viewed as an exercise in caching"

Re: x86 High Precision Event Timers support

Quoted text here. Click to load it

The number of frequencies can be higher, actually; an typical AMD CPU
can only do smallish frequency steps, and that makes for quite a few
frequencies (four-five on typical systems around here)

Quoted text here. Click to load it

yeah, I didn't do multi-cpu/multi-core; the Opteron multi-core CPUs will
all need to run at the same frequency (though I'm not sure if setting
the core voltage/frequency of one half of the core affects the other
half at the same time or that these actions need to be done in
lockstep); multi-socket adds additional challenges.

Quoted text here. Click to load it

Ugh.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
We've slightly trimmed the long signature. Click to see the full one.
Re: x86 High Precision Event Timers support
Quoted text here. Click to load it

On the Dual-Opteron 270 system we have, the two cores in the same
socket always have the same voltage and the same frequency, but the
other two in the other socket can be at a different speed.

We have seen some instability on that system, maybe related to
speed-changing (the system sometimes crashed when the load (and thus
the speed) changed, and this went away when we used a kernel that does
not change speeds).

Followups set to comp.arch.

- anton
--
M. Anton Ertl                    Some things have to be seen to be believed
snipped-for-privacy@mips.complang.tuwien.ac.at Most things have to be believed to be seen
We've slightly trimmed the long signature. Click to see the full one.
Re: x86 High Precision Event Timers support
Quoted text here. Click to load it

As I understand it this is true of Opteron but NOT AMD Athlon64 X2, as
I understand it the X2 allows the cores can be controlled individually
(presumably this is to get down power usage on desktops).

At least that's the explaination I've heard for why you can see some
really funky effects in Windows with X2's (but not Opterons!) unless
you install a new enough "AMD Athlon 64 X2 Dual Core Processor Driver"
(available from AMD but not Windows Update for some reason).

Linux also had problem with X2's and CnQ for a while, probably because
a lot of this was tested on Opteron... IIRC people produced test
programs which showed that this effect was real before the patch was
accepted.

There's some rumors that a future X2 revision is going to run with the
same TSC for all cores in a physical package/socket (they should have
plenty of stable clocks to run it off, perhaps the HT clock).

Re: x86 High Precision Event Timers support
Quoted text here. Click to load it

My understanding is that the Athlon64 X2s still run the two cores at
the same frequency. It's the laptop parts which can run the cores at
different frequencies.

Phil

--
http://www.kantaka.co.uk/ .oOo. public key: http://www.kantaka.co.uk/gpg.txt

Re: x86 High Precision Event Timers support

Quoted text here. Click to load it

My understanding is that the Athlon64 X2 and the Opteron parts are
basically the same.

(The latest socket 939 Opteron and the Athlon64 X2 cannot be told apart by
software; they return the same CPUID values.

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
We've slightly trimmed the long signature. Click to see the full one.
Re: x86 High Precision Event Timers support
Quoted text here. Click to load it

Which one of the problems is that?

--
Joe Seigh

When you get lemons, you make lemonade.
We've slightly trimmed the long signature. Click to see the full one.
Re: x86 High Precision Event Timers support
Quoted text here. Click to load it

Second, as in (b), was my intention. Sorry if I was unclear!
Quoted text here. Click to load it

Terje
--
"almost all programming can be viewed as an exercise in caching"

Re: x86 High Precision Event Timers support
Quoted text here. Click to load it

Well, I assume you're using something like NTP to keep them "in sync".
You can't actually keep them in absolute sync, just within a certain
accuracy with a given precision or certainty.  You cannot use separate
clocks for synchronization like you can with a single clock unless you
accept that synchronizing with multiple clocks will occasionally fail
and allow erroneous results.

Is the "problem" you can't use multiple clocks to synchronize with or
is it something else?


--
Joe Seigh

When you get lemons, you make lemonade.
We've slightly trimmed the long signature. Click to see the full one.

Site Timeline