On Monday 12 September 2005 00:34, Derek Smithies wrote: > 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.
I wasn't saying it was taking hundreds of miliseconds to switch a thread. I was saying "If the CPU's punked out what's adding MORE overhead going to help?" You did, however explain it in D) below: > 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.... If the box is loaded then you will have all kinds of other problems in addition to the timers shifting. I don't think any kind of hard timer source is going to help. Asterisk is *very* dependent on the host CPU being able to do things in a near-realtime fashion. I worked with Steve Kann on the IAX2 jitter buffer implementation. (Ok, he did all of the work and I provided half-assed bug reports, let me have my 15 mintues, ok? :-)) -- the JB is quite abstracted from the channel driver, and it was my understanding that it was done this way *specifically* to facilitate its being used in any channel technology which could benefit from it. -A. _______________________________________________ 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
