[asterisk-dev] Re: Kernel modules => mainline kernel
Oron Peled
oron at actcom.co.il
Tue Feb 13 14:39:42 MST 2007
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
oron at actcom.co.il 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
More information about the asterisk-dev
mailing list