[LAD] Kontakt Spikes

[Michael Ost]

On 10/11/2011 01:52 AM, Clemens Ladisch wrote:
> I wrote:
>> What is the time quantum that sched_rr_get_interval() returns for these
>> threads?
>
> Bah, the documentation of sched_rr_get_interval() is wrong; the kernel
> uses a fixed RR time quantum of 100 ms which cannot be changed (except
> by changing DEF_TIMESLICE in kernel/sched.c).
>
> This means that, when you have five RR/50 threads on one core, a thread
> will run for 100 ms and then be interrupted for 400 ms.  The only way
> for the threads to user shorter intervals is for all of them to
> cooperate and to call sched_yield() after having completed such
> an interval.

In our case this won't be an issue. We are really only using multiple 
threads so multiple cores can be used at the same time; not to divvy up 
a lengthy task, which is the normal use for threading. The fact that 
there are five realtime threads in our example is not a design decision, 
but only an unfortunate and unavoidable side-effect of how Receptor's 
and Kontakt's multi core modes work.

All the realtime threads need to complete their work within the audio 
quantum (2.9 msecs in this case) or there will be drop outs. If any of 
the threads actually needed 100ms, playback will be so messed up and the 
cpu will be so overloaded they would probably have to hard-power off!

We have gotten some interesting results from cyclictest and the new 
ftrace system. Hopefully that will point us to some kernel latency that 
we can work around or fix.

Thanks... mo