Re: latest 'guaranteed low latency' patch against 2.2.14

From: Benno Senoner (sbenno@gardena.net)
Date: Tue Feb 08 2000 - 16:40:42 EST


On Tue, 08 Feb 2000, Balaji Srinivasan wrote:
> >
> > I think most of us will be happy with 500-1ms max scheduling latency
> > when running SCHED_FIFO tasks.
> > Especially multimedia folks because this will enable linux to solve a wide range
> > of real-time multimedia problems like audio and video.
[...]
> If you are interested you could take a look at KURT
> (http://hegel.ittc.ukans.edu/projects/kurt) which is specifically tailored
> to handle multimedia kinds of firm real-time tasks. There is work that
> needs to be done in this area, but i am willing to put time in if we can
> get a reasonable interest in it. Right now you have to inform the kernel
> as to your processing requirements before you start and then the kernel
> either admits ur process or not. After that the kernel takes care of
> scheduling your process at a periodic rate.
>

Yes, I know KURT, but I still think that the
low-latency patch + running apps with SCHED_FIFO and mlockall()
solves most of multimedia very well,
and ofter you need not periodic scheduling but fast response time to
external events.
For example a MIDI synth implemented in software:
you have to react very fast to an incoming MIDI command on the MIDI input
and render the note in form of audio samples to send to the soundcard's DAC
using very small buffers (ideal would be <5-10ms).

Plus consider the fact that we all want Linux to become a good
desktop/multimedia OS soon, without being forced to install special kernels,
tools etc
Since Ingo's lowlatency work is not a radical change, but is based on
adding pre-emption points at critical points in the kernel,
(and reducing execution paths) it will go almost certainly into linux 2.4.
And once Linux will provide "sub-millisecond scheduling latencies"
out of the box , people will begin to see it as a serious alternative to other
multimedia OSes.

The only thing I miss in linux is the UTIME stuff, it would be really nice to
schedule things with microsecond resolution.
But meanwhile we can use other tricks to achieve sub-ms accuracy,
for example by using the RTC clock combined with the RDTSC instruction.
Or when playing audio one could use audio small fragments, and derive the timing
from it.

Benno.

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



This archive was generated by hypermail 2b29 : Tue Feb 15 2000 - 21:00:13 EST