Sorry - I just read you alsways checked the cpu usage. Are all cores at
100%? Is it the atserisk process which consumes it all?
Am 06.02.2013 13:54, schrieb Thorsten Göllner:
Did you watch the cpu usage (for example with top)?
You have a board installed which does use dahdi? Did you check the
command "dahdi_test"?
Maybe a (performance) problem of the software ec?
Am 06.02.2013 11:13, schrieb Hristo Trendev:
Hi,
I have been experimenting with ConfBridge from the asterisk-11 stable
SVN branch (and with 11.2.0 also) for the last 3 weeks and I see a
problem, which what I believe is performance related. I just wanted
to ask if someone else has made any tests and what is the maximum
number of participants that they've seen in a conference.
I was never able to get more than 8 participants (mixed G722 and
G711a) on a conference (actually that's per server limit) with almost
all settings on default, except for dsp_drop_silence and denoise
which are enabled.
I tested on Debian squeeze, 64-bit, quad-core Xeon server @2.4GHz and
also on another virtual server with similar processor (just one core
available to the VM). While this is not the latest and greatest CPU,
I would certainly expect it to handle more than 8 calls.
To be honest, I was in fact able to get it working for up to 20
participants (most with G711), when I switched from
res_timing_timerfd to res_timing_dahdi and turned off denoise, but
that's still not normal I believe, especially with most participants
on mute and with dps_drop_silence enabled and nothing else running on
the server.
The problem itself is, that once I get over the "critical" number of
participants, the voice starts to break up and it's impossible to
understand the person who's talking. This is certainly not bandwidth
related because all tests were made on the LAN and besides I could
see that the CPU was sometime close to 100%.
Did someone observe something similar?
BTW, once the first participant enters the conference I start seeing
probably over 50 messages per second saying:
bridging.c:757 bridge_channel_join_multithreaded: Going into a
multithreaded waitfor for bridge channel 0x292d708 of bridge 0x28f3658
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
