[asterisk-dev] rtp scalability improvement...

[Anton]

Hi!

I would just exoress my oppinion regardin the call volumes 
and the call switching core. 400 calls seems for me to be 
not so much good number and even "comodity" hardware with 
proper approach should be able to process more calls even 
WITHOUT sacrifing kerner routing/packet processing stuff. 
For example We're operating commecial VOIP H323 softswitch, 
which is currently run on the ordinary P4 with 1Mb RAM - 
this one could switch more than 500 simultaneous calls per 
second (MVTS) and with Dual-head XEON it claims to be able 
to do more than 1500 calls/s. Not arguably this one does 
not such features as Asterisk does, but from one side it is 
not supposed to have. From another, the mentione tests with 
Asterisk used only PASSTHROUGH switching functions of the 
asterisk - so 400 calls not too bad, but I do thing that 
Single Xeon should be able to process more than 1000 
concurrent calls with SIP. H323 is more CPU intensive. 
One more point voting for looking for extra scalability - is 
that Asterisk potentially could be used even as switching 
core while running not even PBX but normal PSTN - but 
scalability is the stone on the way. Seems someone objects 
Asterisk growth to a potential competitor to a proprietary 
solutions...

Regards,
Anton.

On 20 March 2006 02:57, Andrew Kohlsmith wrote:
> On Sunday 19 March 2006 16:01, Roy Sigurd Karlsbakk wrote:
> > After some discussion on #kernelnewbies on
> > irc.oftc.net, one whos nick is 'ahu' told me this was
> > 'because of heavy switching', too many system calls
> > etc. he mentioned using mmapped libpcap as a dirty hack
> > that would allow packets to move into userspace without
> > any system call at all.
>
> I ran this by my kernel-hacker friend and he largely
> agreed, but suggested performing this dirty hack and
> profiling it just to see what happens.
>
> My own thoughts are that mmaping pcap in this manner
> largely bypasses many of the things that the kernel can
> do to packets (which is the point) but you need to be
> careful because you can lose a lot of the functionality
> you may have been expecting if you are relying on any
> advanced routing or processing. However, I imagine that
> the people interested in doing this have any packet
> processing done on separate routers, so the point's moot.
>
> To me, 400 calls on a single Xeon seems like a pretty
> good balance between scalability and performance...  this
> is all commodity hardware, remember.  I wonder, Roy, what
> the bandwidth and packet levels were like.  (i.e. what
> did the network look like?)
>
> -A.
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev