[Asterisk-Users] 5,000 concurrent calls system rollout question

[Damon Estep]

> -----Original Message-----
> From: asterisk-users-bounces at lists.digium.com [mailto:asterisk-users-
> bounces at lists.digium.com] On Behalf Of Kristian Larsson
> Sent: Wednesday, February 01, 2006 2:49 AM
> To: Asterisk Users Mailing List - Non-Commercial Discussion
> Subject: Re: [Asterisk-Users] 5,000 concurrent calls system rollout
> question
> 
> On Tue, Jan 31, 2006 at 06:29:07PM -0700, Damon Estep wrote:
> >
> >
> > > -----Original Message-----
> > > From: asterisk-users-bounces at lists.digium.com
[mailto:asterisk-users-
> > > bounces at lists.digium.com] On Behalf Of C F
> > > Sent: Tuesday, January 31, 2006 4:03 PM
> > > To: Asterisk Users Mailing List - Non-Commercial Discussion
> > > Subject: Re: [Asterisk-Users] 5,000 concurrent calls system
rollout
> > > question
> > >
> > > I don't know how much 1+1 by you is, but lets recalculate this for
a
> > > moment:
> > > First the bandwidth per channel:
> > > http://www.airewaves.com/aire/support/bandwidth_explain.php
> > > 1.5mbps (mega *BITS* not BYTES per second) to a full T1, which
equals
> > > 1536 Kbits, each channel then takes 64kbps.
> > > 64*5,000=320,000kbps.
> > > 32,000/1,024=312.5 Mbps (round off to Mbps), no where close to a
Gb.
> > > Every single PC made in the last 4 years I came across, can handle
> > > this type of bandwidth.
> > > BTW, this all amounts to just over 39 MBYTES per second.
> > 312.5/8=39.0625
> > >
> >
> > Not that I disagree with your point, the bandwidth is not huge, but
the
> > math is a little fuzzy;
> >
> > First of all, a g.711u stream over UDP is closer 80k than 64k, the
> > payload is 64k + udp overhead + IP overhead.
> >
> > Now consider that the call is originated as SIP (llok back a few
days in
> > the thread), and lets assume the call goes to an external hard or
> > softphone, and lets also assume that there is a reason to keep the
RTP
> > stream running through asterisk (monitoring, recording,
transferring,
> > dtmf, ability to re-enter IVR, etc).
> >
> > I make all the assumptions safely since the thread was started by
> > someone looking to set up a large call center and I have followed
thread
> > out of curiosity.
> >
> > So a 80k full duplex RTP stream originates on media gateway
somewhere,
> > hits the asterisk box, is internally bridged, and is sent back out
to a
> > phone somewhere. My math says this puts a 160kbps full duplex load
in
> > the NIC.
> >
> > Ok, now lets go for 5000 of them. 160kbps*5000=800000kbps or 800mbps
-
> > full duplex.
> >
> > Have you ever seen a NIC or switch that can run GigE full duplex at
80%
> > utilization and not at least start to fall apart?
> No no no.
> 
> First you come to the conclusion that you have
> 800Mbps of traffic, but this is bi directional
> thus 400Mbps in each direction. Then you're
> comparing you're 800Mbps to 1Gbps. If you compare
> bi directional you need to count the card as
> 2Gbps.
> 
> So you are nowhere near 80% but closer to 40%.

Not true, each g.711 call generates 1x 80kps FULL DUPLEX RTP stream, if
the call originates g.711, enters *, gets bridged to another channel,
and goes back out to the phone as an additional g.711 call you are
generating 160 kbps of FULL DUPLEX traffic per call.

160kbps full duplex * 5000 calls IS 800mbps FULL DUPLEX!

Until someone steps up and says "we are currently doing this in a
PRODUCTION environment and it has been working for X months" I will
stand by my opinion that a single chassis 5000 call implementation of *
with RTP streams bridged is IMPOSSIBLE for many reasons, this being one
of them, the interrupt servicing being the next, the cpu load being 3rd,
and so on...

And if it can be done, I would still not do it - too many eggs in one
box. This should be done on 10x high end servers, 500 calls each, no
transcoding, round robin call origination - and even at that - 500 calls
per box will require a 2 to 4 CPU box with GigE NICs

Holy cow - just writing 5000 CDRs in a short time interval will bring a
box to its knees.

There have been many theoretical reasons why it can't be done posted
(including mine), and no "real world experience" posted. There are
reasons for that.

> >
> > To get to a comfortable load you would need 2x GigE NICs (for ~40%
> > utilization), of course now we are adding additional overhead for
the
> > bonded NIC trunking protocol.
> >
> > Is still contend this is not practical without multiple very high
end
> > servers and round robin call origination from the upstream provider
> > delivered over something like GigE or OCx.
> >
> > Maybe someone will step up and post some real-world application
limits
> > based on experience...
> >