Con Kolivas wrote:
Comments and testing welcome.
There's a collection of test summaries from jack_test3.2 runs at <http://www.graggrag.com/ck-tests/ck-tests-0501182249.txt>
Tests were run with iso_cpu at 70, 90, 99, 100, each test was run twice. The discrepancies between consecutive runs (with same parameters) is puzzling. Also recorded were tests with SCHED_FIFO and SCHED_RR.
Before drawing any hardball conclusions, verification of the results would be nice. At first glance, it does seem that we still have that fateful gap between "harm minimisation" (policy) and "zero tolerance" (audio reality requirement).
Thanks.
SCHED_ISO /proc/sys/kernel/iso_cpu . . .: 70 /proc/sys/kernel/iso_period . : 5 XRUN Count . . . . . . . . . : 110
vs
SCHED_FIFO XRUN Count . . . . . . . . . : 114 XRUN Count . . . . . . . . . : 187
vs
SCHED_RR XRUN Count . . . . . . . . . : 0 XRUN Count . . . . . . . . . : 0
Something funny going on here... You had more xruns with SCHED_FIFO than the default SCHED_ISO settings, and had none with SCHED_RR. Even in the absence of the SCHED_ISO results, the other results dont make a lot of sense.
Con
P.S. If you're running on SMP it may be worth booting on UP or using cpu affinity (schedtool -a 0x1 will bind you to 1st cpu only) and see what effect that is having. There are some interesting things that can adversely affect latency on SMP.
signature.asc
Description: OpenPGP digital signature