Re: 1000HZ ticks for x86 in the 2.5-tree

On Mon, 8 Jul 2002, H}kan Hjort wrote:

>> C Make Linux/x86 tick at 1kHz instead of 100Hz.
> Yes. This is a good thing.  Apparently vektor asked Linus to do this at
> OLS last week.

A one-man lobby group in action! :)

>> RTC is still more accurate, but on the other hand, you don't need root 
>> privileges to take advantage of the 1kHz ticks!
> How do you mean 'RTC is still more accurate'?  That you can get higher
> interrupt rates than 1k out of it, or what?   

Yup, RTC provides rates upto 8192Hz. And, at least in theory, even with a
1kHz RTC, using on-the-fly reprogramming of RTC it's possible to get
slightly more accurate results.

> Since the displayrates are close to 100Hz, everything above 200/300Hz
> will be enough.

Well, I also sent this to linux-audio-dev, and there the rates are closer
to 100kHz (ie. 96kHz on pro-audio soundcards). ;) But yes, a 1kHz goes a
long way.

Of course this only solves part of the puzzle. There's still the problem
of ensuring our program gets selected before other processes in
ready-state when ticks occur (--> use of SCHED_FIFO/SCHED_RR). Another
thing is to make sure our app is able to complete processing and return to
poll_on_timer() before the next display sync (and the related timer tick),
not just once, but _every_ time (--> minimizing use of non-deterministic
code paths).

But I think these issues aren't as critical for video playback as they are
for audio. After spending some time reading ogle and movietime sources,
I've come to understand that accurate scheduling of video frames (in
relation to display sync) is the most critical issue. And that's precisily
what 1kHz tick will help to improve.

A missed frame or two once a minute is not that bad if all the other
frames are outputted just at the right moment. In audio, a single dropped
sample can result in a spoiled recording session and, well, this is
completely unacceptable for pro-audio use.

--
 http://www.eca.cx
 Audio software for Linux!