Re: [LAU] [Jack-Devel] zombification behaviour...

I use jack2 on a uniprocessor system. I either don't use a lot of jack
clients (compared to many LAU folk, probably true) or the ones I use are
all well-behaving JACK clients. Haven't had it get more than maybe 8%
CPU usage.

torbenh wrote:
> hi... i thought i take this to lau to get an impression on users
> feelings.
>
> here is the story. i basically wanted to improve the heuristics for
> client zombification. i wanted jack to only kick clients which take a
> whole cpu slice. the result would be that you can overload the cpu
> with well behaving clients, and jack would not act on it.
>
> the result in a synchronous jackd (jackd1/tschack or jackd2 -S)
> would be continuous xruns, and probably bad noise.
>
> the problem is that its not 100% possible to identify the bad client,
> and its always possible, that we might kick an inocent client.
>
> so many people on jack-dev advocate not kicking any client (this is what
> jack2 does) jack2 users probably have an SMP system, so jack RT load at
> 100% doesnt mean their system is unresponsive.
>
> for UP users it might make sense to stop processing after a continous
> series of timeouts, so that the user can fix things up.
>
>
>
> On Wed, Nov 17, 2010 at 02:50:02PM -0500, Paul Davis wrote:
>> [ ... ]
>>
>> there are really 3 possible policies:
>>
>> 1) ignore all client behaviour (jack2)
>> 2) try to zombify the misbehaving client(s) (jack1)
>> 3) stop running the process() cycle if there is misbehaviour, and
>> restart whenever
>> the graph is rechained (indicating that a client has been removed, or
>> added, or connections where changed)
>>
>> torben has been experimenting with an improved version of (2) and with (3)
>
> my argumentation is that if i make the rules for (2) less agressive,
> jack might not act up when you overload the cpu.
> so i would basically like to protect the user by implementing (3)
>
> after testing the overload situation i think the noise is not so bad.
> and i would probably prefer this over silence, if i was on stage.
>
> but UP people might want their cpu freed so they can fix the situation
> quickly.
>
>> _______________________________________________
>> Jack-Devel mailing list
>> Jack-Devel@email-addr-hidden
>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>

-- 
David
gnome@email-addr-hidden
authenticity, honesty, community
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user