[MPlayer-dev-eng] [PATCH] Remove assumptions about kernel HZ=100 from timing
Uoti Urpala
uoti.urpala at pp1.inet.fi
Sun Apr 2 12:34:11 CEST 2006
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: timing.diff
Type: text/x-patch
Size: 1200 bytes
Desc:
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20060402/f20f23b1/attachment.bin>
More information about the MPlayer-dev-eng
mailing list