zombification behaviour...

classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

zombification behaviour...

torbenh

hi...

i am trying to fix jack1 zombification behaviour now.
as fons already noted, i think its valid to zombify a client, that
spent more than period_usecs in its process_cb.

if we apply this rule, jack would not kick anyone, when 2 clients eat
75% of the RT timeslice each. not kicking anybody in this case seems
correct.

but we should do somthing in this case. because the audio would end up
stuttering and jackd would continously xrun.

so basically we should stop executing the process cycle, when it failed
to finish intime, for ~10 cycles.
we should retry executing when "something" changed.

would be nice to have a prominent notification for the user in this
case. but i still think its better to go silent, than continously
stuttering.

other opinions please ?

--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

Stéphane Letz

Le 17 nov. 2010 à 17:49, torbenh a écrit :

>
> hi...
>
> i am trying to fix jack1 zombification behaviour now.
> as fons already noted, i think its valid to zombify a client, that
> spent more than period_usecs in its process_cb.

On OSX we regularly have this issue when new clients launch, since memory usually cannot be pinned. First cycle possibly warms data and code. So... ?

>
> if we apply this rule, jack would not kick anyone, when 2 clients eat
> 75% of the RT timeslice each. not kicking anybody in this case seems
> correct.
>
> but we should do somthing in this case. because the audio would end up
> stuttering and jackd would continously xrun.

Let the *user* decide?

>
> so basically we should stop executing the process cycle, when it failed
> to finish intime, for ~10 cycles.

I suggest using exactly 3,141592653 cycles...


> we should retry executing when "something" changed.

Define "something" (in any sensible way)

>
> would be nice to have a prominent notification for the user in this
> case. but i still think its better to go silent, than continously
> stuttering.
>
> other opinions please ?
>

Sorry to be a bit ironic, but this never ending discussion about those corner cases makes me feel sick. Almost 10 years after jack first design, it seems that there is still no sensible way to take the right decision. So my opinion is : don't do that at jack server level. If a user wants to protect against RT thread locking the machine, then das-watchdog kind of program can be used.

(And anyway OSX has a RT thread locking protection scheme that just do something similar to das-watchdog...)

Stéphane

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

Fons Adriaensen-2
On Wed, Nov 17, 2010 at 06:40:06PM +0100, Stéphane Letz wrote:

> Let the *user* decide?

Yes.

> I suggest using exactly 3,141592653 cycles...

You probably meant 3.141592654 (when rounding to nearest :-)
 
> Sorry to be a bit ironic, but this never ending discussion
> about those corner cases makes me feel sick. Almost 10 years
> after jack first design, it seems that there is still no sensible
> way to take the right decision. So my opinion is : don't do that
> at jack server level. If a user wants to protect against RT thread
> locking the machine, then das-watchdog kind of program can be used.

I wouldn't mind if a client that _obviously_ misbehaves (taking more
than few cycles) gets kicked out. Anything else should just be allowed
to happen, actions like waiting for a number of cycles are probably
going to make things worse, and only the user can decided what to do
next.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

Paul Davis
On Wed, Nov 17, 2010 at 1:29 PM,  <[hidden email]> wrote:

> I wouldn't mind if a client that _obviously_ misbehaves (taking more
> than few cycles) gets kicked out. Anything else should just be allowed
> to happen, actions like waiting for a number of cycles are probably
> going to make things worse, and only the user can decided what to do
> next.

the problem is that there is no reliable back-channel to the user to
tell them that anything is wrong.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

torbenh
In reply to this post by Stéphane Letz
On Wed, Nov 17, 2010 at 06:40:06PM +0100, Stéphane Letz wrote:

>
> Le 17 nov. 2010 à 17:49, torbenh a écrit :
>
> >
> > hi...
> >
> > i am trying to fix jack1 zombification behaviour now.
> > as fons already noted, i think its valid to zombify a client, that
> > spent more than period_usecs in its process_cb.
>
> On OSX we regularly have this issue when new clients launch, since memory usually cannot be pinned. First cycle possibly warms data and code. So... ?

not do it on first cycle ?
maybe. i dont really care for osx anyways.
(and jack1 doesnt check the timouts on osx anyways, i think)

that osx doesnt support proper memlocking does not justify that
we should be forgiving on linux.
however i still feel, that mlockall() doesnt guarantee all pages to be
mapped right away.



>
> >
> > if we apply this rule, jack would not kick anyone, when 2 clients eat
> > 75% of the RT timeslice each. not kicking anybody in this case seems
> > correct.
> >
> > but we should do somthing in this case. because the audio would end up
> > stuttering and jackd would continously xrun.
>
> Let the *user* decide?

how should the user decide ?
in case of a user decision, we still need to implement both choices.
i dont care for the defaults.
i only care for choices.





>
>
> > we should retry executing when "something" changed.
>
> Define "something" (in any sensible way)

client got deleted, port got removed ?

graph_rechained in my current implementation.

>
> >
> > would be nice to have a prominent notification for the user in this
> > case. but i still think its better to go silent, than continously
> > stuttering.
> >
> > other opinions please ?
> >
>
> Sorry to be a bit ironic, but this never ending discussion about those corner cases makes me feel sick. Almost 10 years after jack first design, it seems that there is still no sensible way to take the right decision. So my opinion is : don't do that at jack server level. If a user wants to protect against RT thread locking the machine, then das-watchdog kind of program can be used.
>
> (And anyway OSX has a RT thread locking protection scheme that just do something similar to das-watchdog...)

linux has RT thread locking protection, which doesnt even kill stuff.


>
> Stéphane
>

--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

torbenh
In reply to this post by Fons Adriaensen-2
On Wed, Nov 17, 2010 at 07:29:06PM +0100, [hidden email] wrote:
> On Wed, Nov 17, 2010 at 06:40:06PM +0100, Stéphane Letz wrote:
>
> > Let the *user* decide?
>
> Yes.

can you elaborate on this ?
what shall jackd do when i start too many clients, and overload the CPU
?

shall it ask the user whether it should go stuttering or should it stay
silent ?
and during the question what should happen ?

>
> > I suggest using exactly 3,141592653 cycles...
>
> You probably meant 3.141592654 (when rounding to nearest :-)
>  
> > Sorry to be a bit ironic, but this never ending discussion
> > about those corner cases makes me feel sick. Almost 10 years

programming is about corner cases.

> > after jack first design, it seems that there is still no sensible
> > way to take the right decision. So my opinion is : don't do that
> > at jack server level. If a user wants to protect against RT thread
> > locking the machine, then das-watchdog kind of program can be used.
>
> I wouldn't mind if a client that _obviously_ misbehaves (taking more
> than few cycles) gets kicked out. Anything else should just be allowed
> to happen, actions like waiting for a number of cycles are probably
> going to make things worse, and only the user can decided what to do
> next.

the user decision is using -Z or not using it ?
i really dont understand what this discussion is about.
it not about defaults. its about what stuff to implement.

more specificly, whether i implement this in tschack or jack1...
i need to implement it anyways.


>
> Ciao,
>
> --
> FA
>
> There are three of them, and Alleline.
>

--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

Fons Adriaensen-2
In reply to this post by Paul Davis
On Wed, Nov 17, 2010 at 01:34:01PM -0500, Paul Davis wrote:

> On Wed, Nov 17, 2010 at 1:29 PM,  <[hidden email]> wrote:
>
> > I wouldn't mind if a client that _obviously_ misbehaves (taking more
> > than few cycles) gets kicked out. Anything else should just be allowed
> > to happen, actions like waiting for a number of cycles are probably
> > going to make things worse, and only the user can decided what to do
> > next.
>
> the problem is that there is no reliable back-channel to the user to
> tell them that anything is wrong.

Well... IMHO jack1 needs a second client tread. Wouldn't solve
everything, but it could help.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

Fons Adriaensen-2
In reply to this post by torbenh
On Wed, Nov 17, 2010 at 07:53:28PM +0100, torbenh wrote:
> On Wed, Nov 17, 2010 at 07:29:06PM +0100, [hidden email] wrote:
> > On Wed, Nov 17, 2010 at 06:40:06PM +0100, Stéphane Letz wrote:
> >
> > > Let the *user* decide?
> >
> > Yes.
>
> can you elaborate on this ?
> what shall jackd do when i start too many clients, and overload the CPU

Nothing but produce xruns. If that doesn't trigger the user to take
some action then there isn't a problem (for that user :-). Systems
that work unattended should monitor xruns (and other aspects of their
health).

> shall it ask the user whether it should go stuttering or should it stay
> silent ?

No.

> and during the question what should happen ?

No questions need to be asked.

> the user decision is using -Z or not using it ?
> i really dont understand what this discussion is about.
> it not about defaults. its about what stuff to implement.

I'd make the -Z behaviour the default, and remove the option.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

torbenh
On Wed, Nov 17, 2010 at 08:01:27PM +0100, [hidden email] wrote:

> On Wed, Nov 17, 2010 at 07:53:28PM +0100, torbenh wrote:
> > On Wed, Nov 17, 2010 at 07:29:06PM +0100, [hidden email] wrote:
> > > On Wed, Nov 17, 2010 at 06:40:06PM +0100, Stéphane Letz wrote:
> > >
> > > > Let the *user* decide?
> > >
> > > Yes.
> >
> > can you elaborate on this ?
> > what shall jackd do when i start too many clients, and overload the CPU
>
> Nothing but produce xruns. If that doesn't trigger the user to take
> some action then there isn't a problem (for that user :-). Systems
> that work unattended should monitor xruns (and other aspects of their
> health).
hopefully user is fast enough that his speakers dont get destroyed ;)
hmm... but this kind of signal probably doesnt do that.

>
> > shall it ask the user whether it should go stuttering or should it stay
> > silent ?
>
> No.
>
> > and during the question what should happen ?
>
> No questions need to be asked.
>
> > the user decision is using -Z or not using it ?
> > i really dont understand what this discussion is about.
> > it not about defaults. its about what stuff to implement.
>
> I'd make the -Z behaviour the default, and remove the option.
ok. my old patch is attached for the record.
i wont persue this anymore. will be some tschack option.



--
torben Hohn

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

2nz5nqi4.txt (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

Arnold Krille-3
In reply to this post by Fons Adriaensen-2
On Wednesday 17 November 2010 19:29:06 [hidden email] wrote:

> On Wed, Nov 17, 2010 at 06:40:06PM +0100, Stéphane Letz wrote:
> > Let the *user* decide?
> Yes.
> > Sorry to be a bit ironic, but this never ending discussion
> > about those corner cases makes me feel sick. Almost 10 years
> > after jack first design, it seems that there is still no sensible
> > way to take the right decision. So my opinion is : don't do that
> > at jack server level. If a user wants to protect against RT thread
> > locking the machine, then das-watchdog kind of program can be used.
> I wouldn't mind if a client that _obviously_ misbehaves (taking more
> than few cycles) gets kicked out. Anything else should just be allowed
> to happen, actions like waiting for a number of cycles are probably
> going to make things worse, and only the user can decided what to do
> next.
"Let the user decide" - Good idea! Really! System load is up the roof, cycles
are all spent in one or several processing threads going havoc, the only way
the watchdog can react is because of highest priority. And you expect the user
to get any notice (apart from non-moving mouse) and display warning-boxes and
dialogs through graphic (or text) interfaces??? You got to be kidding. (Hint:
Not all systems in use are smp systems.)

Just drop the most misbehaving clients from jack execution path to get the
system back to a somewhat normal state and when that works out, signal the
dropped clients that they might get re-added to the graph if they aren't
naughty anymore. During that they can ask the user or increase some internal
buffers or decide to opt-out or something...

> > I suggest using exactly 3,141592653 cycles...
> You probably meant 3.141592654 (when rounding to nearest :-)

More reliable for the statistics: watch the behavior for 42 cycles.

Have fun,

Arnold

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

Paul Davis
On Wed, Nov 17, 2010 at 2:33 PM, Arnold Krille <[hidden email]> 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 grap 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)
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

Fons Adriaensen-2
In reply to this post by Arnold Krille-3
On Wed, Nov 17, 2010 at 08:33:29PM +0100, Arnold Krille wrote:

> Just drop the most misbehaving clients from jack execution path to get the
> system back to a somewhat normal state and when that works out, signal the
> dropped clients that they might get re-added to the graph if they aren't
> naughty anymore. During that they can ask the user or increase some internal
> buffers or decide to opt-out or something...

Problem here is that there is no way to decide who is 'most
misbehaving' if you have 10 clients that each take between
5 and 15 percent but adding up to 101.

Apart from that, a very common situation is that clients
take say 80 % of the available time, and _something_ happens
that makes that fail (e.g. scheduling latency) once every
hour. I don't want jack to take *any* action at all in that
case. I could be doing a live recording, and having a few
xruns per hour is much less of a problem than the recording
app being thrown out.

Ciao,

--
FA

There are three of them, and Alleline.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

Arnold Krille-3
Hi,

On Wednesday 17 November 2010 22:04:16 [hidden email] wrote:
> On Wed, Nov 17, 2010 at 08:33:29PM +0100, Arnold Krille wrote:
> > Just drop the most misbehaving clients from jack execution path to get
> > the system back to a somewhat normal state and when that works out,
> > signal the dropped clients that they might get re-added to the graph if
> > they aren't naughty anymore. During that they can ask the user or
> > increase some internal buffers or decide to opt-out or something...
> Problem here is that there is no way to decide who is 'most
> misbehaving' if you have 10 clients that each take between
> 5 and 15 percent but adding up to 101.

Indeed, but as you say, it is much more common that one client misbehaves...

The watchdog should additionally watch total processing time and disable a
random client (or the one taking the most time) if the total processing time
is to long.

> Apart from that, a very common situation is that clients
> take say 80 % of the available time, and _something_ happens
> that makes that fail (e.g. scheduling latency) once every
> hour. I don't want jack to take *any* action at all in that
> case. I could be doing a live recording, and having a few
> xruns per hour is much less of a problem than the recording
> app being thrown out.

Hence my idea to watch the situation for longer time like 42 jack-cycles to
gather the data and only jump to action if the processing time is exceeded in
all these cycles. That way a low number of xruns is forgiven but big problems
are worked on.
The time to watch could be a command-line option. 42 might not be the answer
for everyone:-)

Have fun,

Arnold

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

torbenh
In reply to this post by Arnold Krille-3
On Wed, Nov 17, 2010 at 08:33:29PM +0100, Arnold Krille wrote:

> On Wednesday 17 November 2010 19:29:06 [hidden email] wrote:
> > On Wed, Nov 17, 2010 at 06:40:06PM +0100, Stéphane Letz wrote:
> > > Let the *user* decide?
> > Yes.
> > > Sorry to be a bit ironic, but this never ending discussion
> > > about those corner cases makes me feel sick. Almost 10 years
> > > after jack first design, it seems that there is still no sensible
> > > way to take the right decision. So my opinion is : don't do that
> > > at jack server level. If a user wants to protect against RT thread
> > > locking the machine, then das-watchdog kind of program can be used.
> > I wouldn't mind if a client that _obviously_ misbehaves (taking more
> > than few cycles) gets kicked out. Anything else should just be allowed
> > to happen, actions like waiting for a number of cycles are probably
> > going to make things worse, and only the user can decided what to do
> > next.
>
> "Let the user decide" - Good idea! Really! System load is up the roof, cycles
> are all spent in one or several processing threads going havoc, the only way
> the watchdog can react is because of highest priority. And you expect the user
> to get any notice (apart from non-moving mouse) and display warning-boxes and
> dialogs through graphic (or text) interfaces??? You got to be kidding. (Hint:

> Not all systems in use are smp systems.)

oh my... i got tricked into thinking that systems are all SMP.
still... sched_fifo is only allowed to suck 95% on linux. so the total
deadlock wont be happening. but a UP system will be crawling at that
point.

shooting clients sucks. (most clients need a restart or crash, or
whatever)
however in order to make the machine not unresponsive something should
happen, at least the code should exist in jack1 (doesnt need to be
default, i guess) but for UP people we should really have a solution,
when they accidentally overload their cpu.


>
> Just drop the most misbehaving clients from jack execution path to get the
> system back to a somewhat normal state and when that works out, signal the
> dropped clients that they might get re-added to the graph if they aren't
> naughty anymore. During that they can ask the user or increase some internal
> buffers or decide to opt-out or something...
>
> > > I suggest using exactly 3,141592653 cycles...
> > You probably meant 3.141592654 (when rounding to nearest :-)
>
> More reliable for the statistics: watch the behavior for 42 cycles.
>
> Have fun,
>
> Arnold



> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org


--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

Tim-2
In reply to this post by Fons Adriaensen-2
On November 17, 2010 04:04:16 pm [hidden email] wrote:
> Apart from that, a very common situation is that clients
> take say 80 % of the available time, and _something_ happens
> that makes that fail (e.g. scheduling latency) once every
> hour. I don't want jack to take *any* action at all in that
> case. I could be doing a live recording, and having a few
> xruns per hour is much less of a problem than the recording
> app being thrown out.
My words exactly. I like Jack2's philosophy. It's how I would
 try to design something like that. Seems the most logical.
Just wanted to say, try to preserve that philosophy if possible even
 when it's quite bad, although these cases of lockup seem to cause
 you some issues.

I would say as a user I don't mind choppiness, even severe to the
 point of, well, near lockup, users know that's an indication some thing's
 wrong, so we stop the program (if we can) and try to correct it.
Who cares if buffers are lost, let them go, I say. We'll notice it and correct.

To save the user from his own lockup, why not kick 'em out if the load
 is too severe - near lockup but not at it - after a set time, say 5 seconds?
Who to kick out. Everyone? "Party's over - everyone out! Fix the issue  
 and try again. I'll keep running for you, though."
Maybe blindly kick 'em out one by one until it's safe again?
Is it not possible to find out who are the offenders and single them out?

Hope you are able to work it out. Cheers. Tim.

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

Paul Davis
On Wed, Nov 17, 2010 at 9:03 PM, Tim E. Real <[hidden email]> wrote:

> To save the user from his own lockup, why not kick 'em out if the load
>  is too severe - near lockup but not at it - after a set time, say 5 seconds?

this is called the watchdog, and it already exists.

the issue here is not total lockup as much as continually excessive of
cpu cycles during the process() callback, leading to continual xruns.

> Who to kick out. Everyone? "Party's over - everyone out! Fix the issue
>  and try again. I'll keep running for you, though."

if you read my list of the 3 (currently identified) policies, this is #3.

> Is it not possible to find out who are the offenders and single them out?

as we've tried to outline, this is somewhat tricky unless there is a
clear offender. sometimes there is, sometimes there isn't.
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

Dominique Michel-2
In reply to this post by Paul Davis
Le Wed, 17 Nov 2010 14:50:02 -0500,
Paul Davis <[hidden email]> a écrit :

> On Wed, Nov 17, 2010 at 2:33 PM, Arnold Krille <[hidden email]>
> wrote:
>
>  [ ... ]
>
> there are really 3 possible policies:
>
>    1) ignore all client behaviour (jack2)

For me, this is the best solution, because if jackd start to make some
xruns when adding a client, I will just remove this client. And also
because it is simple, and if it is different ways to archive a result,
the simplest one will work better in most cases.

>    2) try to zombify the misbehaving client(s) (jack1)

I cannot see how jackd can know for sure what are the misbehaving
client(s) ? If a client is badly coded in respect to jack, it would be
better to not allow it to connect to jack at all. In the other cases,
the problem will be too much clients for the available processing power,
and the decision must be left to the user.

>    3) stop running the process() cycle if there is misbehaviour, and
> restart whenever
>          the grap is rechained (indicating that a client has been
> removed, or added, or connections where changed)

Not sure if I understand well. Not sure if this will not kill some
clients.

But anyway, 2) or 3) can be good to have on non SMB systems.

>
> torben has been experimenting with an improved version of (2) and
> with (3)

--
"We have the heroes we deserve."
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

Arnold Krille-3
On Thursday 18 November 2010 21:57:24 Dominique Michel wrote:

> Le Wed, 17 Nov 2010 14:50:02 -0500,
> Paul Davis <[hidden email]> a écrit :
> > On Wed, Nov 17, 2010 at 2:33 PM, Arnold Krille <[hidden email]>
> >
> > wrote:
> >  [ ... ]
> >
> > there are really 3 possible policies:
> >    1) ignore all client behaviour (jack2)
> For me, this is the best solution, because if jackd start to make some
> xruns when adding a client, I will just remove this client. And also
> because it is simple, and if it is different ways to archive a result,
> the simplest one will work better in most cases.
This is actually the worst behaviour on non-smp systems. One client messes up
and blocks the whole system. When you finally get control back (as a user), the
concert you are recording/playing is long over...

> >    2) try to zombify the misbehaving client(s) (jack1)
> I cannot see how jackd can know for sure what are the misbehaving
> client(s)?

That is the big question.

> If a client is badly coded in respect to jack, it would be
> better to not allow it to connect to jack at all.

This is the part that can not be decided by jack unless you want jackd to lock
in on a given set of "good" clients authorized by paul davis. But then paul
would be paid by that big fruit company...

> In the other cases,
> the problem will be too much clients for the available processing power,
> and the decision must be left to the user.

What about this: Running three jack-racks is no problem when all run simple
plugins. One jack-rack and one jconvolver with a big impulse response is too
much for the same system. Not a problem of to many clients. Only a problem of
one client taking to much processing time (and that might actually be the
jack-rack instance because of de-normal problems).

> >    3) stop running the process() cycle if there is misbehaviour, and
> >
> > restart whenever
> >
> >          the grap is rechained (indicating that a client has been
> >
> > removed, or added, or connections where changed)
> Not sure if I understand well. Not sure if this will not kill some
> clients.

I don't think (that many) clients should rely on their process-callback
getting called in regular intervals. At least when they do, they should know
ways to adopt their behavior it.

Have fun,

Arnold

_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org

signature.asc (205 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: zombification behaviour...

torbenh
On Thu, Nov 18, 2010 at 10:41:54PM +0100, Arnold Krille wrote:

> On Thursday 18 November 2010 21:57:24 Dominique Michel wrote:
> > Le Wed, 17 Nov 2010 14:50:02 -0500,
> > Paul Davis <[hidden email]> a écrit :
> > > On Wed, Nov 17, 2010 at 2:33 PM, Arnold Krille <[hidden email]>
> > >
> > > wrote:
> > >  [ ... ]
> > >
> > > there are really 3 possible policies:
> > >    1) ignore all client behaviour (jack2)
> > For me, this is the best solution, because if jackd start to make some
> > xruns when adding a client, I will just remove this client. And also
> > because it is simple, and if it is different ways to archive a result,
> > the simplest one will work better in most cases.

it might look simple on first glance.
but there are some gory details, which actually made things a lot
simpler, when we instantly zombify a client, which didnt reply.

we probably need some form of timeout to handle client crashes.
(it might work without the timeouts by only relying on filedescriptors
getting closed on crashes, but this would ignore stopped clients)

>
> This is actually the worst behaviour on non-smp systems. One client messes up
> and blocks the whole system. When you finally get control back (as a user), the
> concert you are recording/playing is long over...

this is the reason, why i did not want to relax the zombification rules
without implementing (3). the code is not active by default, but UP users
will really want to run jackd with -C ;)

>
> > >    2) try to zombify the misbehaving client(s) (jack1)
> > I cannot see how jackd can know for sure what are the misbehaving
> > client(s)?
>
> That is the big question.

with the relaxed rules, i am pretty confident, that only clients which
take longer than the whole period size get kicked.
i can still construct cases where we end up with a second execution
token floating around, but this situation would get caught by (3).

>
> > If a client is badly coded in respect to jack, it would be
> > better to not allow it to connect to jack at all.
>
> This is the part that can not be decided by jack unless you want jackd to lock
> in on a given set of "good" clients authorized by paul davis. But then paul
> would be paid by that big fruit company...
>
> > In the other cases,
> > the problem will be too much clients for the available processing power,
> > and the decision must be left to the user.

well, the whole patch is geared at bringing the user in control.
1) it relaxes the rule to shoot clients.
2) on UP systems the -C option makes sure, that the system stays
   responsive, so the user can quickly remove a problem.

>
> What about this: Running three jack-racks is no problem when all run simple
> plugins. One jack-rack and one jconvolver with a big impulse response is too
> much for the same system. Not a problem of to many clients. Only a problem of
> one client taking to much processing time (and that might actually be the
> jack-rack instance because of de-normal problems).
>
> > >    3) stop running the process() cycle if there is misbehaviour, and
> > >
> > > restart whenever
> > >
> > >          the grap is rechained (indicating that a client has been
> > >
> > > removed, or added, or connections where changed)
> > Not sure if I understand well. Not sure if this will not kill some
> > clients.
>
> I don't think (that many) clients should rely on their process-callback
> getting called in regular intervals. At least when they do, they should know
> ways to adopt their behavior it.

clients which get killed by this are broken. end of story.


>
> Have fun,
>
> Arnold



> _______________________________________________
> Jack-Devel mailing list
> [hidden email]
> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org


--
torben Hohn
_______________________________________________
Jack-Devel mailing list
[hidden email]
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org