[linux-audio-user] Re: [Jackit-devel] 2.6.10

Rui Nuno Capela rncbc at rncbc.org
Thu Dec 30 11:16:29 EST 2004


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 at rncbc.org




More information about the Linux-audio-user mailing list