Rui Nuno Capela wrote:
>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
>
A question here about Mdk 10.1 {a tad OT}...
I'm under the impression that there are issues preventing the use of
newer 2.6 kernels with 10.1 because they break stuff. It seems not as
you are using this kernel.
I don't have the time or really the skillset to build kernels
efficiently and I rely heavily on Thac's RPM's for my production box.
But I'm faced with a bit of a mild dilemna; Thac is not supporting the
10.0 RPMs and there have been many upgrades. But I cannot seem to get
the 2.6.7 mm.7 kernels to boot on my test box running 10.1 official. And
If I cant have a RT kernel to use, my production box is gathering
cobwebs. I don't need zero Xruns at 32x2. I just need reliable RT
performance with modest latency...I mean damn...I can go mess with my
Winblows machine to remember what latency blessings we have in Linux
audio! :) And I can always just hide the Qjackctl window; I'm convinced
that sometimes just seeing the "Xrun monitor" numbers turn red causes
some folks to tip the box over and start again with a fresh reinstall!
If I'm prepared to wear my sox 2 days in a row then I can live with some
red numbers. :) Dropouts are unacceptable not Xruns.
R~
>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.
>
>
