30 Dec
2004
30 Dec
'04
7:28 p.m.
Rui Nuno Capela wrote:
Jack O'Quin wrote:
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~
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.