[asterisk-bugs] [Asterisk 0012327]: IAX2 out of threads - spinning 100% when frame delivery to * is slow

[noreply at bugs.digium.com]

The following issue has been RESOLVED. 
====================================================================== 
http://bugs.digium.com/view.php?id=12327 
====================================================================== 
Reported By:                xrg
Assigned To:                qwell
====================================================================== 
Project:                    Asterisk
Issue ID:                   12327
Category:                   Channels/chan_iax2
Reproducibility:            sometimes
Severity:                   major
Priority:                   normal
Status:                     resolved
Asterisk Version:           1.4.19-rc3 
SVN Branch (only for SVN checkouts, not tarball releases): N/A 
SVN Revision (number only!):  
Disclaimer on File?:        N/A 
Request Review:              
Resolution:                 duplicate
Duplicate:                  11550
Fixed in Version:           
====================================================================== 
Date Submitted:             03-28-2008 15:00 CDT
Last Modified:              05-06-2008 15:34 CDT
====================================================================== 
Summary:                    IAX2 out of threads - spinning 100% when frame
delivery to * is slow
Description: 
Have managed to narrow the following problem:

Scenario: We have an IAX2 call bridged to some (SIP) slow channel. Then,
after some packets are queued, we see them piling up in the IAX2 channel,
causing it to race (100% CPU) or even use up all its threads (marked as
func="socket_process"). The sound then gets choppy and call may be cut.

Setup:  call --> <IAX2+jb> --> [* box ] --> <slow SIP link>
 cpu is 1.4GHz Athlon, speex -> ilbc conversions also require cpu

Problem: IAX2 uses a non-blocking multi-thread read fn() which processes
the frames and tries to deliver them to the * core in iax2_queue_frame(..)
. There, it tries to aquire the channel lock and, if not, pauses for 1usec.
That is not enough on slow systems, and actually the spinning CPU may
throttle the delivery of the frames (thus causing them to bottleneck).

Temp solution: in chan_iax2.c:1443 increase the usleep(1) to
usleep(100)..


======================================================================
Relationships       ID      Summary
----------------------------------------------------------------------
duplicate of        0011550 Prodding channel... causes 100% utiliza...
====================================================================== 

---------------------------------------------------------------------- 
 qwell - 05-06-08 15:34  
---------------------------------------------------------------------- 
Since http://bugs.digium.com/view.php?id=11550 was fixed, I'm going to go ahead
and close this.  If 1.4.20 or
later shows the same behavior, please reopen this issue. 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
05-06-08 15:34  qwell          Note Added: 0086496                          
======================================================================