Re: [PATCH][RFC] sched: Isochronous class for unprivileged soft rt scheduling

[Con Kolivas <kernel@kolivas.org>]

Jack O'Quin wrote:
> Try again with JACK 0.99.48.  It's in CVS now, but you probably need
> this tarball to get around the dreaded SourceForge anon CVS lag...
> 
>    http://www.joq.us/jack/tarballs/jack-audio-connection-kit-0.99.48.tar.gz

Thanks it finally ran to completion. By the way the patch you sent with 
the test suite did not apply so I had to do it manually (booraroom..)

> The results I get with these versions are a lot more stable.  But,
> there are still some puzzles about the scheduling.  Do you distinguish
> different SCHED_ISO priorities?  

It was not clear whether that would be required or not. This is why 
testing is so critical because if you are having latency issues it 
wouldn't be a problem of getting cpu time since your cpu usage is well 
below the 70% limit.

> 
> JACK runs with three different SCHED_FIFO priorities:
> 
>   (1) The main jackd audio thread uses the -P parameter.  The JACK
>   default is 10, but Rui's script sets it with -P60.  I don't think
>   the absolute value matters, but the value relative to the other JACK
>   realtime threads probably does.
> 
>   (2) The clients' process threads run at a priority one less (59).
> 
>   (3) The watchdog timer thread runs at a priority 10 greater (70).
> 
>   (4) LinuxThreads creates a manager thread in each process running
>   one level higher than the highest user realtime thread priority.

Since I (finally) have it running at this end at last I'll do some 
benchmarking of my own to see how (lack of) priorities affects 
SCHED_ISO. If it is inadequate, it wont be too difficult to add them to 
the design. The problem with priorities is that once you go over the cpu 
limit everyone suffers equally; but that's a failsafe that you shouldn't 
actually hit in normal usage so it probably doesn't matter... Hmm come 
to think of it, it probably _is_ a good idea to implement priority 
support afterall.

Cheers,
Con