[Asterisk-Dev] spike / asterisk hang? <- On a 360MHz CPU - no, 440 :)

[Matt Hess]

response inline..

alex at pilosoft.com wrote:

>On Fri, 15 Jul 2005, Matt Hess wrote:
>
>  
>
>>See that's the thing.. the idle indicator on vmstat never shows the cpu
>>bottom out.. 96 % idle should not be the culprit for the reason why
>>asterisk hangs the audio.. at least in my mind it should not be..  I
>>could understand a high influx of interrupts having an impact like this
>>but system calls and traps? That sure feels/seems less likely to me to
>>be able to literally stop the flow of packets from the system when a
>>call comes in or out.. and I've tested this out extensively.. it is only
>>asterisk packets that stop.. other processes on the system perform as
>>they should.. heck, a ping to a router keeps sending packets when
>>asterisk stops sending it's audio..
>>    
>>
>You are not listening. When the CPU is busy, no audio will be forwarded. 
>Pings are processed in kernel, without context switch, this is a very bad 
>comparison. Asterisk voice frame forwarding happens in the asterisk 
>process.
>
>  
>
Not only am I listening .. I'm trying to _understand_ .. I would think 
that would be encouraged instead of frowned upon..

So I understand clearly here.. a context switch is a way to optimize the 
use of a cpu.. yes? If so then my thinking follows this path:

A context switch basically locks or releases the cpu for use.. (I hope 
I'm right there) is what I am seeing nothing more than several hundred 
grab/releases of the cpu in a matter of milliseconds? If so then, isn't 
there a way of prioritizing the cpu usage in asterisk so that is does 
not interfere with the more important dsp processing that is happening? 
I would prefer a second of call signaling delay over a second of lost 
audio..

>>I strongly believe that there is something more sinister lurking beneath
>>this problem than simply cpu restrictions.
>>    
>>
>How about you try running asterisk on a 2005 hardware.
>  
>
Easier said then done.

>  
>
>>But heck.. I suppose I can just ask this question.. why the heck does
>>asterisk generate so many traps and system calls when processing a call?
>>    
>>
>Because it has to.
>
>  
>
>>When completely idle my asterisk system sees about an average of 70 sys 
>>traps a second.. when a call comes in.. the sys traps alone increase 
>>over a 1000% increase.. and that is to a simple dialplan of just:
>>exten => 401,1,Dial(SIP/401)
>>
>>So I guess my question has morphed into something along the lines of:
>>Why is the dialplan so expensive to parse and has or is any work going
>>into making it more system friendly or efficient?
>>    
>>
>No, it is time to get with the times. Get decent hardware.
>
>-alex
>
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>  
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mhess.vcf
Type: text/x-vcard
Size: 279 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-dev/attachments/20050715/974d2224/mhess.vcf