[LAT] [LAU] Are RT-patches needed anymore? (Was Re: >= 2.6.27 RT ETA?)

[dieeasy]

Il giorno Tue, 03 Feb 2009 10:11:20 -0800
Fernando Lopez-Lezcano <nando at ccrma.Stanford.EDU> ha scritto:

> > - what's the difference between running some app realtime, say
> >   "jackd -R", as opposed to "chrt -r" that same app?[3]  
> 
> Jack will give SCHED_FIFO to just the audio thread of the client
> application (which is normally the only one that actually needs
> that). 
>   
> > - how can I identify the audio thread and change scheduling/nice
> >   priority of that single thread?  
> 
> I don't think you can. You can see the threads and their pids
> in /proc/PID/task/ but you don't know which is which. They are just
> numbers. 
> 
> I pays to have jack applications that are properly designed. Then you
> don't have to worry about scheduling and priorities (in a properly
> configured system). 
>   
> > - given audio threads already are highest priority, isn't it better
> > to also schedule SCHED_RR all audio processes (with lower priority
> > than jackd and other audio threads) so no other process can eat cpu
> > time up?  
> 
> Audio threads should be the only ones that need realtime scheduling.
> What do you mean by "all audio processes"?  

What I meant there was (if I got how it works right):
 - jackd already manages audio thread priority, which get SCHED_FIFO
   and therefore can preempt every other process/thread in the system
 - all other processes are sheduled SCHED_OTHER with various nice levels

So, isn't it better to schedule SCHED_RR audio processes (say lmms,
hydrogen and zynaddsubfx) so a cronjob, xorg, daemons and such can't
possibly preempt audio processes?
I think such a situation (i.e. a cronjob preempting zynaddsubfx)
would not give you xruns, but it could lead to audio dropouts
(zynaddsubfx not having time to process audio), which is as bad as xruns
'cause you lose your sound.
Same goes for any other setup in which some apps aren't connected to
jack or properly designed.

> SCHED_RR will be preempted when it uses up its time slice. That
> prevents lockups but it means you could get an xrun anyway.  

I imagine this scenario being very close to the machine not having
enough power to fulfill the requested tasks.
If a round robin across all audio threads gives xruns a fifo on jackd's
audio thread would leave other ones with no cpu time left, I guess.

> > - apart from irq threads, is there any other big improvement a -rt
> >   kernel gives over "vanilla"[4] ones?  
> 
> The time kernel system calls spend in a non-preemptible state are
> supposed to be lower than in a stock kernel (but the gap has been
> getting narrower). That means that a process that is ready to run and
> has SCHED_FIFO has a better chance of being scheduled in time, in the
> stock kernel there could be delays in scheduling that cause the
> process to be scheduled too late... (and you get an xrun)
>   
> > - does enabling "preempt RCU" make a big difference?  
> 
> I have no idea...
>
> [...]
>  
> > [4] I use "stock" debian kernels reconfigured with forced
> >     preemption (low-latency desktop) and 300Hz timer and get pretty
> > low latency (1.5ms) with no xruns at all even under heavy desktop
> > usage  
> 
> Latest kernels are known to be pretty good without the rt patch. Is
> this 2.6.28.*?   

Yep, I run 2.6.28.

Thank for your reply, I've made my mind clearer on some interesting
points now.


bye,
Nicola.