[Developers] Proposed Cactus Timer API (Posix timers)

John Shalf jshalf at lbl.gov
Thu Aug 12 14:25:19 CDT 2004

Just looking through the code, I see that you are looking at the first 
timer "turn over" of the clock timer to estimate the timer resolution.  
It is necessary to find the average & standard deviation of the 
granularity of clock turn-overs.  In order to determine the accuracy of 
the timer, you have to take the average of many timer "turn over" 
events.  The precision is related to the standard deviation of the 
turn-over events (assuming the method of sampling is faster than the 
timer.. I think this is generally true for a simple timing loop).  I 
think this is probably why the results are inconsistent with the 
resolution function.

I've attached a program that I've been using to compare gettimeofday() 
implementations on different platforms.  I'm sure it can be adapted for 
the posix timers.

So on a BSD system, I get the following timing report
	Mintime=1 usec Maxtime=20979 usec Average= 1.47511 usec
I get pretty accurate timing on the BSD system for the default cactus 
timers (with a few exceptions).

On the Cray X1 I get the following timing report
	phoenix% ./a.out
	Mintime=56 usec Maxtime=15200 usec Average= 101.719 usec

Accuracy and precision will tell you different things about the meaning 
of the timing results. On the X1, the timer will not be accurate for 
measuring events that are less than the average timing granularity.  I 
didn't compute the std deviation, but if you do so, it will provide you 
with enough detail to estimate the precision of the timer (and 
consequently the precision of the timing results +/- some percentage).

The range of timings (mintime vs. maxtime) indicate that standard 
deviations are going to be pretty large.  When I plotted the histogram 
of the timings, it looks a lot like a poisson distribution (makes sense 
I guess).


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: clock2b.c
Url: http://www.cactuscode.org/pipermail/developers/attachments/20040812/e8af6667/attachment-0001.c 
-------------- next part --------------

On Aug 11, 2004, at 2:46 PM, Steve White wrote:
> Since we're on the topic, I thought I'd try out some other timers that
> are laying around.  The POSIX timers ('clock_gettime' etc) are high
> resolution (in principle down to nanoseconds) and have a means of
> reporting resolution ('clock_getres').
> Attached find a program that sees how long each clock takes to turn
> over and prints the reported resolution of each.
> 	gcc -c clock.c
> 	gcc clock.o -lrt
> 	./a.out
> The POSIX clocks also have something resembling the Cactus timer's
> modularity: clocks can be added that use the same interface.
> Drawbacks:  Not quite as universal as gettimeofday, getrusage. Some  
> clocks
> are missing on some systems (Peyote and the Xeons are missing the
> MONOTONIC clock).
> Bugs:  It would appear that the resolution function is just wrong for  
> some
> clocks, reporting a resolution much larger than the time required for  
> the
> clock to turn over.
> Here's the Peyote output:
> 	3.002000e-06 sec turnover; 1 iterations
> 	resolution 1.000000e-09 sec
> 	1.000000e-06 sec turnover; 1 iterations
> 	CLOCK_REALTIME resolution 1.000000e-02 sec
> 	1.939000e-06 sec turnover; 1 iterations
> 	resolution 1.000000e-09 sec
> Note the PROCESS and THREAD_CPUTIME clocks report 1 nanosecond  
> resolution,
> which isn't wrong, in the non-strict sense of a lower bound (it could  
> be
> considered overly optimistic).  But the REALTIME clock reports a
> resolution that is much larger than the smallest turnover time.  I  
> think
> this renders the resolution function questionable, if not useless.
> ----------------------------------------------------------------------- 
> -
> Steve White : Programmer
> Max-Planck-Institut f?r Gravitationsphysik       
> Albert-Einstein-Institut
> Am M?hlenberg 1, D-14476 Golm, Germany                   
> +49-331-567-7329
> <clock.c>_______________________________________________
> Developers mailing list
> Developers at cactuscode.org
> http://www.cactuscode.org/mailman/listinfo/developers

More information about the Developers mailing list