[Asterisk-Users] Server Criteria

Steven Critchfield critch at basesys.com
Fri Feb 4 13:24:56 MST 2005


On Fri, 2005-02-04 at 11:21 -0800, Spencer Nassar wrote:
> I've been doing a lot of background reading/searching of this list, 
> voip-info.org, and Google, looking to define a good candidate for a 
> server platform.  I'm very interested in thoughts from others!  So here 
> goes...
> 
> Axiom 1:  if you are not doing doing much transcoding (converting 
> between codecs), the bottleneck for supporting high volumes of 
> simultaneous calls is system bus speed, not CPU power
> ---> points to a 64 bit AMD Opteron system, and maybe just one of the 
> two processor slots populated.  Bus is twice as wide as a 32 bit 
> system, and operates at 1.8GHz (a lot faster than a 64 bit Zeon 
> system).  Then add the second processor to the board if you see you 
> need it.

This I guess depends mostly on what channels you are using. Since a
fully loaded E1 is only 2mbps and you are unlikely to want to place more
than a few per machine before you start building redundancy into your
systems, You will be moving less data than a 100mb ethernet card, but on
a realtime basis instead of being able to delay service. On the other
hand, if you are talking all VoIP, it might help to service that NIC a
little faster to keep all your callers happy with latency.  

> Axiom 2:  Get lots of memory
> ---> I haven't seen this quantified, and plan to do some testing.  I'll 
> post results here, but can anyone share any insights?  I'm planning to 
> start at 2GB, and go up from there if I see swap getting used.
>     - what would an alaw to alaw connection consume (if it didn't hand 
> off)?
>     - what about a 5 call alaw meetme bridge (and how much memory per 
> incremental caller)

Other than a few structures relating to each call and it's state, you
only pass about 160 samples around to be worked on at a time and in
signed linear thats only 320 bytes. So per call incremental memory
shouldn't be very much, probably on the order of a few K at best. We run
our main systems right now with only 256m and they handle T1 capacity.

> Axiom 3: Don't allow any disk IO
> ---> I'm assuming this is related to #2 - get lots of memory to avoid 
> swap to disk.  Other issues or thoughts?

Disk IO isn't a killer. You just have to be careful about not pounding
the drives. Many of us record calls directly to the main drives of the
asterisk machine. Voice mail goes straight to main drives. Just don't
put a database that is going to see much more than extremely sparse
access on the same machine.

> Axoim 4: Come codecs will take advantage of the faster floating point 
> of a 64 bit system
> ---> unknown... has anyone seen this?  Will Asterisk, compiled in a 64 
> bit Linux environment, reap these or other benefits from being on a 64 
> bit system (other than the system bus speed)?

Is the floating point unit that much faster than an equivalent clocked
non 64 bit system? You will probably see similarly improved performance
on the same clock speed rises. Otherwise, I don't know much about the
math being used internally to help on that question.

Hope that sharpens some of your questions to get the data you are
looking for.

-- 
Steven Critchfield <critch at basesys.com>




More information about the asterisk-users mailing list