|
|
|
|
|
|
| Author |
Message |
Robert Redelmeier
*nix forums Guru Wannabe
Joined: 28 Feb 2005
Posts: 200
|
 Posted: Wed Jun 21, 2006 1:49 pm Post subject:
Re: x86 High Precision Event Timers support
|
|
|
In comp.os.linux.development.system Spoon <root@127.0.0.1> wrote in part:
| Quote: | 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:
|
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 |
|
| Back to top |
|
 |
Paul Keinanen
*nix forums beginner
Joined: 27 May 2005
Posts: 21
|
| Posted: Wed Jun 21, 2006 8:42 pm Post subject:
Re: x86 High Precision Event Timers support
|
|
|
On Wed, 21 Jun 2006 13:49:29 GMT, Robert Redelmeier
<redelm@ev1.net.invalid> wrote:
| Quote: | In comp.os.linux.development.system Spoon <root@127.0.0.1> wrote in part:
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:
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.
|
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.
| Quote: | Accuracy still depends on the clock generator. iAFAIK,
nanosleep(), gettimeofday() and friends use RDTSC to
interpolate other clocks (APIC prefered over the PIT).
|
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 |
|
| Back to top |
|
|
Niels Jørgen Kruse
*nix forums beginner
Joined: 13 Jun 2005
Posts: 5
|
| Posted: Thu Jun 22, 2006 7:46 am Post subject:
Re: x86 High Precision Event Timers support
|
|
|
Paul Keinanen <keinanen@sci.fi> wrote:
| Quote: | 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.
|
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 |
|
| Back to top |
|
|
Mike T.
*nix forums Guru Wannabe
Joined: 20 Feb 2005
Posts: 245
|
| Posted: Thu Jun 22, 2006 7:58 am Post subject:
Re: x86 High Precision Event Timers support
|
|
|
Robert Redelmeier wrote:
| Quote: | Spoon wrote:
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:
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.
|
Which reminds me of Rich Brunner's excellent article:
http://groups.google.com/group/fa.linux.kernel/msg/c8ae85a08ebd3aa4
| Quote: | Accuracy still depends on the clock generator. iAFAIK,
nanosleep(), gettimeofday() and friends use RDTSC to
interpolate other clocks (APIC prefered over the PIT).
|
I'm playing with the hrtimers infrastructure:
http://www.tglx.de/hrtimers.html
I *think* they use HPET, if they find it.
http://www.tglx.de/projects/hrtimers/2.6.16/patch-2.6.16-hrt6.patch
I'm also wondering: Are there x86-based systems where a card equipped
with several PITs (e.g. ADLINK's PCI-8554) is a necessity?
http://www.adlinktech.com/PD/web/PD_detail.php?pid=27 |
|
| Back to top |
|
|
Joe Seigh
*nix forums addict
Joined: 09 Apr 2005
Posts: 52
|
| Posted: Thu Jun 22, 2006 11:24 am Post subject:
Re: x86 High Precision Event Timers support
|
|
|
Niels Jørgen Kruse wrote:
| Quote: | Paul Keinanen <keinanen@sci.fi> wrote:
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.
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.
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.
When you get hardware, you make software. |
|
| Back to top |
|
|
David Hopwood
*nix forums addict
Joined: 03 Sep 2005
Posts: 75
|
| Posted: Thu Jun 22, 2006 6:33 pm Post subject:
Re: x86 High Precision Event Timers support
|
|
|
Niels Jørgen Kruse wrote:
| Quote: | Paul Keinanen <keinanen@sci.fi> wrote:
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.
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.
|
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.
--
David Hopwood <david.nospam.hopwood@blueyonder.co.uk> |
|
| Back to top |
|
|
Robert Redelmeier
*nix forums Guru Wannabe
Joined: 28 Feb 2005
Posts: 200
|
| Posted: Thu Jun 22, 2006 6:45 pm Post subject:
Re: x86 High Precision Event Timers support
|
|
|
In comp.os.linux.development.system David Hopwood <david.nospam.hopwood@blueyonder.co.uk> wrote in part:
| Quote: | 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.
|
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 |
|
| Back to top |
|
|
Casper H.S. Dik
*nix forums Guru
Joined: 20 Feb 2005
Posts: 1634
|
| Posted: Thu Jun 22, 2006 8:02 pm Post subject:
Re: x86 High Precision Event Timers support
|
|
|
David Hopwood <david.nospam.hopwood@blueyonder.co.uk> writes:
| Quote: | 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.
|
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 |
|
| Back to top |
|
|
Niels Jørgen Kruse
*nix forums beginner
Joined: 13 Jun 2005
Posts: 5
|
| Posted: Thu Jun 22, 2006 10:03 pm Post subject:
Re: x86 High Precision Event Timers support
|
|
|
David Hopwood <david.nospam.hopwood@blueyonder.co.uk> wrote:
| Quote: | Niels Jørgen Kruse wrote:
Paul Keinanen <keinanen@sci.fi> wrote:
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.
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.
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.
|
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 |
|
| Back to top |
|
|
Terje Mathisen
*nix forums beginner
Joined: 06 May 2005
Posts: 7
|
| Posted: Fri Jun 23, 2006 7:54 am Post subject:
Re: x86 High Precision Event Timers support
|
|
|
Niels Jørgen Kruse wrote:
| Quote: | David Hopwood <david.nospam.hopwood@blueyonder.co.uk> wrote:
Niels Jørgen Kruse wrote:
Paul Keinanen <keinanen@sci.fi> wrote:
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.
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.
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.
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.
|
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
--
- <Terje.Mathisen@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching" |
|
| Back to top |
|
|
Casper H.S. Dik
*nix forums Guru
Joined: 20 Feb 2005
Posts: 1634
|
| Posted: Fri Jun 23, 2006 9:39 am Post subject:
Re: x86 High Precision Event Timers support
|
|
|
Terje Mathisen <terje.mathisen@hda.hydro.com> writes:
| Quote: | 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.
|
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)
| Quote: | 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.
|
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.
| Quote: | 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. 
|
Ugh.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth. |
|
| Back to top |
|
|
Joe Seigh
*nix forums addict
Joined: 09 Apr 2005
Posts: 52
|
| Posted: Fri Jun 23, 2006 10:38 am Post subject:
Re: x86 High Precision Event Timers support
|
|
|
Terje Mathisen wrote:
| Quote: |
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.
|
Which one of the problems is that?
--
Joe Seigh
When you get lemons, you make lemonade.
When you get hardware, you make software. |
|
| Back to top |
|
|
Niels Jørgen Kruse
*nix forums beginner
Joined: 13 Jun 2005
Posts: 5
|
| Posted: Fri Jun 23, 2006 12:06 pm Post subject:
Re: x86 High Precision Event Timers support
|
|
|
Terje Mathisen <terje.mathisen@hda.hydro.com> wrote:
| Quote: | 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.
|
On a Core Duo, the OS X call "mach_absolute_time()" takes ~132 clocks.
With 3 RDTSCs and the triple-width scaling, I suppose that about fits.
If the implementation is the general one, that doesn't rely on a fixed
frequency, it could explain why the result is scaled to nanosecond
resolution. (A companion call to mach_absolute_time provides a fraction
for scaling, so if you want nanosecond resolution, you will be doing a
superfluous scaling.) If a fixed frequency was assumed, the raw
resolution could have been used in the result, saving a scaling
operation.
| Quote: | 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.
|
If Intel could have spared an extra pin, they could have added a proper
timebase register incrementing asyncronously on an external timebase
signal. At a modest frequency like 33MHz, there should be no problem
distributing a timebase signal to multiple CPUs.
--
Mvh./Regards, Niels Jørgen Kruse, Vanløse, Denmark |
|
| Back to top |
|
|
Casper H.S. Dik
*nix forums Guru
Joined: 20 Feb 2005
Posts: 1634
|
| Posted: Fri Jun 23, 2006 12:43 pm Post subject:
Re: x86 High Precision Event Timers support
|
|
|
nospam@ab-katrinedal.dk (=?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?=) writes:
| Quote: | If Intel could have spared an extra pin, they could have added a proper
timebase register incrementing asyncronously on an external timebase
signal. At a modest frequency like 33MHz, there should be no problem
distributing a timebase signal to multiple CPUs.
|
We found that the 10MHz used for this purpose on some SPARC processors
is actually not fast enough; that's perhaps several hundred clock ticks which
makes using this for precise accounting difficult.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth. |
|
| Back to top |
|
|
Bernd Paysan
*nix forums beginner
Joined: 12 Jun 2005
Posts: 4
|
| Posted: Fri Jun 23, 2006 1:24 pm Post subject:
Re: x86 High Precision Event Timers support
|
|
|
Casper H.S. Dik wrote:
| Quote: | nospam@ab-katrinedal.dk (=?ISO-8859-1?Q?Niels_J=F8rgen_Kruse?=) writes:
If Intel could have spared an extra pin, they could have added a proper
timebase register incrementing asyncronously on an external timebase
signal. At a modest frequency like 33MHz, there should be no problem
distributing a timebase signal to multiple CPUs.
We found that the 10MHz used for this purpose on some SPARC processors
is actually not fast enough; that's perhaps several hundred clock ticks
which makes using this for precise accounting difficult.
|
The frontside bus clock should be sufficiently synchronous and identical on
all CPUs used within one box - at least now. Xeons have a "real" frontside
bus, and Opterons have a common hypertransport clock base (200MHz). This
frequency scales with processor performance, so it should not be off so
far. That's 10-15 cycles resolution on current CPUs, less than the rdtsc
instruction takes.
BTW clock skew: Note that for all practical purposes, the only requirement
for a distributed timer is that no signal distributes faster than the
timer.
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/ |
|
| Back to top |
|
|
Google
|
|
| Back to top |
|
|
|
|
The time now is Fri Jan 09, 2009 9:14 pm | All times are GMT
|
|
Debt Consolidation | Credit Cards | Guitar Lessons | Mobile Phone | Bankruptcy
|
|
Copyright © 2004-2005 DeniX Solutions SRL
|
|
|
|
Other DeniX Solutions sites:
Unix/Linux blog |
electronics forum |
medicine forum |
science forum |
|
|
Privacy Policy
|
Powered by phpBB © 2001, 2005 phpBB Group
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
Forum index
»
*nix
»
Linux
»
development
»
system
