[asterisk-dev] rtp scalability improvement...

[Sergey Kuznetsov]

Anton wrote:
> I would say that more than one server is not good, when 
> there is performance issues only. having processing 1000 
> calls/s on fast hardware and good clustering options will 
> bring asterisk to a new usage levels. Industry levels. And 
> possibly Industry would involve it's developers too. In 
> normal case that will lead asterisk to became a monster 
> app, able to do most things needed in telephony :)
>
> In the comparisions of price/performace - Asterisk can 
> win... but total luck of H323 support kills any advantages. 
> MVTS costs $3500 per 30 concurent calls (E1) and I would 
> love to replace it with Asterisk even in cost of extra 
> servers. But as I said - there is no H323 in Asterisk.
>
> Regards,
> Anton
>   

Asterisk works with H323 but crappy. I spent some time to marry 
Asterisk/OH323 with
Cisco Gateway ( not Gatekeeper ). At some moment it starts to work but then
after some time without any interaction it stops to work. It dying in 
Master-Slave determination,
even if signalling part is went thru, and remote side was alerted.
And this is happened with both my H323 providers. The same symptoms.

MVTS mostly signaling switch. I don't think they are trans-coding 
anything and passing any traffic.


PS: As of number of packets sent thru computer:

50 packets per second * 400 channels * 2 in/out = 40 000 packets per second.

Performance dies not because of system calls, but because 20 000 
interruptions/sec happened at that moment.
It's named IRQ poisoning. Because IRQ switching is longer that standard 
task switching.

When you switch from task to kernel in most cases you don't have to 
reload MMU, because kernel
don't care about virtual addresses of task. therefore there is very 
small penalty for that. If you will give real-time
priviledge - it will improve the performance for Asterisk.

When you do IRQ, in that case it's more complicated. But in Linux you 
can emable NAPI if your card allows it
and then it can improve the performance.

It works in such a way:
When first IRQ arrives, IRQ handler disables this IRQ and strarts to 
poll packets within specified quota.
When it's done, it's re-enables IRQ, and returns back to the task. This 
eliminates IRQ switching overhead and can improve
the performance and number of channels.


All the Best!
Sergey.