Measuring short times

Measuring short times

[Antonio Eduardo Fermiano]

Yeah, I'm a programming newbie, so sorry if it's a stupid question.

I need to measure a time shorter than 1 milisecond (I need to measure
500 nanoseconds to be exact), but <time.h> seems to give me only the
option to have miliseconds. Can someone give me some tip of how to do
that?

By the way, I'm using a GCC port for Windows that came with Devcpp,
maybe it's an useful information.

Thank you very much for the help :)
o/

Re: Measuring short times

[Dennis Clarke]

> Yeah, I'm a programming newbie, so sorry if it's a stupid question.
>
> I need to measure a time shorter than 1 milisecond (I need to measure
> 500 nanoseconds to be exact), but <time.h> seems to give me only the
> option to have miliseconds. Can someone give me some tip of how to do
> that?
>
> By the way, I'm using a GCC port for Windows that came with Devcpp,
> maybe it's an useful information.
>
> Thank you very much for the help :)

http://www.blastwave.org/man/gethrtime_3C.html

you need Solaris for that to work.



Dennis

Re: Measuring short times

[Antonio Eduardo Fermiano]

Dennis, those Solaris functions were not useful for me because I got
no idea how to make it work on Windows.

I found this function in internet: (credits:
http://www.codeproject.com/datetime/NanoSecondTimer.asp?df=100&forumid=29560&exp=0&select=682802)

__inline__ uint64_t rdtsc() {
   uint32_t lo, hi;
   __asm__ __volatile__ ("rdtsc" : "=a" (lo), "=d" (hi));
   return (uint64_t)hi << 32 | lo;
}

It gives the 64-bit free counter value of the processor converted to
32-bit and it works wonderful (I could mark one second perfectly
comparing the right values)! The problem is: the frequency of the free
counter varies with the processor frequency, so if I design my program
to my 2.8ghz to wait 500ns, a guy with a 1.4ghz will have this wait
increased for 1ms (1000ns). So I have three choices, and I need some
help because I have no idea of how to go on:

1 ) A way to my program to detect processor's frequency, so it would
calculate the correct counter interval in the beginning and everything
would work fine and every processor would wait the time I want.

2 ) A ready library that would make it for me.

3 ) Another solution that I can't figure out o.o

Thank you very much for reading my message and for the help.
o/



On 11/24/07, Dennis Clarke <dclarke@blastwave.org> wrote:
>
> > Yeah, I'm a programming newbie, so sorry if it's a stupid question.
> >
> > I need to measure a time shorter than 1 milisecond (I need to measure
> > 500 nanoseconds to be exact), but <time.h> seems to give me only the
> > option to have miliseconds. Can someone give me some tip of how to do
> > that?
> >
> > By the way, I'm using a GCC port for Windows that came with Devcpp,
> > maybe it's an useful information.
> >
> > Thank you very much for the help :)
>
> http://www.blastwave.org/man/gethrtime_3C.html
>
> you need Solaris for that to work.
>
>
>
> Dennis
>
>

Re: Measuring short times

[Dennis Clarke]

> Dennis, those Solaris functions were not useful for me because I got
> no idea how to make it work on Windows.

How do you know that those functions are monotonic and consistent ?

Dennis Clarke

Re: Measuring short times

[Daniel Lohmann]

Dennis Clarke schrieb:
>> Dennis, those Solaris functions were not useful for me because I got
>> no idea how to make it work on Windows.
>>     
>
> How do you know that those functions are monotonic and consistent ?
>   
On IA-32 CPUs (Pentium or K5 and above) rdts returns the content of the 
64 bit CPU-internal clock counter, which is set to 0 at system start and 
incremented by one at every clock tick. This is guaranteed to be not 
only monotonic, but even strongly monotonic. Moreover, even on a 4.2 GHz 
system it would take 2^32 seconds (>130 years) until the counter 
overflows. For all practical purposes, this should be fine :-)

Only caveat is that it depends on the CPU clock speed. Not only that the 
basic clock speed is different on every system, it may even change over 
time due to power saving strategies. Nevertheless, for short time 
periods this is on Intel the best method to go.

Unfortunately, the rdts instruction is not a pipeline sequence point. 
This means that the CPU is free to reorder it with other instructions in 
the pipeline. Thus, if you want to measure really short portions of 
code, the results could be "surprising". To prevent this, one has to 
manually insert a sequence point. The cpuid instruction does a good job 
here. However, this clearly is only necessary for really short periods, 
periods way below the 500ns the OP asked for.


So how to determine the clock speed?

1) On windows, this is measured by the system and maintained somewhere 
in the registry. I don't know the exact key, but if you look a bit 
around or goggle for it you should be able to find it.

2) An alternative would be to wait for a defined amount of time (let's 
say 100 msec) and get the rdtsc-value before and afterwards  to 
calculate the CPU frequency.
For this you have to:
a) give your thread a high priority: SetThreadPriority(...),
b) set the systems-internal timer to high precision: timeBeginPeriod(1), 
and
c) do a Sleep(100).
With the timeBeginPeriod(1), the systems-internal timers can be expected 
to be precise by one msec, so the Sleep(100) should wait for 100 msec 
with an error of < 1 Percent.

Daniel

Re: Measuring short times

[Tim Prince]

Daniel Lohmann wrote:
> Dennis Clarke schrieb:
>>> Dennis, those Solaris functions were not useful for me because I got
>>> no idea how to make it work on Windows.
>>>     
>>
>> How do you know that those functions are monotonic and consistent ?
>>   
> On IA-32 CPUs (Pentium or K5 and above) rdts returns the content of the
> 64 bit CPU-internal clock counter, which is set to 0 at system start and
> incremented by one at every clock tick. This is guaranteed to be not
> only monotonic, but even strongly monotonic. Moreover, even on a 4.2 GHz
> system it would take 2^32 seconds (>130 years) until the counter
> overflows. For all practical purposes, this should be fine :-)
> 
> Only caveat is that it depends on the CPU clock speed. Not only that the
> basic clock speed is different on every system, it may even change over
> time due to power saving strategies. Nevertheless, for short time
> periods this is on Intel the best method to go.
> 

I don't think it is safe to count on the rdtsc counter being zeroed at
boot.  On most current motherboards, the BIOS attempts to synchronize
the counters on various sockets at boot, but documentation indicates
that can't be counted upon, so it isn't necessarily safe to use rdtsc on
a multiple CPU machine unless timer calls are locked to the same CPU.
Intel CPUs for several years have based rdtsc counter on the front side
buss clock, so it doesn't vary with power saving.  It still is necessary
to disable power saving strategies in the BIOS in order to get full
repeatable performance, particularly for short intervals.  In case it's
of any interest, the 7 year design life of CPUs is contingent on leaving
power saving enabled.
In case it's more convenient, omp_get_wtime() should be capable of the
resolution mentioned by OP.  Windows Vista also should support HPET
timer on recent platforms.