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

torbenh torbenh at gmx.de
Fri Nov 19 12:13:39 UTC 2010


On Thu, Nov 18, 2010 at 11:17:29PM +0100, Robert Jonsson wrote:
> Hi Torben,
> 
> 2010/11/18 torbenh <torbenh at gmx.de>:
> >
> > 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.
> 
> Being a long time jack user, mainly for recording purposes, I thought
> I would speak up about my experiences.
> I have always felt the unforgiving defaults of jack are very hard to
> work with. When in the middle of a recording session, especially a
> longer one, the last thing I want to happen is that jack kicks me.

right. nobody wants that.
however without kicking, there might be other things happening,
(highly unlikely, but they may occur, which is broken sound, due to an
extra execution token floating through the chain.
it might increase cpu load... and desync clients.

the new code is a lot more relaxed, when it comes to kicking clients.

> It's quite alright to note the problem. Even if an xrun has occured it
> can often be salvaged.
> These days I always use -Z and -t to make jack cut me some slack.

hmm... using -Z AND -t seems pretty excessive.
i mean if a client causes a timeout of a whole second, jack should
really kick it.

do you get zombifications with say -t 1000 ?
theoretically -Z only makes sense if you dont specify -t.

the disadvantage of -t is that if one client crashes, you really get
silence until that timeout is up.
without -t i basically cant even hear a client crash while playing a
music stream.



> 
> Also, to be able to safely decide if an app has broken it's RT
> promise, don't you also need to be sure the kernel has kept it's part?
> Which in my experience has gotten better but isn't always true,
> especially with some hardware configurations.

indeed.
my view might be colored by having well behaving hardware and an
rt-kernel.

> 
> The one reason I see to let jack interfere is as you note, to avoid
> lockups. Though if jack can detect this, leave it for a while (several
> seconds) before doing anything about it.

a cpu overload situation also sounds ugly.
but the user might be surprised by jack suspending the processing.
the time after which the -C option shuts the processing down is
configurable, so if you like several seconds, you can have em.

i found it to be a nice transition... audio begins to stutter, and shuts
down after a few ms. i can quickly kill the offending client, and
operation resumes.

> 
> Just my thoughts,
> Robert
> _______________________________________________
> Linux-audio-user mailing list
> Linux-audio-user at lists.linuxaudio.org
> http://lists.linuxaudio.org/listinfo/linux-audio-user

-- 
torben Hohn


More information about the Linux-audio-user mailing list