* You are viewing Posts Tagged ‘Cores’

Capacity of single instance of Asterisk

Hi

Can someome give tested and proven information on Asterisk capabilities?

I have a server with 24 cores running at 2.4ghz and 16 GB RAM. How many concurrent SIP sessions I can run from single instance of Asterisk on this server? I wish to use G711 codec with echo cancel. And all calls needs to be recorded.

What will be impact on no of session when G729a is used?

Thanks & Regards,
Amit Patkar

More Cores or more CPU Speed

On Fri, May 27, 2011 at 05:30:02PM +0000, daniel@danielknoll.de wrote:
>
> What is better more cores (eg. 2x quadcore) or more CPU speed for a server
> that handle a lot of of Meetme Concerences with hundreds of concurrent G711
> alaw Channels (no transcoding) ?
>
> in my opinion, more cores are better, because Asterisk ist multithreded and
> each channel has a good chance to distribute to the cores.
>
> is that right or what do you think?

I don’t have an answer for you (too many unknown variables to say one way or
another) but I do know that MeetMe currently is serialized onto a single CPU.

For example, all the conference participants threads queue up their audio data
on their pseudo channels which can happen in parallel on SMP systems. Then
they wait for the “masterspan” to mix the audio for all conferences currently
active. This happens on a single CPU to simplifly keeping channels
synchronized to whatever timing source is your master. When this was
originally written there were not too many SMP systems in use. Then the mixed
audio is queued back on the channels. Finally, all the user space channel
threads can read out the mixed audio which can happen in parallel on SMP.

If you have too many conferences, one CPU may not be able to mix all the audio
and you will have audio problems even if there are 7+ other CPUs that are
essentially idle while waiting for one CPU to mix everything. You should be
able to handle 512 conference participants on a modern server system without
problem. The current trunk of DAHDI linux limits the number of open pseudo
channels to 512 for this reason. [1]

[1] http://svn.asterisk.org/view/dahdi?view=revision&revision=9610

The new ConfBridge module in the upcoming 1.10 release may not have this
limitation.