30 Dec
2004
30 Dec
'04
12:16 p.m.
Jack O'Quin wrote:
Here are my results running vanilla 2.6.10. They support your
conclusion, but also the idea that the vanilla kernel is really quite
usable.
Not sure what system statistics we should collect for this. My system
is Debian woody with 2.6.10 and realtime-lsm on an Athlon 1800+ XP
with 256MB main memory and M-Audio Delta-66 sound card.
Something worth telling, in deed: my laptop's Mandrake 10.1 and all my
tests were taken while on a perfectly usual X desktop session (KDE 3.2),
bringing more merit to the RT patch performance. Another note goes to my
custom jackit-0.99.41.10cvs installation: it includes an additional
max_delayed_usecs-histogram patch (also derived from the Lee's original).
Without this modification the result lines that read "Delay Count (>1000
usecs)" are pretty a no-op. Just ignore those, anyway.
Oh, and another important thingie: being it a laptop, it has ACPI support
set on by default. If ACPI is switched off, I'll surely read fewer XRUNs
under vanilla 2.6.10, quite as fewer as yours, but then I will miss some
system monitor goodies (e.g battery status, temperature, etc.).
Incidentally, Ingo has also solved this ACPI latency issue, and that just
makes yet another chalkmark for the RT patch ;)
I imagine that long 10 msec xrun delay probably
occurred during the
graph sort after one of the clients disconnected. If so, that's more
of a JACK implementation artifact than a kernel or system problem.
************* SUMMARY RESULT ****************
Total seconds ran . . . . . . : 300
Number of clients . . . . . . : 20
Ports per client . . . . . . : 4
Frames per buffer . . . . . . : 64
*********************************************
Timeout Count . . . . . . . . :( 1)
XRUN Count . . . . . . . . . : 2
Delay Count (>spare time) . . : 0
Delay Count (>1000 usecs) . . : 0
Delay Maximum . . . . . . . . : 10258 usecs
Cycle Maximum . . . . . . . . : 825 usecs
Average DSP Load. . . . . . . : 32.4 %
Average CPU System Load . . . : 7.3 %
Average CPU User Load . . . . : 24.1 %
Average CPU Nice Load . . . . : 0.0 %
Average CPU I/O Wait Load . . : 1.4 %
Average CPU IRQ Load . . . . : 0.7 %
Average CPU Soft-IRQ Load . . : 0.0 %
Average Interrupt Rate . . . : 1689.4 /sec
Average Context-Switch Rate . : 11771.0 /sec
*********************************************
Hmmm... Now I notice that there was at least one Timeout occurrence. Check
the output log/chart. In my own experience, when this happens the results
are pretty skewed right after that timeout moment. Something about clients
being kicked out from the chain, maybe? Anyway, I believe the only trusty
results are the ones with 0 (zero) timeouts.
Very nice test, BTW.
I had to hack it a bit to work on my system (mainly due to an old GCC
2.95.4 compiler). I would love to include some version of this as a
`make test' option with the JACK distribution.
Glad you find it useful. Feel free to it. But take a note that the
included jack_test_nmeter.c is a minor change from nmeter.c, handed to me
by Denis Vlasenko on the LKML.
Bye now, and thanks.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org