lkml.org 
[lkml]   [2005]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] i386: Selectable Frequency of the Timer Interrupt
From
Date
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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-07-12 17:10    [W:0.093 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site