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@xxxxxxxxxxxxxxxxxxx > http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org -- torben Hohn _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
