Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

Lee Revell
2005-07-12T15:03:29Z

On Tue, 2005-07-12 at 07:56 -0700, Martin J. Bligh wrote:
> --Lee Revell <rlrevell@joe-job.com> wrote (on Tuesday, July 12, 2005 10:24:59 -0400):
>
> > On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
> >> Exactly what problems
> >> *does* it cause (in visible effect, not "timers are less granular").
> >> Jittery audio/video? How much worse is it?
> >
> > Yes, exactly. Say you need to deliver a frame of audio or video every
> > 5ms.
>
> Ummm. that's a 200HZ refresh rate, is it not? That seems unreasonable
> (to a lay-person, as far as video goes).
>

Seems unreasonable now but things like HDTV actually have much tighter
constraints than this. And frame times this small are quite often used
for audio, which admittedly is less affected by HZ because those devices
generate their own interrupts.

> > You have a rendering thread and a display thread that communicate
> > via FIFOs. The main thread waits in select() for the next frame to
> > complete rendering or for the deadline to expire. That's next to
> > impossible with HZ=100, because the best you can do is the deadline
> > +-10ms. With HZ=1000 it's no problem.
>
> So if we have a 50HZ refresh rate, and a HZ rate of 250 or 300, it'll
> work fine then, right? I know that's actually some error in the timers,
> so it may be 2 or 3 ticks, not 1, but if we're running HZ at 5 or 6
> times the frequency of video, presumably that'd still work fine?

Yes, for PAL/NTSC, but it's nice to be forward looking...

Lee