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

Martin J. Bligh
2005-07-12T15:11:30Z

--Lee Revell <rlrevell@joe-job.com> wrote (on Tuesday, July 12, 2005 11:00:02 -0400):

> 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...

Well, looking forward, you'll have sub-HZ timers, so none of this will
matter. Actually, looking at the above, 150 seems perfectly reasonable
to me, but 300 seems to be close enough. I'll run some numbers on both.

>From your above email, I'm more convinced than ever that lowering HZ is
the right thing to do ...

M.