Here we compare timer granularity that is supported by 2.4.18 and 2.5.59 kernels as ran on stock Redhat 8.0 system. As for all graphs of this type results show "requested sleep versus actual sleep" durations. We take samples every 10 usec for all values less than 3000 usec and after that we take a sample every 1000 usec (or every 1 msec.) At each requested sleep duration 100 samples are taken. The graphs shows all the data points and thus one observes vertical lines in cases where there is conisderabl variation in the amount of actual sleep duration for a given requested sleep duration.
First graph show the entire data collected, while the second graph shows 0-5000 usec requested sleep region in an expanded manner. Beside the collected data a slope 1 line (actual=requested) is shown. Should any points fall below this line it would mean that actual sleep duration was less than requested duration. This would supposed to violate semantics of nanosleep() call that we use to do the sleep request.
We note the following points: minimum sleep duration for Redhat 8.0 supplied 2.4.18 kernel seems to be about 3300 usec. For 2.5.59 kernel the minimum sleep duration is 2000 usec with 1000 usec steps after that. Thus, 2.5.59 kernel (as do most 2.5 series kernels) runs at 1000 HZ clock. However, in Linux the minimum sleep duration turns out to be 2 ticks, not 1 tick. This has been observed for some time, as in Linux 2.2.5 results in and Linux 2.4.10 results in that are shown under this category of results. Please see Overview section for a link to an explanation.
These tests were conducted at time shared priority. (This is what our "non-root" designation means.) Running these tests as root (at prio=20) did not materially change the amount of observed hjitter.