* Jack O'Quin <[EMAIL PROTECTED]> wrote:
> > It would be very interesting to see how jackd/jack_test performs with
> > this patch applied, and rt_cpu_limit is set to different percentages,
> > compared against unpatched SCHED_FIFO performance.
>
> It works great...
>
> http://www.joq.us/jack/benchmarks/rt_cpu_limit
> http://www.joq.us/jack/benchmarks/rt_cpu_limit+compile
> http://www.joq.us/jack/benchmarks/.SUMMARY
>
> I'll experiment with it some more, but this seems to meet all my
> needs. As one would expect, the results are indistinguishable from
> SCHED_FIFO...
>
> # rt_cpu_limit
> Delay Maximum . . . . . . . . : 290 usecs
> Delay Maximum . . . . . . . . : 443 usecs
> Delay Maximum . . . . . . . . : 232 usecs
>
> # rt_cpu_limit+compile
> Delay Maximum . . . . . . . . : 378 usecs
> Delay Maximum . . . . . . . . : 206 usecs
> Delay Maximum . . . . . . . . : 528 usecs
very good. Could you try another thing, and set the rt_cpu_limit to less
than the CPU utilization 'top' reports during the test (or to less than
the DSP CPU utilization in the stats), to deliberately trigger the
limiting code? This both tests the limit and shows the effects it has.
(there should be xruns and a large Delay Maximum.)
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
