[asterisk-biz] IAX Channels limit on Asterisk 1.4.17

[Zoa]

Afaik, removing the multithreading will cause serious other problems, as 
1 operation that might take a little too long and block everything else, 
(e.g. an iax register packet which needs to be verified against some 
external database) might cause delay of more than 20ms, and in those 
20ms no other audio for any other call will get processed).

I have done well over 256 channels, but i think that was back in the 
days when it was without multithreading.

Zoa

Trixter aka Bret McDanel wrote:
> On Tue, 2008-01-15 at 23:31 -0800, Nitzan Kon wrote:
>   
>> After doing some googling I think I found your problem.. if you look in
>> chan_iax2.c you'll see there is a hard-coded limit of 256 channels:
>>     
>
>
> this limit is used in find_idle_thread(), looking there you will see
> that it will first try to get an idle thread, if that fails then it will
> try from the dynamic list, if that fails then it tries to create one
> only if there are available threads.  There is no log entry created if
> it cant make a new thread, especially because of the limit.  So at the
> very least it should say why it cant make a thread.
>
> These threads are made when some action is added to the scheduler, and
> in socket_read().  The scheduler stuff seems a bit dodgy, rather than a
> queue with 1 thread processing the queue, it will assign each scheduled
> event a new thread.  
>
> Because of the way you do things in UDP you cant spawn a new thread for
> each connection on reception, instead you really have to have 1 thread
> that receives all packets for all hosts and deal with them.  TCP is
> different since you have a connected state, you can do like apache.  By
> using 1 port like this, iax gets a bottleneck situation where it will
> have all Rx packets go into a single thread, regardless of the number of
> CPUs/cores you may have in your system.  So this is 1 of that, the
> scheduler is the rest.  
>
> While this may be part of the problem in higher than 256 channel counts,
> its related to the scheduler and not the actual channel limits.  If you
> try to schedule an action (such as a ping, reception from the jitter
> buffer, register, and several other things) you may run out of scheduler
> threads and that would cause a problem.  
>
> The 'multi threaded scheduler' can of course be disabled more easily by
> commenting 
> #define SCHED_MULTITHREADED
> in chan_iax2.c.  
>
> If you do that you will notice that elsewhere in the code it will just
> do stuff as opposed to trying to create a new thread to do it.  This may
> result in that limit being removed, and would easily let you know if its
> the multi-threaded scheduler that is to blame as opposed to something
> else.
>
> I do not know what performance problems may be caused by disabling the
> multithreaded scheduler.  So if you do disable it, testing is certainly
> a good thing.
>
>
>