[asterisk-dev] Streamlining RTP code.

[Roy Sigurd Karlsbakk]

hi

if you try to monitor the system while doing this, you will most  
probably find that the time spent is not spent within asterisk  
directly, but in the linux system (kernel space). we have done quite  
a few tests on this, and found that the problem is context switching  
between user- and kernelspace, calls to recvfrom() and sendto() etc.  
monitoring the system with oprofile shows exactly this as well.  
talking to some kernel hacker, i was told this was a common problem  
with linux and telephony, and the only possibility that guy knew to  
bypass this was to hack it up with mmapped libpcap, which is rather  
ugly, but quite possibly very fast.

roy

On Jul 11, 2006, at 6:20 PM, Constantine Filin wrote:

> Greetings,
>
> I am looking into channel.c of asterisk version 1.2.9 and trying to  
> figure out what can be changed
> to increase asterisk ability to handle large RTP volume. As it is  
> this code can sustain about 20
> simultaneous calls on a Pentium 2 (not a top of the line, I know)  
> but I would like to increase this
> number.
>
> I have a couple of ideas how the performance can be optimized and  
> would like to run it by the
> rest of the list of see if someone was already moving in this  
> direction and has code prototypes.
> Otherwise I just solicit any comments.
>
> So.
>
> 1) Right now RTP bridging happens in channel.c in function  
> "ast_generic_bridge". This function
>     calls "ast_waitfor_n" to see where the next packet comes from,  
> then reads from it and
>     does "ast_write" to write RTP to the other channel.
>
>     The problem with "ast_waitfor_n" is that it can only report a  
> single channel as the winner,
>     whereas it is quite possible that the packets from both  
> channels are waiting to be handled.
>     If "ast_waitfor_n" (or another function) is changed to return  
> an array of winners, then this can
>     shave off quite a bit of CPU cycles and increase the  
> performance. Of course the rest of
>     "ast_generic_bridge" has to be modified to work with several  
> winners.
>
> 2) I am seeing in frame.c a TODO comment next to "ast_frfree":
>
> /*!
>  * \todo Important: I should be made more efficient.  Frame headers  
> should
>  * most definitely be cached
>  */
>
>    The thing is that this comment has been in the code for more  
> than a year already and
>    nobody has gotten it done. I am wondering if this is just lack  
> of time or there is a more
>    fundamental difficulty behind caching the frame headers? Caching  
> frame headers will
>    definitely add to the performance.
>
> Another big architectural issue I am trying to wrap my mind around  
> is multiple PBX threads.
> Having 20 threads on a Pentium II doing RTP I/O pretty much starves  
> off other threads in
> the process (e.g. SIP thread or Zap thread). Has anyone been  
> thinking about RTP I/O
> multiplexing in PBX?
>
> Please let me know your ideas about this and let me know if I am  
> looking into the right
> direction. What else can be done to increase the RTP performance?
>
> Respectfully
>
> Constantine.
>
>
> !DSPAM:44b3ee52319061918396396!
> _______________________________________________
> --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
>
>
> !DSPAM:44b3ee52319061918396396!

--
Roy Sigurd Karlsbakk
roy at karlsbakk.net
(+47) 98013356
---
In space, loud sounds, like explosions, are even louder because there  
is no air to get in the way.