[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <480F64B2.7060608@hp.com>
Date: Wed, 23 Apr 2008 09:32:50 -0700
From: Rick Jones <rick.jones2@...com>
To: David Miller <davem@...emloft.net>
CC: johnwheffner@...il.com, netdev@...r.kernel.org
Subject: Re: Socket buffer sizes with autotuning
David Miller wrote:
> From: "John Heffner" <johnwheffner@...il.com>
> Date: Tue, 22 Apr 2008 19:17:39 -0700
>
>
>>On Tue, Apr 22, 2008 at 5:38 PM, Rick Jones <rick.jones2@...com> wrote:
>>
>>> oslowest:~# netstat -an | grep ESTAB
>>> ...
>>> tcp 0 2760560 10.208.0.1:40500 10.208.0.45:42049 ESTABLISHED
>>> ...
>>>
>>> Is this expected behaviour?
>>
>>What is your interface txqueuelen and mtu?
1000, MTU 1500 and TSO is enabled.
>> If you have a very large interface queue, TCP will happily fill it
>> up unless you are using a delay-based congestion controller.
At the same time, the sender will not try to send any more than the
receiver is willing to advertise as window.
> Yes, that's the fundamental problem with loss based congestion
> control. If there are any queues in the path, TCP will fill them up.
>
> Vegas and other similar techniques are able to avoid this, but come
> with the fundamental flaw that it's easy to get them into situations
> where they do not respond to increases in pipe space adequately, and
> thus underperform compared to loss based algorithms.
I can see that for the sending side being willing to send into the
receiver's ever increasing window, but is autotuning supposed to keep
growing and growing the receive window the way it seems to be?
rick jones
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists