Example 5-1 shows an outline of code to initialize a repeating timer signal.

usema_t * alarmSema; /* initialized elsewhere */
void uponSigalrm()
{
   usvsema(alarmSema); /* count a period */
}
int setUpTimer(long periodInMicrosec)
{
   struct sigaction alarmActor = {SA_RESTART,uponSigalrm,0};
   struct itimerval period = {{0, 0}, {0, 0}};
   if (sigaction(SIGALRM, & alarmActor, NULL))
   {
      perror("sigaction");
      return -1;
   }
   period.it_interval.tv_usec = periodInMicrosec;
   period.it_value.tv_usec = periodInMicrosec;
   if (setitimer(ITIMER_REAL, &period, NULL)) 
   {
      perror("setitimer");
      return -1;
   }
   return 0; /* indicate success */
}

The example begins by defining a signal-handling function, uponSigalrm(). This handler performs the V (count-up, revive) operation on a semaphore. When the main process has completed its work for one interval and is ready to wait until the next interval, it will perform the P (count-down, deplete) operation on the same semaphore. (This is one of many possibilities for interaction between the signal handler and the main process. For an example of another method based on sigsuspend(), see “Interprocess Communication” in Appendix A.)

The periodic timer is initialized in the function setUpTimer(). It establishes uponSigalrm() as the signal handler. Then it initializes the itimer, using a period passed as an argument.

In the Challenge/Onyx and POWER-Challenge architectures, each CPU has a hardware-operated cycle counter and a hardware comparator that generates an interrupt when the comparator register matches the cycle counter. In these systems, the kernel can manage interval timers with the minimum number of interrupts.

In the Challenge/Onyx systems, the number of timer interrupts the kernel must handle depends only on the number of active timer requests and their repetition rates. If there are many timers, or if there are repeating timers with very short intervals, there will be many interrupts. Normally there are fewer interrupts than in a system without a clock comparator.

In all uniprocessor systems and in the Crimson series (the only multiprocessor systems supported by IRIX 6.2 that lack a hardware clock comparator) the kernel manages interval timers using a periodic interrupt, as follows.

The key point is the value of the periodic interval T at which the kernel updates timers. No timer interval can be shorter than T. The smaller the value of T, the more frequently the kernel must inspect all timers.

By default, T is one second divided by the value HZ defined in /usr/include/sys/param.h. In all recent versions of IRIX, HZ=100, so T, the minimum itimer interval, is 10 milliseconds. For normal processes—that is, processes not running at a nondegrading priority in the real-time band—no interval shorter than 10 milliseconds can be scheduled. The interval requested by a normal process is rounded up to whole multiples of 10 milliseconds.

In systems with a clock comparator, the fasthz tuning parameter has no effect on timer requests. Timer requests from real-time processes are rounded only to the nearest hardware timer unit—21 nanoseconds in the Challenge/Onyx system.

In uniprocessors and Crimson systems, the minimum effective timer resolution for real-time processes is set by the fasthz system tuning parameter. Any timer request is rounded up to the nearest multiple of the fasthz interval.

You can inspect and change the current value of fasthz using the systune command

# systune -i
Updates will be made to running system and /unix.install
systune-> fasthz
        fasthz = 1000 (0x3e8)
systune-> quit

The default value is 1000. That is, the minimum effective timer interval for a real-time process is 1 millisecond.

In systems that have no clock comparator, the kernel implements fast timers by shortening the periodic timer interval to the fasthz frequency whenever a process sets a timer at an interval that is not a multiple of HZ The frequent interrupts needed to support fast timers cause an overhead load of several percent of the power of one CPU. In these systems you should try to design your real-time application to use intervals that are multiples of 10 milliseconds, so that the fast interrupt rate is not needed. When that is not feasible, you can assign the interrupt to a particular CPU (see “Assigning the fasthz Processor”).

You may need to experiment with different fasthz values in order to produce a repeatable, short interval. On a Challenge/Onyx system the hardware clock interval is 21 nanoseconds, which does not divide evenly into most fasthz intervals. The fast timer support code uses integer division, and it has some difficult problems with truncation.

For example, suppose you want to set an itimer to define a 60 Hz frame rate. You would set an itimer with a value of 16,667 microseconds.

Experience has shown that the default fasthz value of 1000 does not give good results with a 16.67 millisecond itimer. In IRIX version 5.2, this combination “jitters” on either side of the target interval. In version 5.3, itimers are guaranteed always to delay at least the specified time. While in 5.3 the interval is not shorter than 16.67 milliseconds, it is sometimes longer. Changing to a fasthz of 2400 (a multiple of the desired interval rate) does not solve the problem, which was due to integer truncation in the timer routine. However, a fasthz frequency slightly less than a multiple of the desired frame rate, 2390, does produce a dependable 16.7 millisecond interval.

---

Note: Itimers are not recommended as a way to schedule for a high frame rate. When designing a real-time program for a high frame rate the REACT/Pro Frame Scheduler offers a much more reliable and accurate way to schedule repetitive processes.

---

Normally, interval timer interrupts are taken by the CPU in which the itimer was initialized. However, when you isolate a particular CPU (see “Isolating a CPU From TLB Interrupts”), all itimers pending for that CPU are retargeted to the assigned Clock CPU (see “Assigning the Clock Processor”). Any new itimer requests made in an isolated CPU after it has been isolated are taken on that CPU.

For a continuously-running real-time process, it is generally best to take interval timer interrupts on the CPU where the process runs. This helps to reduce the impact of timer handling on other CPUs, and helps to reduce the time to deliver the SIGALRM.

When timer interrupts are handled in any CPU, timer handling can temporarily be out of synchronization with the time-of-day service. There is a kernel tuning parameter, itimer_on_clkcpu, which if set forces all timer interrupts to be taken on the CPU that is the clock CPU. This parameter should only be set when it is crucial that all processes see an exact, consistent relationship between itimer intervals and time of day stamp values. Because it forces timer handling to a single CPU, it can increase the latency of SIGALRM delivery.

TheBSD UNIX gettimeofday() function returns the time as two long integers in a timeval structure. (For details of the call, refer to the gettimeofday(3) reference page.) The fields of a timeval are as follows:

struct timeval {
   long tv_sec; /* seconds since Jan. 1, 1970 */
   long tv_usec; /* additional microseconds */
}

The nominal resolution of this timestamp is 1 microsecond. However, it is not practical for the kernel to update an internal timestamp with this frequency. The actual timestamp value is updated at intervals that are convenient to the kernel. The intervals are not regular, and they differ with hardware and with the version of IRIX in use. However they are never greater than 10 milliseconds.

This does not mean that successive calls to gettimeofday() return the same value. On the contrary, experimentation reveals that successive calls always return different values. (See the sample program under “Getting the Time of Day Stamp”.)

Normally an IRIX system uses one of the time-synchronization daemons, either timed or timeslave, to keep the local clock accurate. These daemons use adjtime() to adjust the time of day when necessary. (See the timed(1), timeslave(1), and adjtime(2) reference pages.) Thus the timestamp returned by gettimeofday() should reflect the true local time, with an inaccuracy of at worst -10 milliseconds.

Either the date command or the time daemon can adjust the current time by a negative increment. As a result, gettimeofday() can in rare circumstances return duplicate values, or a value that is less than the value from the preceding call (see the date(1) reference page).

The POSIX-compliant clock_gettime() function returns the time of day as two long integers in a structure

The gettimeofday() function returns the time as two long integers in a timespec structure. (For details of the call, refer to the gettimeofday(3) reference page.) The fields of a timeval are as follows:

typedef struct timespec {
   long tv_sec; /* seconds */
   long tv_usec; /* and nanoseconds */
} timespec_t;

The nominal resolution of this timestamp is 1 nanosecond. However, it is not practical for the kernel to update an internal timestamp with this frequency. The actual timestamp value is updated at intervals that are convenient to the kernel. The intervals are not regular, and they differ with hardware and with the version of IRIX in use. However they are never greater than 10 milliseconds.

Normally an IRIX system uses one of the time-synchronization daemons, either timed or timeslave, to keep the local clock accurate. These daemons use adjtime() to adjust the time of day when necessary. (See the timed(1), timeslave(1), and adjtime(2) reference pages.) Thus the timestamp returned by clock_gettime() should reflect the true local time, with an inaccuracy of at worst -10 milliseconds.

Either the date command or the time daemon can adjust the current time by a negative increment. As a result, clock_gettime() can in rare circumstances return duplicate values, or a value that is less than the value from the preceding call (see the date(1) reference page).