<br><br><div><span class="gmail_quote">On 3/4/07, <b class="gmail_sendername">Kevin P. Fleming</b> <<a href="mailto:kpfleming@digium.com">kpfleming@digium.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Trixter aka Bret McDanel wrote:<br>> instead of much more frequently. I would also like to see interrupts<br>> once per span (possibly per card) as opposed to for each channel. These<br><br>This is how it already works. One interrupt per span per millisecond. If
<br>interrupts were generated for each channel the system would fall apart<br>rapidly with any significant number of spans in it.</blockquote><div><br>for part of what I said, ok I was misinformed. However 1 per ms is still 10-20 times more frequently than is generally needed (there are exceptions but they are generally rare).
<br><br>I also dont think that a DMA ring buffer exists (*please* correct me if I am wrong) so that it doesnt take the cpu to blit the data off the card into ram. That isnt that hard to do, you just write to the bus address specified in the card init, which is a value reserved by the kernel. The card needs to be able to write to those addresses, which since its on the bus it has access it just needs the firmware to allow it.
<br><br>You could fire an interrupt once the buffer is full (for those that dont know in a ring buffer you have multiple buffers that are done like a hunt group, first, second, third, first, ...) which could be say 10ms. This also makes packetization easier, it would generate a lot fewer context switches and generally make a better product capable of handling more on the same box.
<br><br>Zaptel would have to be updated since it doesnt really support that method, instead relying on the 1000 interrupts per second thing instead of 50 per span.<br><br>and for those that would say the memory requirements would be too large, 10ms of
g.711 audio is roughly 6400 bytes per DS0 which would be 150kB per T1 (less if pri, more if E1). In a world of gigs of ram that is a trivial price to pay for the performance gains that would be realized. Even on a ram limited system, the performance gains would likely be higher since they also generally have limited cpu resources to handle all those context switches.
<br></div><br></div><br>-- <br>Trixter <a href="http://www.0xdecafbad.com">http://www.0xdecafbad.com</a> Bret McDanel<br>Belfast +44 28 9099 6461 US +1 516 687 5200<br><a href="http://www.trxtel.com">http://www.trxtel.com
</a> the VoIP provider that pays you!