WARNING: this is an automatic post retrieved from the Asterisk-Users Mailing List, not an authored post
May 27, 2011
Tags: audio, conference participants, Cores, daniel, SMP, smp systems, space channel, timing source
On Fri, May 27, 2011 at 05:30:02PM +0000, email@example.com 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. 
The new ConfBridge module in the upcoming 1.10 release may not have this