Copyright © 1992, Dr. Dobb's Journal

Copyright © 1992, Dr. Dobb's Journal

Copyright © 1992, Dr. Dobb's Journal

Copyright © 1992, Dr. Dobb's Journal

Copyright © 1992, Dr. Dobb's Journal

Copyright © 1992, Dr. Dobb's Journal

This article contains the following executables: HRT.ARC

Thomas Roden

IBM-compatible PCs have always incorporated high-resolution timers (the Intel 8254 and equivalents) that govern short-duration functions like RAM refresh and speaker-tone generation, and longer-duration functions such as time and day determinations. Timers operate by counting pulses at a given frequency. With PCs, the timer input frequency is 1.19318 MHz--going into a 16-bit timer. Frequencies that are integer quotients (up to 1/65536) of the base frequency can be generated. This allows for a minimum frequency of approximately 18.2 Hz (corresponding to a period of about 55 milliseconds).

In PC parlance, the 55-millisecond period is often called a tick; much of the rest of the world, notably Macintosh programmers, use the term to refer to 1/60 second. Since the PC tick consists of 65,536 periods of the timer input (approximately 838 nanoseconds), it is natural to name this period. In the interest of cuteness, I'll refer to it as the "ticklet."

To allow longer durations to be timed, the output of one of the timers (Timer 0) is connected to an interrupt line (IRQ 0). The PC is programmed to respond to this interrupt by simulating a 21-bit timer cascaded from the 16-bit hardware timer. This 21-bit timer is large enough to hold time values up to 24 hours. Under DOS, its overflow is fed to the system date value, which should be good at least until the year 2000.

Time-of-day is normally needed only to the second resolution or slightly better, so Timer 0 is set to the minimum frequency. This allows the PC to spend as little time as possible simulating the additional timer bits, leaving more time for the user's program. Normal time-of-day functions read only the cascaded software timer (also known as the tick count), offering resolutions down to one tick.

Some applications require higher timer resolution, to which there are two popular approaches. For periods under one tick, the speaker timer (Timer 2) can be programmed to start and stop on cue (much like a stopwatch). This supplies resolution down to one ticklet. This ideal limit is degraded by the time it takes to access the timer gate and any other latencies in the control software. Three-ticklet resolution is generally attainable. The main side effect of this technique is that the speaker is unavailable during timing.

For periods over one tick, Timer 0 can be accelerated, causing the tick count to increase more quickly. Typically, a separate tick count is maintained, and the original IRQ 0 interrupt is occasionally simulated to preserve the integrity of the system tick count. The main side effect of this technique is increased system overhead. Increasing the IRQ 0 frequency to the point of supporting millisecond resolution seriously impacts system performance.

A technique outlined by Jerry Jongerius in his article "Accurately Timing Windows Events Without Timer Reprogramming" (Microsoft Systems Journal, July 1991) demonstrates that Timer-0 state can be read and combined with the normal system tick count to supply enhanced timer resolution without additional system overhead. Jongerius realizes 1-millisecond resolution with 100-microsecond resolution on faster machines.

A slightly different approach that streamlines Timer-0 reading and integrates 8259 Programmable Interrupt Controller (PIC) data allows resolution under 16 microseconds on most machines. Here's how it's done: The essence of high-resolution, nonintrusive timing is to combine the ticklet portion of the current time with a tick count. This is accomplished by reading Timer 0 to determine the number of ticklets that have passed since the last tick interrupt, using that value as the low word of the result, and using the low-order portions of the system tick count as the higher-order portions of the result.

Unfortunately, the system tick count is not entirely stable. When the time reaches midnight, the count is cleared by DOS. Since it doesn't transition on a power of two, its error can propagate down to any timing interval. Thus, any routine using the system tick count must be prepared for such an error.

It is possible to add checking to determine if a day overflow has occurred, although this tends to add some overhead to every timer interrogation. There are other ways to handle such cases. These typically involve range-checking intervals and supplying defaults when they are out of range.

The midnight-reset problem can be remedied by keeping a parallel tick count that rolls over on a power-of-two boundary. This can be accomplished by hooking an interrupt service routine (ISR) to IRQ 0. This does increase system overhead, but only slightly. Sixteen bits of count allow for a one-hour range. Thirty-two bits of count allow for a whopping seven-year range.

The ISR should increment its count before transferring to the original interrupt code. This ensures total consistency between the count and the ticklet state by not issuing an end of interrupt (EOI) until after the count is incremented. For the same reason, IRQ 0 (INT 08h) and not INT 1Ch should be the interrupt that is intercepted.

It may be safe to intercept at a different point (such as INT 1Ch) so long as it is not possible to call the ticklet reading code between the times that the IRQ 0 is acknowledged and the IRQ 0 ISR is complete. This would depend on the environment in which this technique is used.

Combining the ticklet count with a parallel tick count can yield 48 bits of information spanning a seven-year period. The lower bits are of questionable accuracy, and the upper bits may correspond to uninteresting intervals. The number of bits to use in a count is the count's dynamic range. Where that window of bits is positioned is the resolution.

  Minimum   Maximum   Variable  Shift
  Interval  Interval  Size
  ------------------------------------

    838 ns  1 hr      32 bits     0
   1676 ns  2 hrs     32 bits     1
   3352 ns  4 hrs     32 bits     2
   3352 ns  0.2 sec   16 bits     2
   13.4 us  0.88 sec  16 bits     4
   26.8 us  32 hrs    32 bits     5
    215 us  14 sec    16 bits     8

To avoid difficult situations, use maximum intervals of twice the durations expected. It is feasible to time intervals near the maximum, but they require sufficiently frequent polling to avoid undetected overflow.

Timer output is an unsigned value. The general case of timing is of the interval from one event to another. At the first event, the timer is sampled and its value is stored. At the second output, the timer is again sampled, and this value is subtracted from the first. This yields a value that is correct even if there is a single timer roll over, so long as the range of the timer is not exceeded.

Timer overflow can be handled by monitoring that the timer in question has overflowed and setting a bit and/or ceasing to increment the timer. This requires additional IRQ-0 handling and is generally more difficult than simply using a wider counter.

There are two major uses for a timer: to record the interval between two events, and to wait until such an interval has elapsed. These uses are analogous to a stopwatch and an alarm clock, respectively. Each task suggests different strategies for dealing with the inaccuracies inherent in DOS-dependent timing systems.

Interval recording is usually for the purpose of statistics gathering. Under these circumstances, it is usually acceptable to clip erroneous values to a "reasonable" range or drop them altogether. A value can be considered erroneous when it falls outside of an expected range.

Elapsed time checking is useful for real-time control systems (and games), where it should be guaranteed that a minimum amount of time passes between two events. The approach for this situation depends on which (hopefully infrequent) error behavior is more acceptable: delaying not long enough or delaying up to twice the requested duration.

Working in units of ticklet is all fine and good for our discussion, but it is certainly not a unit recognized by the National Institute of Standards and Technology. Doing all the work in a common unit would add complexity, overhead, and loss of precision to every step. A more effective approach is to supply routines to convert between ticklets and whatever fraction of second you use.

The conversion from ticklet to microsecond can be accomplished in integer by multiplying by 88/105. This introduces an error of roughly one part in seven million. Microseconds can be converted to ticklets with the inverse (105/88) with the same error. Ticklet/millisecond conversions can be accomplished with the fractions 11/13,125 and 13,125/11.

There are fractions that convert more accurately, but they handle only smaller values, due to intermediate overflow. The precise ticklet/millisecond fractions involved are based on 12,000,000/14,318,180 and its inverse.

Floating point will give better accuracy and less chance of overflow, but it is so slow as to risk affecting the timing. The selection of the suggested fractions was a bit more than pure guess work. It involved weighing the merits of accuracy, range, and compute time. (In fact, this topic is interesting to the point of deserving its own article.)

The supplied implementation is designed for DOS, and may not work properly under other operating environments. In particular, if the Timer-0 frequency is changed, even by one, the assumptions made herein become invalid. One reason is that the behavior of a timer in mode 3 is different for even and odd initial counts. There would also be increased difficulty scaling the count for merging with a tick count.

Environments that virtualize I/O, such as Windows 386 Enhanced Mode, also have a problem. Not only is there a severe performance degradation, but there are also additional requirements to the environment. Operations that change the state of the processor interrupt-enable bit must be honored. There is also a relationship between the state of the timer and interrupt controller that must be simulated or preserved.

As Jongerius points out, Virtual Device Driver (VxD) programming techniques can alleviate these problems. Actually, this technique could be used to improve the performance of the Windows GetTickCount call if it were implemented by Microsoft.

Unfortunately, this issue doesn't affect Windows programs exclusively. If this technique is used in a DOS program running in a 386 Enhanced DOS box, it's values will be highly suspect. Discontinuities and glitchy results become common.

Copyright © 1992, Dr. Dobb's Journal