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