On 10/11/2011 03:33 PM, Eric Dumazet wrote: > Le mardi 11 octobre 2011 à 15:11 +0200, David Täht a écrit : >> Of course, it would help if I posted a link to the screenshots! >> >> http://www.teklibre.com/~d/sackoddity/ >> >> On 10/11/2011 03:09 PM, David Täht wrote: >>> I have put up screenshots of tcptrace -G and xplot.org's analysis of my >>> most recent capture of an ipv6 connection over freebox (wired) from a >>> debloat-testing kernel here in france (pre 3.1 by a lot) to a 2.6.16 >>> kernel (the aformentioned netsonar box) in redwood city, ca, both >>> running tcp cubic, over ipv6. >>> >>> at first glance, it looked a lot like a classic bufferbloat trace, with >>> complete with periodic collapses and cubic increasing the window. >>> >>> Then I noticed the sacks. >>> >>> I also have a trace taken between the debloat-testing box and a cerowrt >>> box (running linux 3.04), both running westwood, which shows >>> considerably less undesirable behavior, and I will repeat that test with >>> cubic this evening and post additional data tomorrow morning. > > Who is the sender ? The laptop was the netperf initiator, running 3.1.0-rc4-dbt23 #1 SMP PREEMPT. This is basically 3.1-rc4 + the very few debloat-testing patches which are all specific to wifi. I can easily test against 2.6.38, and with a little work, against linux git head, on the laptop. sysctl on the laptop side is: net.ipv4.tcp_ecn=1 net.ipv4.tcp_sack=1 net.ipv4.tcp_dsack=1 net.core.rmem_max = 2097152 net.core.wmem_max = 2097152 net.ipv4.tcp_rmem = 4096 87380 2097152 net.ipv4.tcp_wmem = 4096 65536 2097152 on the netsonar side remotely (2.6.16), it is whatever the defaults are. Updating a server in bloatlab #1 in California is a little harder, as you might imagine, but I should be able to get that done by next week. > Is some WIFI involved ? No. > "netstat -s" on the receiver would help > I will rerun the tests. > This might be a truesize mismatch. > > I saw those patches being discussed but do not understand the implications. -- Dave Täht