[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4C448688.1070507@hp.com>
Date: Mon, 19 Jul 2010 10:08:24 -0700
From: Rick Jones <rick.jones2@...com>
To: "H.K. Jerry Chu" <hkjerry.chu@...il.com>
CC: Patrick McManus <mcmanus@...ksong.com>,
David Miller <davem@...emloft.net>, davidsen@....com,
lists@...dgooses.com, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org
Subject: Re: Raise initial congestion window size / speedup slow start?
H.K. Jerry Chu wrote:
> On Fri, Jul 16, 2010 at 10:01 AM, Patrick McManus <mcmanus@...ksong.com> wrote:
>>can you tell us more about the impl concerns of initcwnd stored on the
>>route?
>
>
> We have found two issues when altering initcwnd through the ip route cmd:
> 1. initcwnd is actually capped by sndbuf (i.e., tcp_wmem[1], which is
> defaulted to a small value of 16KB). This problem has been made obscured
> by the TSO code, which fudges the flow control limit (and could be a bug by
> itself).
I'll ask my Emily Litella question of the day and inquire as to why that would
be unique to altering initcwnd via the route?
The slightly less Emily Litella-esque question is why an appliction with a
desire to know it could send more than 16K at one time wouldn't have either
asked via its install docs to have the minimum tweaked (certainly if one is
already tweaking routes...), or "gone all the way" and made an explicit
setsockopt(SO_SNDBUF) call? We are in a realm of applications for which there
was a proposal to allow them to pick their own initcwnd right? Having them pick
an SO_SNDBUF size would seem to be no more to ask.
rick jones
sendbuf_init = max(tcp_mem,initcwnd)?
--
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