On Sun, 11 Sep 2005, Andrew Kohlsmith wrote: > On Sunday 11 September 2005 22:28, Derek Smithies wrote: > > You see, implementing IAX2 as is done is asterisk is unfortunate, cause > > there is a serious bottle neck at the reception and transmission of > > packets. The receive thread has to do reception and decoding of the > > packets, leaving insufficient time to do correctly receive all packets. > > I'm not sure I understand. > > If there is CPU starvation with a single-threaded IAX decoder how is adding > more overhead (thread switches) going to help out? I can see how it could > help on a multiprocessor system but yet still I'm not so sure, as you're > still fighting over resources (memory and network) and no amount of CPUs or > threads are going to help with that. > > Where exactly are you seeing these starvation issues? I have to say I > haven't > noticed any quality issues with IAX2, but then again I guess I'm just not > hitting the level of CPU usage that this becomes a problem. Do you have > packet dumps/audio files that show this?
Sorry, I cannot provide you with concrete evidence. I am basing my comments on information I gathered at the German Unix Users Group conference at the start of this year, comments from Brian West, (indeed you will have seen his previous email), and reading reviews from the web. A)It is 100% clear that there are no design flaws (that would influence quality) in IAX2. B)Several people (each with businesses providing asterisk services) have reported that asterisk IAX2 does not work well on multi CPU machines. They report audio dropouts. C)The time to do a thread switch arguement is nonsense. Recent kernels report thread switching times well under a microsecond. Sure, it was a problem with 2.0 kernels. Things have moved on. D)A review of the asterisk IAX2 code shows that the receive thread does a lot of work. The iax2 channel consists of two threads, which handles all of the current iax2 calls. One thread is for reading, one is for writing. Thus, one thread will read in all iax2 frames, process them, and pass them on to the queues (as used by the * core). The other thread will pick the packets of the queues, process, and transmit. This is O.K, until you realise that if the core locks the queues, the read&write threads are totally locked, and no sending can happen. By using more threads to do the read/write process, would not stop the entire read/write process by a mutex on the queues. E)Jitter buffers. There does not seem to be a uniform approach to jitter buffers in asterisk. IAX2, SIP and H.323 all appear to have quite different approacches to this problem - why not one jitter buffer for all ? In IAx2, it relies uppon the computer (with software timers) to correctly deliver the packets. Software timers are not, in my view, reliable enough for this task - particularly when the box is loaded.... Derek. -- Derek Smithies Ph.D. Any fool can write code that IndraNet Technologies Ltd. a computer can understand. Email: [EMAIL PROTECTED] Good programmers write code ph +64 3 365 6485 that humans can understand. Web: http://www.indranet-technologies.com/ Martin Fowler _______________________________________________ Asterisk-Dev mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
