On Thursday 14 August 2003 00.09, Joshua Haberman wrote:
I am distressed. It was my understanding that the
2.5/2.6 kernel branch
was undergoing significant scheduler and latency work, and that 2.6
would eliminate the kernel from the list of obstacles of low-latency on
Linux. It will have the preemptable kernel patch, the new scheduler,
and all of Ingo Molnar's low-latency work. Claims were being thrown
around that 2.6 would be the lowest-latency operating system on the planet.
So how is it that we're in the 2.6.0-test series and people are
complaining about audio skipping in **XMMS**, which uses three second
buffers by default?? If people are getting skips from high-latency
playback, what hope is there for low-latency audio? A series of patches
are coming from both Ingo and Con Kolivas attempting to address this,
but the fact they are just now throwing around potential solutions
erodes at my faith that they really understand the problem or how to
solve it.
Is 2.6.x going to be suitable for low-latency (or even reliable
high-latency) audio? Or is it going to be more of the same: patching
the kernel, tweaking parameters, reading magical incantations, and
hoping for the best?
Reassure me please!
Josh
This is when running the default scheduler (as non root / non suid root).
Then you are not allowed to use SCHED_FIFO nor SCHED_RR
The problem such a process might run into is if it needs service or
a resource held by a blocked process...
BTW
There have been discussions about a new scheduling class
SCHED_SOFTRR. It would be available for all users.
But the total usage would be limited.
If SCHED_SOFTRR were overused those processes would run
out of their timeslice (SCHED_RR never runs out of their timeslice)
I think this feature would be pretty cool! And adding this for
latency sensitive bandwith limited streaming applications could
simplify lots of stuff for the default scheduler...
/RogerL
--
Roger Larsson
SkellefteƄ
Sweden