[Developers] Proposed Cactus Timer API (Posix timers)
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
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).
More information about the Developers