Prev: ANN: Seed7 Release 2010-03-07
Next: pthread_mutex/ptheread_spinlocks & shared memory
From: Chris Friesen on 10 Mar 2010 22:57
On 03/10/2010 01:10 PM, William Ahern wrote:
> Chris Friesen <cbf123(a)mail.usask.ca> wrote:

>> It's now possible to determine whether rdtsc is reliable...on linux an
>> easy way is to look at /proc/cpuinfo. Ideally you want to see
>> "constant_tsc" and "nonstop_tsc".
>
> On Linux/x86_64, at least, the kernel already uses HPET+rtdsc tricks, and it
> uses some special hacks for gettimeofday and similar so that a regular
> system call isn't necessary.

Yeah...but if you're trying to get the latency down as much as possible
you want to avoid the cost of the function call and also all the math
required to convert from clock ticks to microseconds/seconds. In that
scenario, a raw call to rdtsc/rdtscp is about as efficient as it gets.

Chris
From: William Ahern on 11 Mar 2010 11:59
Chris Friesen <cbf123(a)mail.usask.ca> wrote:
> On 03/10/2010 01:10 PM, William Ahern wrote:
> > Chris Friesen <cbf123(a)mail.usask.ca> wrote:

> >> It's now possible to determine whether rdtsc is reliable...on linux an
> >> easy way is to look at /proc/cpuinfo. Ideally you want to see
> >> "constant_tsc" and "nonstop_tsc".
> >
> > On Linux/x86_64, at least, the kernel already uses HPET+rtdsc tricks, and it
> > uses some special hacks for gettimeofday and similar so that a regular
> > system call isn't necessary.

> Yeah...but if you're trying to get the latency down as much as possible
> you want to avoid the cost of the function call and also all the math
> required to convert from clock ticks to microseconds/seconds. In that
> scenario, a raw call to rdtsc/rdtscp is about as efficient as it gets.

How common are x86 systems with both a constant _and_ synchronized TSC?
If you lack either than rdtsc is simply unreliable.
From: Scott Lurndal on 11 Mar 2010 12:52
William Ahern <william(a)wilbur.25thandClement.com> writes:
>Chris Friesen <cbf123(a)mail.usask.ca> wrote:
>> On 03/10/2010 01:10 PM, William Ahern wrote:
>> > Chris Friesen <cbf123(a)mail.usask.ca> wrote:
>
>> >> It's now possible to determine whether rdtsc is reliable...on linux an
>> >> easy way is to look at /proc/cpuinfo. Ideally you want to see
>> >> "constant_tsc" and "nonstop_tsc".
>> >
>> > On Linux/x86_64, at least, the kernel already uses HPET+rtdsc tricks, and it
>> > uses some special hacks for gettimeofday and similar so that a regular
>> > system call isn't necessary.
>
>> Yeah...but if you're trying to get the latency down as much as possible
>> you want to avoid the cost of the function call and also all the math
>> required to convert from clock ticks to microseconds/seconds. In that
>> scenario, a raw call to rdtsc/rdtscp is about as efficient as it gets.
>
>How common are x86 systems with both a constant _and_ synchronized TSC?
>If you lack either than rdtsc is simply unreliable.

Everthing current gen and everthing going forward will have a constant TSC.

Synchronized across cores may not be possible on all architectures (e.g. ccNUMA)
once a certain size is reached. That said, I'm using a 112 core ccNUMA system
with invariant and synchronized TSC's. It gets more complicated when
not all the processors are the same speed processors, however, which this
system supports (even a mix of istanbul and shanghais).

scott
First  |  Prev  | 
Pages: 1 2 3 4 5 6
Prev: ANN: Seed7 Release 2010-03-07
Next: pthread_mutex/ptheread_spinlocks & shared memory