Cal <[EMAIL PROTECTED]> writes: > 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.
It's probably suffering from some of the same problems of thread granularity we saw running nice --20. It looks like you used schedtool to start jackd. IIUC, that will cause all jackd processes to run in the specified scheduling class. JACK is carefully written not to do that. Did you also use schedtool to start all the clients? I think your puzzling discrepancies are probably due to interference from non-realtime JACK threads running at elevated priority. > 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). I still have not found time to run Con's latest version. I've been too busy trying to hack JACK into working with nice(-20), which has turned out to be quite difficult. The interfaces we need don't work, and the ones that do are not what we need. :-( I believe Con's latest sched patch should work fine with the normal jack_test3.2 using the -R option of jackd. That should produce more consistent results. -- joq - 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/