[Asterisk-Users] Re: Hardware for handling large call volume

[John Todd]

[moved to asterisk-users, as this is not a development question]

At 1:40 PM -0400 on 4/24/04, Sudhir Kumar wrote:
>I would like to hear from any of you who has done any kind of
>benchmarking on a robust hardware that can handle large call volume,
>preferably with G.729 codec involved.
>
>We are in the process of putting together a system that should have a
>quad E1 card, G.729 and/or iLBC codecs. The test scenario we are
>interested in:
>	1. keeping all E1 lines saturated (SIP<->PSTN),
>     and 2. as many SIP to SIP calls as possible.
>
>I will share our experience with this group.
>
>We would greatly benefit from any recommendation you can give us about
>the hardware we should use. Mark, Jeremy, Steven, .... anyone.
>
>Thanks,
>-- sudhir

My rule of thumb has been 100 G.729 channels for a dual 3.0ghz Xeon 
machine.  Cost: around $42 per channel (I buy SCSI systems with RAID, 
and that includes the $10 charge for the G.729 license.)  Your 
mileage may vary in both performance and price.  Cost for an 
AS5300-style solution: around $110 per channel, and that's on the 
used market pricing plan.  DSPs are nice if you have a lot of money, 
but the price for doing DSP-type processing on generalized processors 
is dropping rapidly.  As the saying goes: "Specialization is for 
insects."  Even with the badly-coded g.729 codec, it's still 
impressively fast.

I have now been extremely satisfied with SuperMicro motherboards, so 
I'd recommend them, and the guys at Silicon Mechanics (referred 
through someone else here on this list from a while back... don't 
remember who) have done outstanding work for me with those boards and 
first-rate chassis/integrations/drives.

If you're doing SIP-to-SIP, you can often stay out of the media 
channel, which means no transcoding overhead unless you have special 
requirements (transfer, recording, etc.)  Of course, PSTN (PRI) 
termination will always mean media conversion unless you're doing 
G.711.  Keeping a system "saturated" means having busy signals, since 
to keep a system saturated that implies having more 1 more call at 
your minimum moment in the day than you have capacity to handle.

I've got on my plate the following things to measure (when I get a 
spare moment of life, which at this rate may be never):

  - latency/jitter/packet loss on long-haul IAX2 trunks (i.e.: satellite)
  - load testing G.729, ILBC, Speex, and other complex codecs as a 
relative comparative load on a dual 3.0ghz Xeon machine (quantitative 
testing, not seat-of-pants testing)
  - maximal traffic density on 802.11[a,b,g] links with multiple IAX2 
talkers (trunk mode)
  - maximal traffic density on 802.11[a,b,g] links with multiple IAX2 
talkers (normal mode)
  - maximal traffic density on 802.11[a,b,g] links with multiple IAX2 
talkers (routed)
  - maximal traffic density on 802.11[a,b,g] links with multiple SIP 
talkers  (normal)
  - maximal traffic density on 802.11[a,b,g] links with multiple SIP 
talkers  (routed)

JT