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

[Jim Van Meggelen]

asterisk-dev-bounces at lists.digium.com wrote:
> 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..

It is encouraged! 

But what you are talking about is more of an intellectual exercise than
a problem with Asterisk. Therefore, you may find that the -dev list is
going to suggests to you that this is more a -user list question.
Really, take it to -users, and you may find that a lively and productive
conversation ensures (no guarantee, but there are lots of folks that
love running Asterisk on marginal hardware). I run Asterisk on Soekris
boxes (AstLinux r001z and all that), and they have far less power than
yer SPARC does. What I don't do is try and shove 15 calls through it. .
. . actually, I think I'm gonna try . . . 

But I digress.

I met a guy at Astricon who was very interested in optimizing Asterisk
for the SPARC. He knew, however, that it wasn't going to be a trivial
job, and he certainly wasn't going to try and run it through -dev, at
least not until he'd gotten most of the work done.

> 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.

Fair enough. But tweaking Asterisk to run on your 450MHz SPARC is also
easier said than done. The argument here is that what we suggest (new
hardware) is far easier than what you suggest (comb through the code
looking for tweaks that'll put the spark back in your SPARC).

Probably no one disagrees with you that it is an interesting challenge,
it's just not really relevant to the current development effort.

>>> 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.

Well, perhaps not "decent hardware" so much as: 
Be aware of the performance requirements of Asterisk, and budget for
hardware that will a) handle your anticipated growth, and b) be easy to
get support for.

If you want to run unusual hardware, you are more likely to get positive
than negative responses from the community (as in: "Asterisk on a WRT?
How cool!"). 

BUT

If you want to make your decision to push the envelope something the
community is responsible to address, you may find some resistance.

Regards,

Jim.

--
Jim Van Meggelen
jim at vanmeggelen.ca
www.oreillynet.com/cs/catalog/view/au/2177

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.323 / Virus Database: 267.8.15/49 - Release Date:
14/07/2005