[9fans] high precision timings

[9fans] high precision timings

[Steve Simon]

after the recent discussions on nsec()...

does anyone already have the snippet of code to do fine grained
timeings on the x86 platform using the hardware performance counters?

I would use nsec() but I'am timing systemcalls so I expect my results
would be swamped by nsec()'s performance.

Thanks

-Steve

Re: [9fans] high precision timings

[erik quanstrom]

On Sun Sep  4 13:48:31 EDT 2011, steve@quintile.net wrote:
> after the recent discussions on nsec()...
> 
> does anyone already have the snippet of code to do fine grained
> timeings on the x86 platform using the hardware performance counters?
> 
> I would use nsec() but I'am timing systemcalls so I expect my results
> would be swamped by nsec()'s performance.

i wrote up a little demo using a varient of nsec and
using the x86 cycle counter, RDTSC.
the source is in /n/sources/contrib/quanstro/highprec.

i'd recommend doing timings on your particular hardware.
here are my results:

; aux/cpuid -i
AMD Phenom(tm) II X4 965 Processor
; 8.out
nsec latency 25729ns
nsec latency 24554ns
cycle hz = 3393000000
cycles latency 88 cycles; 25 ns
cycles latency 78 cycles; 22 ns

ladd; aux/cpuid -i
         Intel(R) Atom(TM) CPU  330   @ 1.60GHz
ladd; 8.out
nsec latency 39501ns
nsec latency 38901ns
cycle hz = 1604000000
cycles latency 60 cycles; 37 ns
cycles latency 48 cycles; 29 ns

new; aux/cpuid -i
          Intel(R) Xeon(R) CPU E31220 @ 3.10GHz
new; 8.out
nsec latency 8591ns
nsec latency 9155ns
cycle hz = 3105000000
cycles latency 28 cycles; 9 ns
cycles latency 28 cycles; 9 ns

chula; aux/cpuid -i
Intel(R) Core(TM) i7 CPU         920  @ 2.67GHz
chula; 8.out
nsec latency 14319ns
nsec latency 14451ns
cycle hz = 2660000000
cycles latency 40 cycles; 15 ns
cycles latency 32 cycles; 12 ns

it seems like you can get ±10ns at a few 10s of
ns latency with _cycles and ±10µs at a few 10s
of µs latency with /dev/bintime.

- erik

Re: [9fans] high precision timings

[ron minnich]

The TSC has been badly abused by the chip makers over the last ten
years. It went through a period of time where it had poor accuracy. Be
sure to look at your hardware and make sure it's a later chip which
will give you reasonable TSC behavior.

ron

Re: [9fans] high precision timings

[erik quanstrom]

On Mon Sep  5 00:43:49 EDT 2011, rminnich@gmail.com wrote:
> The TSC has been badly abused by the chip makers over the last ten
> years. It went through a period of time where it had poor accuracy. Be
> sure to look at your hardware and make sure it's a later chip which
> will give you reasonable TSC behavior.

my example code wires the proc to a mach to avoid extreme TSC problems
such as on some ht p4 machines.

perhaps that's a bit extreme.  it's been a long time since i've used a machine
with a broken cycle counter.  (last purchase: 2006.)

- erik

Re: [9fans] high precision timings

[s s]

[-- Attachment #1: Type: text/plain, Size: 650 bytes --]

On Mon, Sep 5, 2011 at 12:42 AM, ron minnich <rminnich@gmail.com> wrote:

> The TSC has been badly abused by the chip makers over the last ten
> years. It went through a period of time where it had poor accuracy. Be
> sure to look at your hardware and make sure it's a later chip which
> will give you reasonable TSC behavior.
>
> ron
>

Not concerned just yet about the accuracy of the hardware.

Just wondering why the example client outputs "invalid arguments", and the
server outputs ...

2011/09/05 00:37:14 bad client connection:  [::1]:57429

Still happy to see something compile, run, and give output, though.

 - Leonard

[-- Attachment #2: Type: text/html, Size: 995 bytes --]

Re: [9fans] high precision timings

[s s]

[-- Attachment #1: Type: text/plain, Size: 39 bytes --]

Sorry, wrong thread.

 - Leonard
>

[-- Attachment #2: Type: text/html, Size: 271 bytes --]

Re: [9fans] high precision timings

[dexen deVries]

On Monday 05 of September 2011 06:42:35 ron minnich wrote:
> The TSC has been badly abused by the chip makers over the last ten
> years. It went through a period of time where it had poor accuracy. Be
> sure to look at your hardware and make sure it's a later chip which
> will give you reasonable TSC behavior.

FWIW, Pentium M had `broken' TSC behavior. during boot, linux complains, ``TSC 
halts in idle'' and refuses to use it as clock source. apparently TSC counts 
actual CPU clock impulses, and those are slowed down in idle.
-- 
dexen deVries

[[[↓][→]]]

For example, if the first thing in the file is:
   <?kzy irefvba="1.0" rapbqvat="ebg13"?>
an XML parser will recognize that the document is stored in the traditional 
ROT13 encoding.

(( Joe English, http://www.flightlab.com/~joe/sgml/faq-not.txt ))