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

[Andrew Kohlsmith]

On Friday 15 July 2005 15:04, Matt Hess wrote:
> It's a 440 actually ;) ..  1G ram. I surely thought a sparc would handle
> more than it seems to.. but I feel this may very well be a dev issue if
> looked into further.. I'll explain as I go..

Remember that all of Asterisk's DSP work is done on the CPU.  I am not sure 
how optimized the Sparc port of GCC is and how strong the Sparc FPU is.  
Asterisk does a LOT more than just toss packets around.

> 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

You will likely never see the CPU bottom out with 1s granularity on ps.

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

Again -- Asterisk is doing far more than tossing packets around.  You're not 
making much of a comparison.  You're not just DMAing data from disk or RAM 
and tossing it out an interface.  You're computing fairly heavy formulas on 
data gathered from other sources and generating entirely new datasets and 
spitting THAT off.  

Also remember that Asterisk data is timely and needs to be processed with 
damn-near real time performance.  Your webserver traffic most certainly is 
not.

> I strongly believe that there is something more sinister lurking beneath
> this problem than simply cpu restrictions.

Given that this is such a small priority for the Asterisk community at large, 
I feel you'll have a very difficult time convincing Digium or anyone to 
bother scratching this itch.  If, however, this is enough of an itch for you 
to dive in... well the more people who are familliar with the intracasies of 
Asterisk, the better!

> I've got an identical system acting as a router..

red herring.  A router is not a realtime data processing platform.  Asterisk 
is.

> So that's 0 idle cpu.. 6k ints a second and it was with me running an
> ntop process on it.. the thing didn't even bat an eyelash at the load..
> 7.4 Mbps in+out was being passed at that time.. yet pings through it
> only had a 0.679 ms std-dev to a popular webserver across several ip
> providers. (I should note again the reason the cpu was at zero idle was
> that I was beating up the system with ntop)

Again, I bet those packets being tossed from interface to interface have 
hardly any CPU time on them.  VOIP packets are quite different unless they're 
just being passed through.

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

The *entire* idea behind Zapata is that host CPU is cheap.  It's *designed* to 
be run on heavy CPUs because they're cheaper than proprietary DSPs and 
on-card solutions.  You are misapplying Asterisk.

-A.