Messages in this thread | | | Subject | Re: [PATCH 2.6.30-rc4] r8169: avoid losing MSI interrupts | From | David Dillow <> | Date | Sat, 23 May 2009 10:51:48 -0400 |
| |
On Sat, 2009-05-23 at 16:35 +0200, Michael Riepe wrote: > Hi! > > Michael Buesch wrote: > > > Thanks a lot, Dave! This fixes the issue on my chip. > > Yep, it's stable here as well. And even a little faster than pci=nomsi. > The only strangeness I observed is that the throughput (measured with > iperf and a single TCP connection) varies: > > [ ID] Interval Transfer Bandwidth > [ 3] 0.0-10.0 sec 667 MBytes 559 Mbits/sec > [ 3] 10.0-20.0 sec 803 MBytes 673 Mbits/sec > [ 3] 20.0-30.0 sec 802 MBytes 673 Mbits/sec > [ 3] 30.0-40.0 sec 714 MBytes 599 Mbits/sec > [ 3] 40.0-50.0 sec 669 MBytes 561 Mbits/sec > [ 3] 50.0-60.0 sec 791 MBytes 663 Mbits/sec > [ 3] 0.0-60.0 sec 4.34 GBytes 622 Mbits/sec > [snip] > I suppose it's a side effect of the MSI acknowledgement loop. But who am > I to complain about higher average throughput? ;-)
I wonder if that is the TCP sawtooth pattern -- run up until we drop packets, drop off, repeat. I thought newer congestion algorithms would help with that, but I've not kept up, this may be another red-herring -- like the bisection into genirq.
A tcpdump may answer the question -- wireshark can do an analysis and see if it is running up until it starts dropping or something.
Or it may be the loop, but I wouldn't expect it to make such a big difference, or be as variable if it does.
Also, what does it look like with multiple streams?
Thanks for testing guys -- I'm glad it works for a sample size > 1!
Dave
| |