9 Jun
2016
9 Jun
'16
5:02 a.m.
Hello,
at some point I am getting the following errors from JACK
Jun 9 11:57:19 001-can1-plumber jackd[21110]: shm registry full
Jun 9 11:57:19 001-can1-plumber jackd[21110]: Cannot create shared memory
segment of size = 422
Jun 9 11:57:19 001-can1-plumber jackd[21110]: JackShmMem::new bad alloc
Jun 9 11:57:19 001-can1-plumber jackd[21110]: Cannot open client
Jun 9 11:57:19 001-can1-plumber jackd[21110]: Cannot create new client
Max locked memory for this process is set to 134217728 while launching JACK
via systemd.
It effectively causes JACK to hang.
I am using 1.9.10 (commit 1ed50c92) on ubuntu 16.04.
The configure flags are --clients=500 --ports-per-application=4 (I am not
reaching 500 clients limit when that occurs, they are around 250).
JACK is started with dummy driver, and --port-max set to 2000.
What is the reason for hitting SHM limit? Can I overcome this in any way?
m.
9 Jun
9 Jun
5:32 a.m.
Hello,
I've found a piece of code that can be responsible for this:
#define MAX_SHM_ID 256
This is used to determine size of the registry.
What is rationale for hardcoding this like this?
m.
2016-06-09 12:02 GMT+02:00 marcin(a)saepia.net <marcin(a)saepia.net>et>:
Hello,
at some point I am getting the following errors from JACK
Jun 9 11:57:19 001-can1-plumber jackd[21110]: shm registry full
Jun 9 11:57:19 001-can1-plumber jackd[21110]: Cannot create shared memory
segment of size = 422
Jun 9 11:57:19 001-can1-plumber jackd[21110]: JackShmMem::new bad alloc
Jun 9 11:57:19 001-can1-plumber jackd[21110]: Cannot open client
Jun 9 11:57:19 001-can1-plumber jackd[21110]: Cannot create new client
Max locked memory for this process is set to 134217728 while launching
JACK via systemd.
It effectively causes JACK to hang.
I am using 1.9.10 (commit 1ed50c92) on ubuntu 16.04.
The configure flags are --clients=500 --ports-per-application=4 (I am not
reaching 500 clients limit when that occurs, they are around 250).
JACK is started with dummy driver, and --port-max set to 2000.
What is the reason for hitting SHM limit? Can I overcome this in any way?
m.
6:39 a.m.
shared memory is not a very malleable resource. you can't just arbitrarily
increase the size of it like you can with heap memory.
But running 250 JACK clients is not a viable workflow either. It doesn't
scale in that way unless you're not interested in latency, in which case
use PulseAudio.
On Thu, Jun 9, 2016 at 6:32 AM, marcin(a)saepia.net <marcin(a)saepia.net> wrote:
Hello,
I've found a piece of code that can be responsible for this:
#define MAX_SHM_ID 256
This is used to determine size of the registry.
What is rationale for hardcoding this like this?
m.
2016-06-09 12:02 GMT+02:00 marcin(a)saepia.net <marcin(a)saepia.net>et>:
Hello,
at some point I am getting the following errors from JACK
Jun 9 11:57:19 001-can1-plumber jackd[21110]: shm registry full
Jun 9 11:57:19 001-can1-plumber jackd[21110]: Cannot create shared
memory segment of size = 422
Jun 9 11:57:19 001-can1-plumber jackd[21110]: JackShmMem::new bad alloc
Jun 9 11:57:19 001-can1-plumber jackd[21110]: Cannot open client
Jun 9 11:57:19 001-can1-plumber jackd[21110]: Cannot create new client
Max locked memory for this process is set to 134217728 while launching
JACK via systemd.
It effectively causes JACK to hang.
I am using 1.9.10 (commit 1ed50c92) on ubuntu 16.04.
The configure flags are --clients=500 --ports-per-application=4 (I am not
reaching 500 clients limit when that occurs, they are around 250).
JACK is started with dummy driver, and --port-max set to 2000.
What is the reason for hitting SHM limit? Can I overcome this in any way?
m.
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
10 Jun
10 Jun
8:46 a.m.
Well I understand but what I observe is that JACK has unpredictable amount
of total clients which is an issue, regardless if it's closer to 10 than
1000.
I have found out at least 3 conditions that affect this:
- compilation flags, which by the way may cause jack to segfault if they
are set too high
- parameter to jackd
- MAX_SHM_ID
I suggest integrating this into one runtime command line parameter.
M.
09.06.2016 1:39 PM "Paul Davis" <paul(a)linuxaudiosystems.com> napisał(a):
shared memory is not a very malleable resource. you
can't just arbitrarily
increase the size of it like you can with heap memory.
But running 250 JACK clients is not a viable workflow either. It doesn't
scale in that way unless you're not interested in latency, in which case
use PulseAudio.
On Thu, Jun 9, 2016 at 6:32 AM, marcin(a)saepia.net <marcin(a)saepia.net>
wrote:
Hello,
I've found a piece of code that can be responsible for this:
#define MAX_SHM_ID 256
This is used to determine size of the registry.
What is rationale for hardcoding this like this?
m.
2016-06-09 12:02 GMT+02:00 marcin(a)saepia.net <marcin(a)saepia.net>et>:
Hello,
at some point I am getting the following errors from JACK
Jun 9 11:57:19 001-can1-plumber jackd[21110]: shm registry full
Jun 9 11:57:19 001-can1-plumber jackd[21110]: Cannot create shared
memory segment of size = 422
Jun 9 11:57:19 001-can1-plumber jackd[21110]: JackShmMem::new bad alloc
Jun 9 11:57:19 001-can1-plumber jackd[21110]: Cannot open client
Jun 9 11:57:19 001-can1-plumber jackd[21110]: Cannot create new client
Max locked memory for this process is set to 134217728 while launching
JACK via systemd.
It effectively causes JACK to hang.
I am using 1.9.10 (commit 1ed50c92) on ubuntu 16.04.
The configure flags are --clients=500 --ports-per-application=4 (I am
not reaching 500 clients limit when that occurs, they are around 250).
JACK is started with dummy driver, and --port-max set to 2000.
What is the reason for hitting SHM limit? Can I overcome this in any way?
m.
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
9:39 a.m.
client limits: i will leave the developer(s) of jack2 to comment on the
specifics. jack2 hard-codes more values than jack1.
the shared memory registry: you can't make its configuration a run-time
thing, because you'd have to ensure that the library and the server are
both given the same value.
MAX_SHM_ID is an operating system constant.
you are hitting the limit almost certainly because you are running far more
clients than JACK was designed to support.
every client with a process callback implies at least 1 extra context
switch during the process cycle. this does not and cannot scale with
contemporary operating systems and processors. context switches are cheap
but not free. doing hundreds of them per process cycle steals significant
amounts of time from what is available for actual signal processing.
On Fri, Jun 10, 2016 at 9:46 AM, marcin(a)saepia.net <marcin(a)saepia.net>
wrote:
Well I understand but what I observe is that JACK has
unpredictable amount
of total clients which is an issue, regardless if it's closer to 10 than
1000.
I have found out at least 3 conditions that affect this:
- compilation flags, which by the way may cause jack to segfault if they
are set too high
- parameter to jackd
- MAX_SHM_ID
I suggest integrating this into one runtime command line parameter.
M.
10:13 a.m.
Hello,
if MAX_SHM_ID is an OS constant, why is it defined in JACK source code then?
I understand issues with context switching. But I am designing system that
can easily split into multiple machines, so instead of having 1 huge JACK
with 100 clients I can have 10 x 10 etc. But still, I need to know what is
the limit, and it seem to be quite unknown… I can obviously do crash
testing, but I would prefer to rely on certain design principles, no luck
that I won’t encounter some hardcoded limits...
Any advice how to compute max number of clients?
Any experience about that in practice?
Marcin
dnia 10 czerwca 2016 o 16:39:17, Paul Davis (paul(a)linuxaudiosystems.com)
napisał:
client limits: i will leave the developer(s) of jack2 to comment on the
specifics. jack2 hard-codes more values than jack1.
the shared memory registry: you can't make its configuration a run-time
thing, because you'd have to ensure that the library and the server are
both given the same value.
MAX_SHM_ID is an operating system constant.
you are hitting the limit almost certainly because you are running far more
clients than JACK was designed to support.
every client with a process callback implies at least 1 extra context
switch during the process cycle. this does not and cannot scale with
contemporary operating systems and processors. context switches are cheap
but not free. doing hundreds of them per process cycle steals significant
amounts of time from what is available for actual signal processing.
On Fri, Jun 10, 2016 at 9:46 AM, marcin(a)saepia.net <marcin(a)saepia.net>
wrote:
Well I understand but what I observe is that JACK has
unpredictable amount
of total clients which is an issue, regardless if it's closer to 10 than
1000.
I have found out at least 3 conditions that affect this:
- compilation flags, which by the way may cause jack to segfault if they
are set too high
- parameter to jackd
- MAX_SHM_ID
I suggest integrating this into one runtime command line parameter.
M.
10:18 a.m.
On Fri, Jun 10, 2016 at 11:13 AM, Marcin Lewandowski <marcin(a)saepia.net>
wrote:
Hello,
if MAX_SHM_ID is an OS constant, why is it defined in JACK source code
then?
oops, my mistake ... misread my own grep output. sorry about that.
I understand issues with context switching. But I am designing system that
can easily split into multiple machines, so instead of having 1 huge JACK
with 100 clients I can have 10 x 10 etc.
that won't help.
But still, I need to know what is the limit, and it
seem to be quite
unknown… I can obviously do crash testing, but I would prefer to rely on
certain design principles, no luck that I won’t encounter some hardcoded
limits...
well, as mentioned, you can't put things on the command line that have be
constant across the server and library. so there are some constants that
are going to be hard-coded whether you like it or not.
there is no "hard limit". the number of clients before there is so little
time left for the process cycle() depends on (a) what each client does (b)
how much time each client takes for its context switch (which is partially
a function of what it does) (c) the period size
Any advice how to compute max number of clients?
as noted above, you cannot compute this number. it will vary dramatically
depending on the condition.
11 Jun
11 Jun
2:54 a.m.
On Fri, Jun 10, 2016 at 5:18 PM, Paul Davis <paul(a)linuxaudiosystems.com>
But still, I need to know what is the limit, and it seem to be quite
I understood his question to be how many ports you can add before running
out of shared memory,
not how many clients you can run before running out of cpu...
unknown… I can obviously do crash testing, but I
would prefer to rely on
certain design principles, no luck that I won’t encounter some hardcoded
limits...
well, as mentioned, you can't put things on the command line that have be
constant across the server and library. so there are some constants that
are going to be hard-coded whether you like it or not.
there is no "hard limit". the number of clients before there is so little
time left for the process cycle() depends on (a) what each client does (b)
how much time each client takes for its context switch (which is partially
a function of what it does) (c) the period size
3:18 a.m.
Exactly.
I am not asking when drops will start to occur.
I am asking about technical capability to connect clients even if they do
nothing regarding DSP.
I run into issues on jack_client_open phase, not later.
If I will have issues later on with drops due to exceeding DSP load, then I
will try to figure out how to optimize that part, but for now I just need
to predict if JACK will handle properly just connecting many clients.
M.
11.06.2016 9:54 AM "Kjetil Matheussen" <k.s.matheussen(a)gmail.com>
napisał(a):
On Fri, Jun 10, 2016 at 5:18 PM, Paul Davis <paul(a)linuxaudiosystems.com>
But still, I need to know what is the limit, and it seem to be quite
I understood his question to be how many ports you can add before running
out of shared memory,
not how many clients you can run before running out of cpu...
unknown… I can obviously do crash testing, but I
would prefer to rely on
certain design principles, no luck that I won’t encounter some hardcoded
limits...
well, as mentioned, you can't put things on the command line that have be
constant across the server and library. so there are some constants that
are going to be hard-coded whether you like it or not.
there is no "hard limit". the number of clients before there is so little
time left for the process cycle() depends on (a) what each client does (b)
how much time each client takes for its context switch (which is partially
a function of what it does) (c) the period size
6 a.m.
Ah, well for just port counts, Jack2 hard-codes the limit at compile time.
Jack1 allows any size to be set at run time.
However, you've run into the shm registry issue, and both Jack2 and Jack1
encode that at compile time.
There are no explicit limits on the number of clients themselves in either
implementation.
On Sat, Jun 11, 2016 at 4:18 AM, marcin(a)saepia.net <marcin(a)saepia.net>
wrote:
Exactly.
I am not asking when drops will start to occur.
I am asking about technical capability to connect clients even if they do
nothing regarding DSP.
I run into issues on jack_client_open phase, not later.
If I will have issues later on with drops due to exceeding DSP load, then
I will try to figure out how to optimize that part, but for now I just need
to predict if JACK will handle properly just connecting many clients.
M.
11.06.2016 9:54 AM "Kjetil Matheussen" <k.s.matheussen(a)gmail.com>
napisał(a):
>
>
> On Fri, Jun 10, 2016 at 5:18 PM, Paul Davis <paul(a)linuxaudiosystems.com>
>
>>
>> But still, I need to know what is the limit, and it seem to be quite
>>> unknown… I can obviously do crash testing, but I would prefer to rely on
>>> certain design principles, no luck that I won’t encounter some hardcoded
>>> limits...
>>>
>>
>> well, as mentioned, you can't put things on the command line that have
>> be constant across the server and library. so there are some constants that
>> are going to be hard-coded whether you like it or not.
>>
>> there is no "hard limit". the number of clients before there is so
>> little time left for the process cycle() depends on (a) what each client
>> does (b) how much time each client takes for its context switch (which is
>> partially a function of what it does) (c) the period size
>>
>>
> I understood his question to be how many ports you can add before running
> out of shared memory,
> not how many clients you can run before running out of cpu...
>
>
>
6:18 p.m.
No comment.
10.06.2016 10:21 PM "David Nielson" <david(a)naptastic.com> napisał(a):
On 06/10/2016 10:13 AM, Marcin Lewandowski wrote:
Any advice how to compute max number of clients?
You add more clients until it doesn't work for you anymore.
David Nielson
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
6:21 p.m.
What else do you imagine?
How many instances of jack_midi_dump do you can run compared with how many
instances of Ardour?
On Fri, Jun 10, 2016 at 7:18 PM, marcin(a)saepia.net <marcin(a)saepia.net>
wrote:
No comment.
10.06.2016 10:21 PM "David Nielson" <david(a)naptastic.com> napisał(a):
On 06/10/2016 10:13 AM, Marcin Lewandowski wrote:
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Any advice how to compute max number of clients?
You add more clients until it doesn't work for you anymore.
David Nielson
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
6:25 p.m.
I imagine that author of a certain software is capable of making answer
such as "maximum amount of X is dependent of Y, even if it's not entirely
predictable, you have to be aware that the potential bottleneck is Z".
I am so glad that bridges are not designed by programmers.
M.
11.06.2016 1:21 AM "Paul Davis" <paul(a)linuxaudiosystems.com> napisał(a):
What else do you imagine?
How many instances of jack_midi_dump do you can run compared with how many
instances of Ardour?
On Fri, Jun 10, 2016 at 7:18 PM, marcin(a)saepia.net <marcin(a)saepia.net>
wrote:
No comment.
10.06.2016 10:21 PM "David Nielson" <david(a)naptastic.com> napisał(a):
On 06/10/2016 10:13 AM, Marcin Lewandowski wrote:
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
Any advice how to compute max number of clients?
You add more clients until it doesn't work for you anymore.
David Nielson
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
7:44 p.m.
bridges are the wrong analogy. or maybe they are the perfect analogy.
the capacity of a bridge is typically measured in mass units (so many kg or
tonnes or whatever). if someone comes along and asks "how many vehicles can
the bridge support?", there is no good answer. if we're talking about a
bunch of small passenger cars, the answer will be completely different than
if the vehicles are all massive freight haulers moving the parts of another
bridge, tanks and large concrete shapes.
JACK is similar. I could tell you that most systems can get up to between
80-95% "DSP load" level before things start falling apart. But what means
in terms of actual clients is really indeterminate until you know what
those clients do.
On Fri, Jun 10, 2016 at 7:25 PM, marcin(a)saepia.net <marcin(a)saepia.net>
wrote:
I imagine that author of a certain software is capable
of making answer
such as "maximum amount of X is dependent of Y, even if it's not entirely
predictable, you have to be aware that the potential bottleneck is Z".
I am so glad that bridges are not designed by programmers.
M.
11.06.2016 1:21 AM "Paul Davis" <paul(a)linuxaudiosystems.com> napisał(a):
> What else do you imagine?
>
> How many instances of jack_midi_dump do you can run compared with how
> many instances of Ardour?
>
> On Fri, Jun 10, 2016 at 7:18 PM, marcin(a)saepia.net <marcin(a)saepia.net>
> wrote:
>
>> No comment.
>> 10.06.2016 10:21 PM "David Nielson" <david(a)naptastic.com>
napisał(a):
>>
>>>
>>> On 06/10/2016 10:13 AM, Marcin Lewandowski wrote:
>>> >
>>> > Any advice how to compute max number of clients?
>>> >
>>>
>>> You add more clients until it doesn't work for you anymore.
>>>
>>> David Nielson
>>>
>>>
>>> _______________________________________________
>>> Jack-Devel mailing list
>>> Jack-Devel(a)lists.jackaudio.org
>>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>>
>>>
>> _______________________________________________
>> Jack-Devel mailing list
>> Jack-Devel(a)lists.jackaudio.org
>> http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
>>
>>
>
2870
days inactive
2872
days old
jackaudio@lists.linuxaudio.org
14 comments
5 participants
participants (5)
-
David Nielson -
Kjetil Matheussen -
Marcin Lewandowski -
marcin＠saepia.net
-
Paul Davis