Re: timing

New Message Reply Date view Thread view Subject view Author view

Jim Helman (jimh++at++surreal)
Mon, 20 Nov 95 16:17:56 -0800


>From the man page:;;;;

> pfGetTime returns a high resolution clock time in seconds that is
> relative to the initial time set by pfInitClock. It determines the
> highest resolution clock available and uses that clock in all subsequent
> calls. On Indy, Indigo, Indigo2, 4D/35, Power Series systems with IO3
> boards, and Onyx, the resolution of the clock is submicrosecond. If the
> hardware does not support a high resolution counter, the time of day
> clock is used which typically has 10ms resolution (see below).

The resolution of the counter on Onyx 21ns, so the overhead for the
call itself (1-2 usec on a 150MHZ machine) predominates. Also note
that you will have variations, possibly quite significant if another
process wants to run. For solid timings, it's best to run on an
isolated CPU. Performer 1.2 may also have some slight variability in
timing because it acquires a lock which another process or the wrap
process may hold. So banging heavily on pfGetTime() simultaneously in
multiple processes is a bad idea in 1.2. 2.0's pfGetTime is much
improved and does not need to acquire a lock.

rgds,

-jim helman

jimh++at++surreal.asd.sgi.com
415/933-1151


New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:52:03 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.