Re: [PATCH] sched - Implement priority and fifo support for SCHED_ISO

["Jack O'Quin" <joq@io.com>]

> Jack O'Quin wrote:
>> The corrected version works noticeably better, but still nowhere near
>> as well as SCHED_FIFO.  The first run had a cluster of really bad
>> xruns.  The second and third were much better, but still with numerous
>> small xruns.
>>
>>   http://www.joq.us/jack/benchmarks/sched-iso-fix/
>>
>> With a compile running in the background it was a complete failure.
>> Some kind of big xrun storm triggered a collapse on every attempt.
>>
>>   http://www.joq.us/jack/benchmarks/sched-iso-fix+compile/
>>
>> The summary statistics are mixed.  The delay_max is noticeably better
>> than before, but still much worse than SCHED_FIFO.  But, the xruns are
>> really bad news...

Con Kolivas <kernel@kolivas.org> writes:
> Believe it or not these look like good results to me. Your XRUNS are
> happening when the DSP load is >70% which is the iso_cpu % cutoff. Try
> setting the iso_cpu to 90%
>
> echo 90 > /proc/sys/kernel/iso_cpu

I ran them again with that setting.  But, don't forget the large
number of xruns before, even running without the compiles in the
background.  There are still way too many of those, although the third
run was clean.  If you can get them all to work like that, we'll
really have something.

  http://www.joq.us/jack/benchmarks/sched-iso-fix.90

With a compile running in the background, the entire run did not fail
completely as it had at 70%.  But there are still way too many xruns.

  http://www.joq.us/jack/benchmarks/sched-iso-fix.90+compile

I moved a bunch of directories testing older prototypes to a .old
subdirectory, they no longer clutter up the summary statistics.

  http://www.joq.us/jack/benchmarks/.SUMMARY

The fact that the results did improve with the 90% setting suggests
that there may be a bug in your throttling or time accounting.  The
DSP load for this test should hover around 50% when things are working
properly.  It should never hit a 70% limit, not even momentarily.  The
background compile should not affect that, either.

Something seems to be causing scheduling delays when the sound card
interrupt causes jackd to become runnable.  Ingo's nice(-20) patches
seem to have the same problem, but his RLIMIT_RT_CPU version does not.

This is still not working well enough for JACK users.  Long and
variable trigger latencies after hardware interrupts are deadly to any
serious realtime application.
-- 
  joq