Van Jacobson had a nice talk recently on the subject of making networking faster on modern architectures. See:<br>
<br>
<a href="http://lwn.net/Articles/169961/">http://lwn.net/Articles/169961/</a><br><br><div><span class="gmail_quote">On 3/19/06, <b class="gmail_sendername">Sergey Kuznetsov</b> <<a href="mailto:asterisk_biz@deeptown.org">
asterisk_biz@deeptown.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Anton wrote:<br>> I would say that more than one server is not good, when
<br>> there is performance issues only. having processing 1000<br>> calls/s on fast hardware and good clustering options will<br>> bring asterisk to a new usage levels. Industry levels. And<br>> possibly Industry would involve it's developers too. In
<br>> normal case that will lead asterisk to became a monster<br>> app, able to do most things needed in telephony :)<br>><br>> In the comparisions of price/performace - Asterisk can<br>> win... but total luck of H323 support kills any advantages.
<br>> MVTS costs $3500 per 30 concurent calls (E1) and I would<br>> love to replace it with Asterisk even in cost of extra<br>> servers. But as I said - there is no H323 in Asterisk.<br>><br>> Regards,<br>> Anton
<br>><br><br>Asterisk works with H323 but crappy. I spent some time to marry<br>Asterisk/OH323 with<br>Cisco Gateway ( not Gatekeeper ). At some moment it starts to work but then<br>after some time without any interaction it stops to work. It dying in
<br>Master-Slave determination,<br>even if signalling part is went thru, and remote side was alerted.<br>And this is happened with both my H323 providers. The same symptoms.<br><br>MVTS mostly signaling switch. I don't think they are trans-coding
<br>anything and passing any traffic.<br><br><br>PS: As of number of packets sent thru computer:<br><br>50 packets per second * 400 channels * 2 in/out = 40 000 packets per second.<br><br>Performance dies not because of system calls, but because 20 000
<br>interruptions/sec happened at that moment.<br>It's named IRQ poisoning. Because IRQ switching is longer that standard<br>task switching.<br><br>When you switch from task to kernel in most cases you don't have to<br>reload MMU, because kernel
<br>don't care about virtual addresses of task. therefore there is very<br>small penalty for that. If you will give real-time<br>priviledge - it will improve the performance for Asterisk.<br><br>When you do IRQ, in that case it's more complicated. But in Linux you
<br>can emable NAPI if your card allows it<br>and then it can improve the performance.<br><br>It works in such a way:<br>When first IRQ arrives, IRQ handler disables this IRQ and strarts to<br>poll packets within specified quota.
<br>When it's done, it's re-enables IRQ, and returns back to the task. This<br>eliminates IRQ switching overhead and can improve<br>the performance and number of channels.<br><br><br>All the Best!<br>Sergey.<br><br>_______________________________________________
<br>--Bandwidth and Colocation provided by <a href="http://Easynews.com">Easynews.com</a> --<br><br>asterisk-dev mailing list<br>To UNSUBSCRIBE or update options visit:<br> <a href="http://lists.digium.com/mailman/listinfo/asterisk-dev">
http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br>Mike Taht<br>PostCards From the Bleeding Edge<br><a href="http://the-edge.blogspot.com">http://the-edge.blogspot.com
</a>