This web page presents a simple tool for comparing operating system jitter.

Periodic scheduling test

Our overall goal is to schedule a process to periodically wake up and perform some function. For many mission critical applications a very high degree of predictability in this scheduling is required. Ideally, we would like the operating system to wake up the process at the rate we request with tightly bounded jitter. We further test the operating systems' ability to guarantee this bounded behavior under under a potentially large overload of other lower priority, non real-time, processes. These other non real-time processes are divided into three categories: computationally intensive, disk intensive, or network intensive.

For most of the tests we apply the following algorithm:

a = gettimeofday();    		/* measure delta time since last sleep */
for (i = 0; i < NUM_SAMPLES; i++) {	/* one million iterations, typically */
   nanosleep(20000000);   	/* sleep for 20 msec; = 50 HZ  */
   b = gettimeofday();    	/* measure delta time since last sleep */
   record (b - a);        	/* record the measurement in a histogram */
   a = b;

Some of the kernel tests use the following algorithm:

for (i = 0; i < NUM_SAMPLES; i++) {	/* one million iterations, typically */
   t1 = get_cycles();			/* read x86 TSC register */
   nanosleep(20000000);			/* sleep for 20ms */
   t2 = get_cycles();			/* read x86 TSC register */
   record( (t2 - t1) / CPU_KHZ * 1000);	/* record delta */

In order to differentiate between the two algorithms, we measured the overhead of the two (gettimeofday() vs get_cycles()) calls.

On the "bert" system configuration running Linux 2.6.0-test2-mm1 we obtained the following results:

   1000000 calls to gettimeofday in 1.420258 secs.
   1.420258 usec per invocation.

   1000000 calls to get_cycles() in 0.156194 secs.
   0.156194 usec per invocation.

Based on this data gettimeofday() is almost an order of magnitude slower.

How to use

To generate a graph overlaying the histograms of measured jitter, select the measurements of interest and click on the plot button.

Below the generated graph two more click-able links are presented. The first is the summary of the data in tabular form. The second is a graph of the data plotted using gnuplot's pm3d mode for splot. This graph is useful for visualizing the spread in large sets of data.


The Jitter Comparator was developed during summer of 2003 and was greatly aided by summer interns Keith O'Hara and Gaurav Naik. Some of Keith's slides on these topics are available here.

The Jitter Comparator is a companion to our existing Middleware Comparator. Additional information about the comparator, including how the graphs are labeled, is given in the overview associated with the MW Comparator.