timers(5)timers(5)NAMEtimers - timers and process time accounting information
SYNOPSIS
#include <sys/time.h>
DESCRIPTION
The timing facilities under IRIX consist of interval timers, event
timing, process execution time accounting, and time of day reporting.
Interval timers consist of POSIX timers (see timer_create (3c)), and
itimers that were introduced in BSD4.2 (see getitimer(2)). Use of the
POSIX timers is strongly recommended for new applications. The IRIX-
unique BSD4.2 itimers are supported only to provide compatibility for
older applications.
On Silicon Graphics machines there are two independent timers per
processor. The first interrupts the processor at a regular interval of
10 milliseconds and is used for scheduling and statistics gathering. The
second interrupts the processor at fasthz frequency and is used to
support the high resolution POSIX and itimer capabilities. On
multiprocessor machines, one processor is used to maintain system time
and low frequency system tasks, and is labeled the clock processor. One
processor is also required to service high frequency system tasks and is
labeled the fast clock processor. The mpadmin(1) command can be used to
bind the clock and fast clock to a particular physical processor.
A real-time process (one with priority between 0 and 255) may make POSIX
timer requests, or itimer requests with a resolution greater than 10
milliseconds when using the CLOCK_REALTIME timer. The limit on the
resolution depends on the underlying hardware and can be dynamically
determined by examining the variable fasthz using systune(1M) or by
opening /dev/kmem and reading fasthz as a 4 byte word. The fasthz
variable can also be modified using systune(1M).
On the Indigo, Indy, Indigo2, O2, and Octane products, acceptable values
for fasthz are 500, 1000, and 2500 Hz. If the requested value is not one
of these values, then the default value of 1000 Hz is used. On the
Challenge Series, the resolution of the hardware timer is 21 nanoseconds
and therefore any value smaller than 47MHz is possible. For realistic
results, no fasthz value larger than 2000 Hz should be specified because
the kernel cannot reliably deliver itimer signals at a greater rate.
On Onyx2, Onyx3, and Origin Systems, fasthz has a value of 1250 Hz which
gives a resolution of 800 microseconds. For processes running with
either the FIFO or RR scheduling policies, both POSIX timers with
CLOCK_SGI_FAST, and itimers with ITIMER_REAL have a resolution of 0.8
microseconds. This does not necessarily mean that timer interrupts can
be received at that frequency, the timers simply have that resolution.
It is not possible to achieve better than 10 millisecond timer accuracy
when running without either a FIFO or RR scheduling policy. To take low
latency timestamps with maximum resolution on Onyx2, Onyx3 and Origin
Page 1
timers(5)timers(5)
systems, clock_gettime (CLOCK_SGI_CYCLE) should be used. This will give
a timer resolution of 0.8 microseconds.
On Origin3000, Origin300, Onyx3000, Onyx300, Fuel, and Tezro series
systems the resolution of the hardware real-time clock can be set with
the PROM command "rtc <kHz>". The RTC drives the fast clock. The
default kHz is 1250 and thus has a resolution of 0.8 microseconds. The
value of kHz should not be changed by more then an order of magnitude.
Setting a resolution of worse than 1.0 microseconds will interfere with
IRIX's ability to smoothly keep track of the time of day. Many digital
media hardware boards expect a 1250 kHz RTC and so changing it will break
their behavior.
Event timing is typically used by the programmer to measure the elapsed
time between events. By examining the time before and after an operation
and then computing the difference, the application can calculate the
elapsed time of the operation. The POSIX clock_gettime(2), the System V
time(2), times(2) and Berkeley gettimeofday(3B) calls may be used to that
end. IRIX also allows the user to map a hardware counter into the user
address space and read it directly for low overhead time snapshots.
Information about the address and rate of the hardware counter is
available through the SGI_QUERY_CYCLECNTR request to the syssgi(2) system
call. The mmap(2) system call can then be used to make the counter
directly available to the user process.
Process execution time accounting is typically measured under System V
with the times(2) system call and under Berkeley with the getrusage(3)
system call. Traditionally under UNIX, the time reported by these system
calls is measured by the scheduling clock. On each clock tick the kernel
examines the processor status word and charges the running process a
tick's worth of execution time in user or system mode. The most
significant drawback of this scheme is limited precision. Under IRIX,
the kernel keeps track of process state transitions between user and
system modes and accumulates the elapsed time between state transitions.
This information is available through the times(2) and getrusage(2)
system calls.
System time of day can be obtained via the gettimeofday(3B) system call.
On the Challenge, Origin, and Onyx Series, there is a 64 bit counter that
is used to maintain system time. The system initializes a timebase at
startup using the battery backed time of day clock and associates a
counter value with that timebase. Subsequent gettimeofday() calls will
return the original timebase plus the difference between the current
counter value and the original startup counter value. A gettimeofday()
call causes the kernel to report the current time plus the difference
between the current counter value and the last snapshot value of the
counter from the scheduling clock. On some other Silicon Graphics
machines, there is a 64 bit data structure that is maintained by the
clock processor. On every clock tick, the kernel updates that data
structure by an amount equal to the clock tick (typically 10
milliseconds). A gettimeofday() call will return the current value of
that structure. When timed(1M) is running, the gettimeofday() and
Page 2
timers(5)timers(5)time(2) results will be adjusted to match time of other machines running
timed within a local area.
On multiprocessor machines timers live on the processor where the program
that created them was running at the time they were created. A timer
stays connected to that processor until it expires, is disabled or the
user restricts, isolates, or wards the processor with the timer. If a
user restricts, isolates, or wards a processor with timers, all of the
timers are moved to the processor that owns the clock as reported by
sysmp(2).
SEE ALSOclock_gettime(), clock_settime(), clock_getres(), getitimer(2), sysmp(2),
syssgi(2), time(2), timer_create(3C), timer_delete(3C),
timer_getoverrun(3C), timer_gettime(3C), times(2), getrusage(3),
gettimeofday(3B)
Page 3
