Donald Becker wrote: > > On Sun, 14 Oct 2001, Manfred Spraul wrote: > > > I've cleaned up the winbond-840 interrupt handler and added a very > > simple interrupt avoidance scheme: > > "Cleaned up"?? Uhmm, that's certainly not cleaner. > It's an _experimental_ patch, definitively not for inclusion. I had to find another chipset bug with the hw timer, and I think that the old code was incorrect if PCI writes were posted. > Also, keep in mind that the winbond-840 driver is a special case. The > Tx FIFO limit circuitry is broken on some chips. The driver must > explicitly limit how many bytes are permitted into the on-chip FIFO to > avoid transmit corruption. > Yes, I agree. I can reproduce the corruption. > > Result: > > single stream tcp receive performance up from 9.2 MB/sec to 10.5 MB/sec > > (mtu 1500). > > MTU=1500 at 100Mbps should never be an interesting case. A P5-100 > system could handle 2-3 full-rate 100Mbps connections. > Cyrix P-120. Due to the tx bug it's not fast enough to handle 100Mbps. > > In both cases, 0 packet drops (as expected - one tcp streams with a > > window of 64 kB and a 64 entry rx queue makes packet drops impossible) > > > > IMHO that shows that packet drops are not the right sign when to switch > > on interrupt mitigation - packets aren't dropped, > > This should be obvious: making a long Rx ring will prevent packets from > being dropped. However that same long Rx will prevent the appropriate > packets from being dropped when the system is overloaded. > A single tcp stream with a cross-over cable never pushes the receiver to the point of dropping packets. Instead user space is starved, the packets remain in the rx queue and the window size goes to 0. Then the sender stopps sending packets. > > instead the tcp sender > > just sends packets slower and performance goes down. > > Isn't that the desired effect? > Specifically: dropping packets is sometimes the correct way to indicate > TCP congestion. > There is no real system overload. ~ 4000 superflous interupts/sec waste lots of cpu time. Avoiding these interrupts increases the transfer rate (9MB to 10 MB with MTU=1500, IIRC 3 MB to 4 MB with MTU=600). IMHO the network drivers need a helper function that tells them when to switch on interrupt mitigation. "Are packets dropped" or "is the backlog queue too long" are not the right tests - these tests are only correct for routers, not when a user space application wants cpu time to work with the received data. I would propose a fixed rate limit, but I'll try out other algorithms. -- Manfred - : send the line "unsubscribe linux-net" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
