18 Nov
2010
18 Nov
'10
3:42 p.m.
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(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
--
torben Hohn
18 Nov
18 Nov
8:40 p.m.
New subject: [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:
--
David
gnome(a)hawaii.rr.com
authenticity, honesty, community
[ ... ]
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(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
8:50 p.m.
New subject: [Jack-Devel] zombification behaviour...
Torben, a few questions.
1. Is the uncertainty over knowing which client is the offender a
result of the client's jack code being less than optimal? (no offence
to coders)
2.) Can jack, if advisable, take a bit of extra code to more clearly
define which client is the offender?
3.) Would a more robust client ID system solve the challenge of jack
knowing 100% which client is the offender? i.e. Ardour is 001,
jconvolver is 002, etc...... (I imply with this a central list at
jackaudio. org, where jack capable clients are listed, and any coder
that builds a jack app "officially" registers their app, and gets an
app specific ID.)
These questions are based on jack1, which i use.
Alex.
--
www.openoctave.org
midi-subscribe(a)openoctave.org
development-subscribe(a)openoctave.org
9:04 p.m.
New subject: [Jack-Devel] zombification behaviour...
On Thu, Nov 18, 2010 at 2:50 PM, alex stone <compose59(a)gmail.com> wrote:
Torben, a few questions.
1. Is the uncertainty over knowing which client is the offender a
result of the client's jack code being less than optimal? (no offence
to coders)
not really.
there are 2 scenarios that can cause confusion:
1) several clients, none of which is really bad by itself, but they
all contribute to excess CPU load
2) errors by the kernel scheduler that make a particular client
look bad, when its really not
torben has done some work to reduce the impact of both of these, and
in all honest (2) is an issue that JACK can't really solve.
the first case is reduced by forcing a "bad client" to be one that on
its own takes more than an entire JACK period to execute.
3.) Would a more robust client ID system solve the
challenge of jack
knowing 100% which client is the offender?
no, this problem is unaffected by the type of "identifier" used for the
clients.
9:13 p.m.
New subject: [Jack-Devel] zombification behaviour...
Am Donnerstag, den 18.11.2010, 22:50 +0300 schrieb alex stone:
Torben, a few questions.
1. Is the uncertainty over knowing which client is the offender a
result of the client's jack code being less than optimal? (no offence
to coders)
2.) Can jack, if advisable, take a bit of extra code to more clearly
define which client is the offender?
Jack apps could/need measure there own needed time per circle and
forward this information to jack if jack ask for it, may when CPU load
become to heavy, to give jack the possibility to decide witch one is the
ops.
3.) Would a more robust client ID system solve the challenge of jack
knowing 100% which client is the offender? i.e. Ardour is 001,
jconvolver is 002, etc...... (I imply with this a central list at
jackaudio. org, where jack capable clients are listed, and any coder
that builds a jack app "officially" registers their app, and gets an
app specific ID.)
These questions are based on jack1, which i use.
Alex.
9:21 p.m.
New subject: [Jack-Devel] zombification behaviour...
On Thu, Nov 18, 2010 at 3:12 PM, hermann <brummer-(a)web.de> wrote:
Jack apps could/need measure there own needed time per
circle and
forward this information to jack if jack ask for it, may when CPU load
become to heavy, to give jack the possibility to decide witch one is the
ops.
the server already has this information.
19 Nov
19 Nov
11:31 p.m.
New subject: [Jack-Devel] zombification behaviour...
On Thu, Nov 18, 2010 at 09:12:14PM +0100, hermann wrote:
Am Donnerstag, den 18.11.2010, 22:50 +0300 schrieb
alex stone:
Whenever these questions come up, I always find myself singing this:
http://www.youtube.com/watch?v=iBgewcFh-cg
-ken
Torben, a few questions.
1. Is the uncertainty over knowing which client is the offender a
result of the client's jack code being less than optimal? (no offence
to coders)
2.) Can jack, if advisable, take a bit of extra code to more clearly
define which client is the offender?
Jack apps could/need measure there own needed time per circle and
forward this information to jack if jack ask for it, may when CPU load
become to heavy, to give jack the possibility to decide witch one is the
ops.
>
> 3.) Would a more robust client ID system solve the challenge of jack
> knowing 100% which client is the offender? i.e. Ardour is 001,
> jconvolver is 002, etc...... (I imply with this a central list at
> jackaudio. org, where jack capable clients are listed, and any coder
> that builds a jack app "officially" registers their app, and gets an
> app specific ID.)
>
> These questions are based on jack1, which i use.
> 
20 Nov
20 Nov
1:30 p.m.
New subject: [Jack-Devel] zombification behaviour...
On 19/11/2010, Ken Restivo <ken(a)restivo.org> wrote:
Whenever these questions come up, I always find myself
singing this:
http://www.youtube.com/watch?v=iBgewcFh-cg
For me it's more this:
http://www.youtube.com/watch?v=HF4cZsaRin8
18 Nov
18 Nov
11:17 p.m.
New subject: [Jack-Devel] zombification behaviour...
Hi Torben,
2010/11/18 torbenh <torbenh(a)gmx.de>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.
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.
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.
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.
Just my thoughts,
Robert
19 Nov
19 Nov
1:13 p.m.
New subject: [Jack-Devel] zombification behaviour...
On Thu, Nov 18, 2010 at 11:17:29PM +0100, Robert Jonsson wrote:
Hi Torben,
2010/11/18 torbenh <torbenh(a)gmx.de>de>:
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.
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. 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(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
--
torben Hohn
23 Nov
23 Nov
9:21 a.m.
New subject: [Jack-Devel] zombification behaviour...
2010/11/19 torbenh <torbenh(a)gmx.de>de>:
On Thu, Nov 18, 2010 at 11:17:29PM +0100, Robert
Jonsson wrote:
It was several years ago I settled on these arguments, memory fails me somewhat.
Tt one point my machine needed this to survive certain operations,
probably disk intensive operations, loading / saving large projects.
The RT performance I have today is much better so I'm not entirely
sure if I need both.
Another thing is coping with bad plugins, I just lots and sometimes I
encounter denormal issues. This is on a dual core machine so the gui
is still workable so with the settings I use I mostly have time to
disable the plugin before anything worse happens.
Regards,
Robert
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.
4914
days inactive
4919
days old
linux-audio-user@lists.linuxaudio.org
10 comments
8 participants
participants (8)
-
alex stone -
david -
Gwenhwyfaer -
hermann -
Ken Restivo -
Paul Davis -
Robert Jonsson -
torbenh