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