Linux provides several mechanisms for event timing, ranging from 1-second down to submicrosecond resolution. This section discusses the following timing sources:
date The resolution of date is 1s. Using the +%s formatter, date returns the number of seconds that have elapsed since 00:00:00, January 1, 1970.
jiffies The resolution of jiffies is 10ms. On all platforms, Linux configures a hardware timer that interrupts the processor periodically typically every 10ms (this value is defined in the kernel source as HZ). The timer interrupt routine increments the kernel variable jiffies by 1. Therefore, the value of jiffies represents the number of 10ms increments that have occurred since booting. It is possible to increase jiffies resolution by altering the HZ source declaration. However, this could ultimately lower overall system performance due to increased interrupt processing. Other mechanisms offer higher resolution.
PSR The resolution of PSR (which stands for processor-specific registers) is various. Some newer processors contain two 32-bit counters that increment on every system clock cycle. The counters accessed through PSR provide resolutions that are dependent on processor clock speed. Kernel source code provides function calls to access the PSR. For example, the rdtsc function returns the timestamp counter (TSC) on Pentium and newer processors, and the get_tbl function returns the mftb register value on PowerPCs. 486 and ARM processors do not contain system clock counters.
get_cycles The resolution of get_cycles is various. The get_cycles function, which is defined all on platforms, returns a count of system clock cycles that fit into a single CPU register. Typically this is the lower half of the two 32-bit counters mentioned previously. If the processor doesn't contain a clock counter, get_cycles returns 0. get_cycles returns 0 on 486 and ARM processors.
do_gettimeofday The resolution of do_gettimeofday is about 1ms. The do_gettimeofday function fills a timeval data structure with the number of seconds and microseconds elapsed since booting. The x86 and PowerPC kernel source claim near-microsecond resolution for do_gettimeofday.
The Project Trailblazer race timer needs to have 1ms resolution. This resolution eliminates using date and jiffies. The MZ104's 486 and the MediaEngine's ARM processors don't contain system clock counters, so the Project Trailblazer engineers also can't use PSR. The get_cycles function returns only a 32-bit counter value. On the slowest clocked target board, the RPX-CLLF (at 70MHz), the get_cycles function can only count 61 seconds' worth of microseconds. A typical race will be longer than 61 seconds, so the get_cycles function won't work for Project Trailblazer. This leaves the do_gettimeofday function. With near-microsecond resolution and a 32-bit counter of seconds (232 seconds = 49,710 days), the do_gettimeofday will provide accuracy for even the longest race. The race timer's interrupt routine can timestamp the race's start and finish by using do_gettimeofday. A scheduled task can later compute the race's overall time.
Interrupt latency is a measure of the time between an event occurring (for example, the race start) and when the processor executes the interrupt handler code. Even with microsecond timing access, race timing won't have millisecond accuracy if the system interrupt latency exceeds a millisecond. The next section examines the Project Trailblazer engineers' development of interrupt handlers within a device driver to measure average interrupt latencies for the MZ104, MediaEngine, and RPX-CLLF target boards.