-- On Fri, 10 Aug 2007, John Sigler wrote: > Hello, Hi John, > > I'd like to describe what I'm trying to do, so people can comment. > > > Any comments so far? Well, some NICs buffer writes, and some even buffer receives. So your NIC may be buffering underneath you too. > > Now all this seems nice in theory, but I'd also like to make it work in > practice! (And I'm having some problems.) > > R is typically 38 Mbit/s => B/R is typically 277 µs > Obviously, I'm going to need high-resolution timers if I want to sleep > for so small an interval. > > As far as I understand, each packet received will generate one IRQ, and > each write to the PCI output device will generate one IRQ. This means > 3600 IRQs per second from the NIC, and 3600 IRQs per second from the PCI > device. Is that reasonable? (Considering a 1267 MHz P3 with no IO-APIC.) As mentioned above, the NIC may buffer too, so it may not be sending the packets out immediately. Usually, a driver would send out several packets before sending a transmit IRQ. In fact, that transmit IRQ is usually so to tell the driver that it can write more after a certain threshold has been reached. (It's been several years since I wrote a NIC driver, so I'm going off of my old memory ;-) > > It is easy to reduce the number of IRQs from the PCI device by grouping > several packets for a single write. It might be worthwhile. May not be needed if the driver already does it. > > One problem I have is that the PCI device's driver blocks until the > device has acknowledged the data, and the write operation sometimes > blocks for 200, 300, even 400 µs (I have not been able to tell why). Not sure what you mean by saying the driver "blocks". Is it a sleeping thread (in -rt) or from an interrupt? Can you be more specific here. > > I might not need -rt, if I'm willing to handle several packets every > time I wake up? For any reaction time less than 100 us (or maybe even higher), you will need -rt. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
