11 Oct
2011
11 Oct
'11
6:33 p.m.
On 10/11/2011 01:52 AM, Clemens Ladisch wrote:
I wrote:
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
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.