extreme difference in port creation performance between jack1 and jack2

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

extreme difference in port creation performance between jack1 and jack2

Jörn Nettingsmeier-5
hi *!


this may be a known issue, and it sure is a corner case, but i found
that jack2 is orders of magnitude slower when creating a massive number
of ports.

my testcase is a third-order ambisonic ardour session with more than
1500 ports. it takes just a few seconds to load when using jack1, but a
few minutes when using jack2. following qjackctl's message window, i can
see that port creation happens very slowly.

i'm not saying this is necessarily a bug, as my session is clearly a
pathological case, but the difference is striking... won't matter for
99% of the users, but it does form an upper bound for ambisonic work - i
couldn't see myself going to fourth order using ardour2/jack2.

(btw, iiuc ardour3 will ameliorate this issue by no longer relying on
jack for its internal routing, so the issue may become moot soon.)


best,

jörn


--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio), Elektrofachkraft
Audio and event engineer - Ambisonic surround recordings

http://stackingdwarves.net

_______________________________________________
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: extreme difference in port creation performance between jack1 and jack2

Stéphane Letz

Le 16 nov. 2010 à 21:57, Jörn Nettingsmeier a écrit :

> hi *!
>
>
> this may be a known issue, and it sure is a corner case, but i found
> that jack2 is orders of magnitude slower when creating a massive number
> of ports.
>
> my testcase is a third-order ambisonic ardour session with more than
> 1500 ports. it takes just a few seconds to load when using jack1, but a
> few minutes when using jack2. following qjackctl's message window, i can
> see that port creation happens very slowly.

AFAIR it is not the port create per see, but the fact that ardour check the connection state just after port registration (or something like that).

In jack2 there is a 2 state model with a lock-free switch from "old state" to "next state" that happens at each cycle (when the state has been changed).


>
> i'm not saying this is necessarily a bug, as my session is clearly a
> pathological case, but the difference is striking... won't matter for
> 99% of the users, but it does form an upper bound for ambisonic work - i
> couldn't see myself going to fourth order using ardour2/jack2.

I agree this is an issue with jack2, but as you said you're in a really pathological case
>
>
> (btw, iiuc ardour3 will ameliorate this issue by no longer relying on
> jack for its internal routing, so the issue may become moot soon.)
>

Or something could possibly be done at ardour level, I don't know.

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: extreme difference in port creation performance between jack1 and jack2

Jörn Nettingsmeier-5
On 11/17/2010 10:34 AM, Stéphane Letz wrote:

>
> Le 16 nov. 2010 à 21:57, Jörn Nettingsmeier a écrit :
>
>> my testcase is a third-order ambisonic ardour session with more
>> than 1500 ports. it takes just a few seconds to load when using
>> jack1, but a few minutes when using jack2. following qjackctl's
>> message window, i can see that port creation happens very slowly.
>
> AFAIR it is not the port create per see, but the fact that ardour
> check the connection state just after port registration (or something
> like that).
>
> In jack2 there is a 2 state model with a lock-free switch from "old
> state" to "next state" that happens at each cycle (when the state has
> been changed).

thanks for the explanation. if it's indeed an issue with ardour, it will
probably go away when i move on to ardour3...

>> i'm not saying this is necessarily a bug, as my session is clearly
>> a pathological case, but the difference is striking... won't matter
>> for 99% of the users, but it does form an upper bound for ambisonic
>> work - i couldn't see myself going to fourth order using
>> ardour2/jack2.
>
> I agree this is an issue with jack2, but as you said you're in a
> really pathological case

:)


best,

jörn



--
Jörn Nettingsmeier
Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487

Meister für Veranstaltungstechnik (Bühne/Studio), Elektrofachkraft
Audio and event engineer - Ambisonic surround recordings

http://stackingdwarves.net

_______________________________________________
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: extreme difference in port creation performance between jack1 and jack2

torbenh
In reply to this post by Jörn Nettingsmeier-5
On Tue, Nov 16, 2010 at 09:57:03PM +0100, Jörn Nettingsmeier wrote:

> hi *!
>
>
> this may be a known issue, and it sure is a corner case, but i found
> that jack2 is orders of magnitude slower when creating a massive number
> of ports.
>
> my testcase is a third-order ambisonic ardour session with more than
> 1500 ports. it takes just a few seconds to load when using jack1, but a
> few minutes when using jack2. following qjackctl's message window, i can
> see that port creation happens very slowly.
>
> i'm not saying this is necessarily a bug, as my session is clearly a
> pathological case, but the difference is striking... won't matter for
> 99% of the users, but it does form an upper bound for ambisonic work - i
> couldn't see myself going to fourth order using ardour2/jack2.

how about tschack ?
regarding port creation i made it pretty quick.
(one of my primary users was/is? alex ;)

its not as fast as jack1, but thats what you get, if you want clickless
connections :)


>
> (btw, iiuc ardour3 will ameliorate this issue by no longer relying on
> jack for its internal routing, so the issue may become moot soon.)

well... a bit.
but you probably still have quite a big set of connections.

(note that a3 will help you a lot more, because of smp capabilities)
if ardour is the single client, an smp jack will help you exactly
nothing.

>
>
> best,
>
> jörn
>
>
> --
> Jörn Nettingsmeier
> Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487
>
> Meister für Veranstaltungstechnik (Bühne/Studio), Elektrofachkraft
> Audio and event engineer - Ambisonic surround recordings
>
> http://stackingdwarves.net
>
> _______________________________________________
> 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: extreme difference in port creation performance between jack1 and jack2

Stéphane Letz
In reply to this post by Jörn Nettingsmeier-5

Le 17 nov. 2010 à 11:29, Jörn Nettingsmeier a écrit :

> On 11/17/2010 10:34 AM, Stéphane Letz wrote:
>>
>> Le 16 nov. 2010 à 21:57, Jörn Nettingsmeier a écrit :
>>
>>> my testcase is a third-order ambisonic ardour session with more
>>> than 1500 ports. it takes just a few seconds to load when using
>>> jack1, but a few minutes when using jack2. following qjackctl's
>>> message window, i can see that port creation happens very slowly.
>>
>> AFAIR it is not the port create per see, but the fact that ardour
>> check the connection state just after port registration (or something
>> like that).
>>
>> In jack2 there is a 2 state model with a lock-free switch from "old
>> state" to "next state" that happens at each cycle (when the state has
>> been changed).
>
> thanks for the explanation. if it's indeed an issue with ardour, it will
> probably go away when i move on to ardour3...

No i'm not saying it is an issue in ardour at all .... ((-:

it is an design choice in jack2 that shows in this kind of specific case.


>
>>> i'm not saying this is necessarily a bug, as my session is clearly
>>> a pathological case, but the difference is striking... won't matter
>>> for 99% of the users, but it does form an upper bound for ambisonic
>>> work - i couldn't see myself going to fourth order using
>>> ardour2/jack2.
>>
>> I agree this is an issue with jack2, but as you said you're in a
>> really pathological case
>
> :)
>
>
> best,
>
> jörn
>

Stépahne
_______________________________________________
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: extreme difference in port creation performance between jack1 and jack2

torbenh
On Wed, Nov 17, 2010 at 05:29:59PM +0100, Stéphane Letz wrote:

>
> Le 17 nov. 2010 à 11:29, Jörn Nettingsmeier a écrit :
>
> > On 11/17/2010 10:34 AM, Stéphane Letz wrote:
> >>
> >> Le 16 nov. 2010 à 21:57, Jörn Nettingsmeier a écrit :
> >>
> >>> my testcase is a third-order ambisonic ardour session with more
> >>> than 1500 ports. it takes just a few seconds to load when using
> >>> jack1, but a few minutes when using jack2. following qjackctl's
> >>> message window, i can see that port creation happens very slowly.
> >>
> >> AFAIR it is not the port create per see, but the fact that ardour
> >> check the connection state just after port registration (or something
> >> like that).
> >>
> >> In jack2 there is a 2 state model with a lock-free switch from "old
> >> state" to "next state" that happens at each cycle (when the state has
> >> been changed).
> >
> > thanks for the explanation. if it's indeed an issue with ardour, it will
> > probably go away when i move on to ardour3...
>
> No i'm not saying it is an issue in ardour at all .... ((-:
>
> it is an design choice in jack2 that shows in this kind of specific case.

jack2 basically waits until the last connect went through.
iiuc it needs a process cycle, to have it tinker through.

tschack was using this model in the beginning too.
but since alex is using 100+ ports and connections all the time too, i
abandoned it. because it makes 100 ports a pita too.



>
>
> >
> >>> i'm not saying this is necessarily a bug, as my session is clearly
> >>> a pathological case, but the difference is striking... won't matter
> >>> for 99% of the users, but it does form an upper bound for ambisonic
> >>> work - i couldn't see myself going to fourth order using
> >>> ardour2/jack2.
> >>
> >> I agree this is an issue with jack2, but as you said you're in a
> >> really pathological case
> >
> > :)
> >
> >
> > best,
> >
> > jörn
> >
>
> Stépahne
> _______________________________________________
> 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: extreme difference in port creation performance between jack1 and jack2

Stéphane Letz

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

> On Wed, Nov 17, 2010 at 05:29:59PM +0100, Stéphane Letz wrote:
>>
>> Le 17 nov. 2010 à 11:29, Jörn Nettingsmeier a écrit :
>>
>>> On 11/17/2010 10:34 AM, Stéphane Letz wrote:
>>>>
>>>> Le 16 nov. 2010 à 21:57, Jörn Nettingsmeier a écrit :
>>>>
>>>>> my testcase is a third-order ambisonic ardour session with more
>>>>> than 1500 ports. it takes just a few seconds to load when using
>>>>> jack1, but a few minutes when using jack2. following qjackctl's
>>>>> message window, i can see that port creation happens very slowly.
>>>>
>>>> AFAIR it is not the port create per see, but the fact that ardour
>>>> check the connection state just after port registration (or something
>>>> like that).
>>>>
>>>> In jack2 there is a 2 state model with a lock-free switch from "old
>>>> state" to "next state" that happens at each cycle (when the state has
>>>> been changed).
>>>
>>> thanks for the explanation. if it's indeed an issue with ardour, it will
>>> probably go away when i move on to ardour3...
>>
>> No i'm not saying it is an issue in ardour at all .... ((-:
>>
>> it is an design choice in jack2 that shows in this kind of specific case.
>
> jack2 basically waits until the last connect went through.
> iiuc it needs a process cycle, to have it tinker through.

jack2 has to wait when *reading* a still changing connection state during a cycle, to retrieve the new state.

So basically is an application does a "jack_connect" then a "jack_port_connected" just after, the "jack_port_connected" would wait for the change to be effective (so that to see the *new* state, and this new state is visible the next cycle). But if application does a sequence of jack_connect and is not interested to see the change after each, then there is no delay at all.

>
> tschack was using this model in the beginning too.
> but since alex is using 100+ ports and connections all the time too, i
> abandoned it. because it makes 100 ports a pita too.

So how does tschack implement that? when a client does a "jack_connect" then a "jack_port_connected" after : what is the retrieved connection state?

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: extreme difference in port creation performance between jack1 and jack2

torbenh
On Wed, Nov 17, 2010 at 06:33:47PM +0100, Stéphane Letz wrote:

>
> Le 17 nov. 2010 à 18:21, torbenh a écrit :
>
> > On Wed, Nov 17, 2010 at 05:29:59PM +0100, Stéphane Letz wrote:
> >>
> >> Le 17 nov. 2010 à 11:29, Jörn Nettingsmeier a écrit :
> >>
> >>> On 11/17/2010 10:34 AM, Stéphane Letz wrote:
> >>>>
> >>>> Le 16 nov. 2010 à 21:57, Jörn Nettingsmeier a écrit :
> >>>>
> >>>>> my testcase is a third-order ambisonic ardour session with more
> >>>>> than 1500 ports. it takes just a few seconds to load when using
> >>>>> jack1, but a few minutes when using jack2. following qjackctl's
> >>>>> message window, i can see that port creation happens very slowly.
> >>>>
> >>>> AFAIR it is not the port create per see, but the fact that ardour
> >>>> check the connection state just after port registration (or something
> >>>> like that).
> >>>>
> >>>> In jack2 there is a 2 state model with a lock-free switch from "old
> >>>> state" to "next state" that happens at each cycle (when the state has
> >>>> been changed).
> >>>
> >>> thanks for the explanation. if it's indeed an issue with ardour, it will
> >>> probably go away when i move on to ardour3...
> >>
> >> No i'm not saying it is an issue in ardour at all .... ((-:
> >>
> >> it is an design choice in jack2 that shows in this kind of specific case.
> >
> > jack2 basically waits until the last connect went through.
> > iiuc it needs a process cycle, to have it tinker through.
>
> jack2 has to wait when *reading* a still changing connection state during a cycle, to retrieve the new state.
>
> So basically is an application does a "jack_connect" then a "jack_port_connected" just after, the "jack_port_connected" would wait for the change to be effective (so that to see the *new* state, and this new state is visible the next cycle). But if application does a sequence of jack_connect and is not interested to see the change after each, then there is no delay at all.

well... i thought i saw it reading the state before trying to connect.
anyways. dont care.
>
> >
> > tschack was using this model in the beginning too.
> > but since alex is using 100+ ports and connections all the time too, i
> > abandoned it. because it makes 100 ports a pita too.
>
> So how does tschack implement that? when a client does a "jack_connect" then a "jack_port_connected" after : what is the retrieved connection state?

the retrieved state is "connected" even if the pending changes didnt get
through yet, and the old state might be there for quite a while, when
the pending chain gets rewritten continously.

tschack has one locked and consistent list of connections.
this list is backed by a double buffered list, which the RT threads are
accessing.
complexity is considerably higher, but this is the design choice for
tschack.... no compromise.

>
> 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: extreme difference in port creation performance between jack1 and jack2

Fons Adriaensen-2
In reply to this post by Stéphane Letz
On Wed, Nov 17, 2010 at 06:33:47PM +0100, Stéphane Letz wrote:

> So basically is an application does a "jack_connect" then a
> "jack_port_connected" just after, the "jack_port_connected"
> would wait for the change to be effective (so that to see
> the *new* state, and this new state is visible the next cycle).
> But if application does a sequence of jack_connect and is not
> interested to see the change after each, then there is no delay
> at all.

What about the connection callback ? Is it delayed as well to the
next cycle ? That would mean that either you have to queue the
data required by the callback, or you can do just one per cycle.
 
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: extreme difference in port creation performance between jack1 and jack2

Tim-2
In reply to this post by torbenh
On November 17, 2010 07:15:52 am torbenh wrote:
> regarding port creation i made it pretty quick.
> (one of my primary users was/is? alex ;)
I think we raised the number of ports in MusE for him.
When he told us he had songs running 100's of tracks and many ports,
 I was like, sweating profusely, "and um it... works?", apparently so.
Tim.

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