On Tuesday, 13 בFebruary 2007 14:56, Andrew Kohlsmith wrote: > Yes, granted, still not ideal, but a lot better than the original > estimates. :-)
The estimates I did meant to show that even with many channels the volume of data copied (16Mb / 1000 channels) is minuscule load in comparison with the interrupt load. You are right that using *only* quad-PRI cards (and assuming we don't need *any* analog lines) you can get a result ~4 times better. (~8000/sec without counting context switches due to transmit paths). Still, even with your optimal setup it's the interrupt load and not the data copies that dominates the performance of the host. In a previous post, regarding my example of NAPI: > ...Yes, and it shot latency right to hell by saving all these interrupts. 1. I mentioned NAPI only to show a real life example where many experienced people thought that zero-copy would be a win, while the real performance boost came from another front. 2. Going from 1ms*8bytes ticks to 10ms*80bytes ticks (for example), would reduce interrupt load ten-fold even without going to polling mode of operation. People do not notice a 10ms latency as long as the jitter is kept low. 3. As Tzafrir mentioned, many of us are doing also VOIP. Care to check the average latency of a typical RTP stream? > True; perhaps it's time to dig out some code and see what happens if you > disable interrupts on Zaptel and use ztdummy with hires timers to poll real > hardware. :-) This is good idea, but the bigest win IMHO is increasing the tick intervals from 1ms ten or twenty fold (more than that start to become a latency problem since people can hear it). -- Oron Peled Voice/Fax: +972-4-8228492 [EMAIL PROTECTED] http://www.actcom.co.il/~oron ICQ UIN: 16527398 "... one of the main causes of the fall of the Roman Empire was that, lacking zero, they had no way to indicate successful termination of their C programs." -- Robert Firth _______________________________________________ --Bandwidth and Colocation provided by Easynews.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
