[lkml]   [2000]   [Feb]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: latest 'guaranteed low latency' patch against 2.2.14
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
> ( 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.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:56    [W:0.042 / U:2.964 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site