[Developers] Proposed Cactus Timer API (Posix timers)

Steve White swhite at aei.mpg.de
Fri Aug 13 12:05:27 CDT 2004


Your proposal makes a lot of sense as a means of determining a working
value for precision, in the sense of the repeatability of measurement.
I'll think about what it would mean to implement it in Cactus.  I think
I'll play with your program a bit this weekend...

As to the question of accuracy, in the sense of agreement with "real" time
(in the context of the clock in question):  By definition it's something
that can't be determined from within the system.

I was working from the notion of resolution, as a lower bound for the
minimum turn-over time for the clock.  This is of some use by itself.
The loops I wrote are just a crude means of looking at that time.  I was
hoping that more API's would provide such a thing, but found that some of
the resolutions provided by standard timers don't even make sense (the
POSIX timers).

I did write that thorn based on the MPI timer (it's in AlphaThorns now),
which I think does something internally like your "hidden timers"
suggestion:  It finds the best high-resolution timer for the system.  It
also provides a resolution (for what it's worth). There is a bug with it
that I hope to fix soon.

I will also think about a thorn for POSIX timers.  It's easy enough and
shouldn't suffer from the same problems as the MPI timer, although
portability is a problem.

Steve White : Programmer
Max-Planck-Institut für Gravitationsphysik      Albert-Einstein-Institut
Am Mühlenberg 1, D-14476 Golm, Germany                  +49-331-567-7329

On Thu, 12 Aug 2004, John Shalf wrote:

> 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).
> -john

More information about the Developers mailing list