Time Accumulation
As each hardware clock interrupt is processed, x number of ticks are added to the tick accumulator. A typical dual-processor machine running XP will increment the accumulator 156,250 times per second, with each increment normally being 1/156250th of a second. The machine will therefore see exactly one second having passed each second. If the accumulator is set to add only 78125 counts per interrupt, then after one second has passed, the machine will think a half-second has passed. Domain Time II manipulates the increment amount to achieve its overall slewing to improve long-term clock accuracy. For example, if a machine usually runs fast, Domain Time II will reduce the number of ticks accumulated per hardware interrupt. If a machine usually runs slow, Domain Time II will increase the number of ticks accumulated per hardware interrupt.

You may use the DTCheck /test command-line program to see the counters and settings on your machine.

Clock Granularity
Even though the internal tick accumulator is functioning in 100-nanosecond units (hectonanoseconds), the clock's granularity is limited to the frequency of hardware interrupts. If interrupts occurred once a nanosecond, the machine could simply add one nanosecond per interrupt and be accurate. However, interrupts typically occur only every 15-16 milliseconds. (The exact frequency is derived from the chips on the motherboard, and varies among machines.) The net result is that the system clock must determine how many hectonanoseconds elapse between hardware interrupts, and update the accumulator by that amount each interrupt. The time on the machine therefore jumps forward this interval each clock tick. The amount of the jump is called the clock's granularity, and is the normative best resolution for measuring elapsed time available on the machine.

For example, rapid successive queries of the clock (every 5 milliseconds) might show this behavior:

Thursday, 31 July 2003, 02:09:00.000   <-- starting time
Thursday, 31 July 2003, 02:09:00.000   <-- five milliseconds later, the clock has not advanced
Thursday, 31 July 2003, 02:09:00.000   <-- ten milliseconds later, the clock still has not advanced
Thursday, 31 July 2003, 02:09:00.015   <-- fifteen millisecond jump according to the system clock
Thursday, 31 July 2003, 02:09:00.015   <-- should be .020 by now, but the clock has not advanced
Thursday, 31 July 2003, 02:09:00.015   <-- another five milliseconds, but the clock has not advanced
Thursday, 31 July 2003, 02:09:00.031   <-- sixteen millisecond jump
Etc.

Overcoming Clock Granularity Limits
Modern systems maintain multiple timers, including the high-performance multimedia timer. The multimedia timer typically has a granularity of 3073670000 counts per second. The granularity of the multimedia timer will vary from machine to machine, and is based on the underlying hardware.

Although the multimedia timer has a very high resolution (low granularity), it is not tied directly to the system clock. Therefore, ticks accumulating on the multimedia timer do not affect the granularity of the reported time-of-day. In addition, the multimedia timer "rolls over" periodically--that is, it simply counts up until it hits the maximum count, then starts again at zero. The multimedia timer by itself cannot therefore be used to track the system time.

Windows machines also have a high-performance "waitable timer," which is a mechanism that allows the system to signal a program at predictable and reliable intervals of one millisecond or more.

Domain Time II uses all three kinds of timers to interpolate the time of day during the 15-16 millisecond period when the time-of-day does not advance. Domain Time II sets a waitable timer for a one-millisecond period, and each period uses the multimedia timer to estimate how much time has actually elapsed. The derived value is accurate to the limit of the multimedia timer's granularity (typically on the order of microseconds or hectonanoseconds), and the net result is added to the current time-of-day as reported by the operating system.

Using interpolated time, rapid successive queries of the clock (every 5 milliseconds) show behavior like this:

Thursday, 31 July 2003, 02:09:00.000   <-- starting time
Thursday, 31 July 2003, 02:09:00.005   <-- five milliseconds added by interpolation
Thursday, 31 July 2003, 02:09:00.010   <-- another five milliseconds added by interpolation
Thursday, 31 July 2003, 02:09:00.015   <-- system clock shows correct time briefly
Etc.

The net result is that times may be compared among machines far more accurately than when relying solely on the system clock. The increase in accuracy is actually greater than the example above shows, since Domain Time II interpolates hectonanoseconds rather than milliseconds.