Messages in this thread | | | Date | Thu, 2 Dec 2004 12:59:41 -0000 (WET) | Subject | Re: [patch] Real-Time Preemption, -RT-2.6.10-rc2-mm3-V0.7.31-19 | From | "Rui Nuno Capela" <> |
| |
> > 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@rncbc.org [unhandled content-type:application/x-gzip-compressed][unhandled content-type:application/x-gzip-compressed][unhandled content-type:application/x-gzip-compressed] | |