[asterisk-dev] Asterisk scalability

Abdul Hakeem alhakeem at gmail.com
Fri Feb 20 07:48:51 CST 2009


Ian,
 
Did you make any modifications in the kernel to achieve IMpps per interface
?
I will appreciate any pointers.
 
Best regards,
Abdul Hakeem

  _____  

Ian FREISLICH <ianf at clue.co.za> writes:

> 80kpps is not that much.  I have machines capable of handling just
> shy of 1Mpps on 1 physical interface, the main problem is the
> physical medium.  My measured max rate on 100M ethernet is 148kpps
> using UDP with a payload of 1 byte.  You should be able to get that
> packet rate in on gigE with a real-world payload.



The challenge is that the 80kpps have to go all the way to user space
and back out to a different ethernet interface. The packets are spread
across 1600 streams, making for lousy cache behaviour when threaded,
and timing is worst-case (each stream gets a packet every 20ms).





So that suggests an optimisation in the path from kernel to user space and
back again - which is some sort of super-recvfrom which can collect ALL the
received data across all the RTP sockets in one big read.  The kernel can
queue all the data into a buffer as it arrives and that data can all be
passed to Asterisk in one go.


Perhaps on the Asterisk side a pool of RTP-router-threads can each use a
system call like this to read data from a few hundred sockets, then process
all those received RTP packets into corresponding output buffer which then
passed back to the kernel via super-send.


Add in any necessary processing for dsp etc and Bob's your uncle.

You'd use a pool of threads so that you had at least one RTP-router-thread
for each CPU.


You'd end up essentially doing 50 system calls per sec per CPU to get all
the data from the kernel into Asterisk and 50 to write the outgoing data.


Obviously there is lots of hand-waving here, and I've probably reinvented
something that is already available in the kernel - in which case someone
please enlighten me.


For IAX it all arrives on one socket anyway - so its just a matter of being
able to get it all out of the kernel in one big read.


We're still going to and from userspace all the time, as opposed to efforts
to do the whole job in the kernel, but I'm sure there is performance to be
gained here, without losing the flexibility that Asterisk's multi-protocol
architecture brings.


And /me waves at Ian.



Regards,
Steve Davies


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20090220/7b1bebf2/attachment.htm 


More information about the asterisk-dev mailing list