Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-19

From: Rui Nuno Capela
Date: Thu Dec 02 2004 - 08:02:34 EST


>
> Next step is really trying to increase the stress and look after when it
> will break apart. It will not take too long...
>
> First attempts, by just increasing the client count from 16 to 20, are
> leading to what will be the next "horror show" :) CPU tops above 90%, and
> after a couple of minutes running steadly it enters into some kind of
> turbulence and hangs. Yeah, it just freezes completely.
>
> So I guess we're having a lot more food to mangle ;)
>

After a bit of investigation, I've found some evidence that the "horror
show" is primarily due to XRUN fprintf stderr storm. If I simply remove
that fprintf line from jack/drivers/alsa/alsa_driver.c (around line 1084),
I can run more than 20 jack_test3_client's without hosing the system.

Most probably, the main issue is about fprintf(stderr) being called in a
RT thread context. This is a jackd issue, not of RT kernel's. I remember
there's a jack patch, somewhere in the limbo, for queing all printable
messages out of the jackd RT threads.

I think I'm urging for that patch right now, even though I'm probably
pushing all this pressure into real/physical/hard limits ;) OK. I'll look
if I can take that back from the jackit-devel archives and see what I can
do about it.


Back to a latency-trace enabled RT-0V0.7.31-19, and a patched jackd
0.99.17cvs, I've trapped some more traces (on attachment). These were
taken while running some jack_test3 with light stress (10~12 clients, 4
ports each).

Bye now.
--
rncbc aka Rui Nuno Capela
rncbc@xxxxxxxxx

Attachment: xruntrace1-2.6.10-rc2-mm3-RT-V0.7.31-19-20041202095337.trc.gz
Description: application/gzip-compressed

Attachment: xruntrace1-2.6.10-rc2-mm3-RT-V0.7.31-19-20041202100140.trc.gz
Description: application/gzip-compressed

Attachment: xruntrace1-2.6.10-rc2-mm3-RT-V0.7.31-19-20041202101633.trc.gz
Description: application/gzip-compressed