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

[Lee Revell <rlrevell@joe-job.com>]

On Mon, 2005-07-11 at 21:30 -0700, Martin J. Bligh wrote:
> Some sort of comprimise has to be struck for now, until we get sub-HZ
> timers. I'd prefer 100, personally (I had that set as default in my tree
> for a long time). Some people would prefer 1000 or even more, maybe.
> 250/300 seems like a reasonable comprimise to me. Exactly what problems
> *does* it cause (in visible effect, not "timers are less granular").
> Jittery audio/video? How much worse is it?

OK, here's a real world example, taken straight from the linux-audio-dev
list today.

Lee

Lee Revell <rlrevell@joe-job.com> :
> On Tue, 2005-07-12 at 20:57 +0200, Kjetil Svalastog Matheussen wrote:
>> E-radium has been tested with both the 2.4 kernel and the 2.6 kernel
>> and with a ~1GhZ machine and a ~2ghz machine. (A 2.4 kernel with a
>> 100hz resolution timer will proably not work very nice though.)
>
> Can you please explain why 100HZ would be a problem for your app?  Right
> now the kernel people are trying to change the default HZ for 2.6 to
> 250.  I have told them that this is insane but they seem inclined to do
> it anyway.
>

The program use poll to sleep. If the resolution of the kernel is 100Hz,
there would sometimes be a too long delay of up to 10ms (and probably beyond)
before the program is woken up,  and before a midi message is sent,
which can cause music to stutter.

Simple as that. :-)

> If you can provide more examples of apps that would be broken by this
> change maybe we can convince them not to change it.
>

Hmm, mplayer I guess...
Don't know how muse, rosegarden, seq24 etc. handles timing...
But all midi-sequencers that doesn't use /dev/rtc could suffer. (?)


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