The non-rtc timing code was written assuming that kernel HZ is always 100, and biases the timing to compensate for the average 5 ms ("randomly" 0-10 ms) extra delay when sleeping. With the current Linux kernels this assumption is no longer true. The kernel config has choices for HZ 100, 250 and 1000, and most distributions use the higher values (Debian uses 1000). The patch removes the bias and some unnecessary complexity from the timing (at least I believe special-casing "usec_sleep(0)" was useless unless someone can demonstrate otherwise). The code still assumes HZ=100 if softsleep is being used. Timing error relative to desired time with and without the patch: HZ 100 without patch: -5 to +5 ms HZ 100 with patch: 0 to +10 ms HZ 250 without patch: -5 to -1 ms HZ 250 with patch: 0 to +4 ms HZ 1000 without patch: -5 to -4 ms HZ 1000 with patch: 0 to +1 ms With normal a/v sync options the effect of the systematic bias in either direction is small as it will get compensated for in the sync code, so in most cases this patch will not result is significantly changed behaviour. The documentation should also be updated to mention that both rtc and softsleep are useless on HZ 1000 boxes (and maybe HZ 250 too). With kernel HZ 1000, non-rtc has timing accuracy similar to rtc, but is better in the sense that the code does not need to wake up every 1/1024 s while sleeping to check the time.