From: "John Heffner" <johnwheffner@gmail.com>
To: "Rick Jones" <rick.jones2@hp.com>
Cc: "David Miller" <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: Socket buffer sizes with autotuning
Date: Wed, 23 Apr 2008 10:41:45 -0700 [thread overview]
Message-ID: <1e41a3230804231041x6fc7cba7pd73447201faf555d@mail.gmail.com> (raw)
In-Reply-To: <480F70C9.7010004@hp.com>
On Wed, Apr 23, 2008 at 10:24 AM, Rick Jones <rick.jones2@hp.com> wrote:
> John Heffner wrote:
> > Receive-side autotuning by design will attempt to grow the rcvbuf
> > (adjusting for overhead) to twice the observed cwnd[1]. When the
> > sender keeps growing its window to fill up your interface queue, the
> > receiver will continue to grow its window to let the sender do what it
> > wants. It's not the receiver's job to do congestion control.
> >
>
> Then why is it starting small and growing the advertised window?
Because the receiver tracks the sender's behavior. (Also because of
the algorithm for figuring out the buffer overhead ratio, but that's a
different story.)
> What concerns me is that we tell folks to rely on autotuning because it
> will set their socket buffers to the size they need, but it seems to be
> setting their socket buffers to very much more than they need. Given that
> netperf couldn't have been receiving any more data in an RTT if it was
> always going at ~940 Mbit/s I'm still perplexed unless there is a positive
> feedback here - allow a greater window, this allows more data to be queued,
> which increases the RTT, which allows more data to be recevied in an "RTT"
> which allows a greater window...
It's true that careful hand-tuning can do better than autotuning in
some cases, due to the sub-optimality of congestion control. This is
one such case, where you have an overbuffered bottleneck. Another
case is where you have an underbuffered bottleneck, especially with a
large BDP. You can calculate exactly the window size you need to fill
the bottleneck and set your send or receive buffer to throttle you to
exactly that window, so that you will get 100% utilization. If you
let autotuning work, it will keep increasing your buffer as congestion
control asks for more until you overflow the buffer and take a loss.
Then, congestion control will have to back off, likely resulting in
under-utilization.
In these cases, hand-tuning can do better because you have out-of-band
knowledge of the path. Also, smarter congestion control algorithms
can do better than traditional AIMD, but it's a very hard problem to
do this well in general. Autotuning's job is mainly just to grow the
buffer sizes to as much as congestion control needs to do its thing.
-John
next prev parent reply other threads:[~2008-04-23 17:41 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-23 0:38 Socket buffer sizes with autotuning Rick Jones
2008-04-23 2:17 ` John Heffner
2008-04-23 3:59 ` David Miller
2008-04-23 16:32 ` Rick Jones
2008-04-23 16:58 ` John Heffner
2008-04-23 17:24 ` Rick Jones
2008-04-23 17:41 ` John Heffner [this message]
2008-04-23 17:46 ` Rick Jones
2008-04-24 22:21 ` Andi Kleen
2008-04-24 22:39 ` John Heffner
2008-04-25 1:28 ` David Miller
[not found] ` <65634d660804242234w66455bedve44801a98e3de9d9@mail.gmail.com>
2008-04-25 6:36 ` David Miller
2008-04-25 7:42 ` Tom Herbert
2008-04-25 7:46 ` David Miller
2008-04-28 17:51 ` Tom Herbert
-- strict thread matches above, loose matches on Subject: below --
2008-04-23 23:29 Jerry Chu
2008-04-24 16:32 ` John Heffner
2008-04-25 0:49 ` Jerry Chu
2008-04-25 6:46 ` David Miller
2008-04-25 21:29 ` Jerry Chu
2008-04-25 21:35 ` David Miller
2008-04-28 18:30 ` Jerry Chu
2008-04-28 19:21 ` John Heffner
2008-04-28 20:44 ` Jerry Chu
[not found] ` <d1c2719f0804281338j3984cf2bga31def0c2c1192a1@mail.gmail.com>
2008-04-28 23:28 ` John Heffner
2008-04-28 23:35 ` David Miller
2008-04-29 2:20 ` Jerry Chu
2008-04-25 7:05 ` David Miller
2008-05-07 3:57 ` Jerry Chu
2008-05-07 4:27 ` David Miller
2008-05-07 18:36 ` Jerry Chu
2008-05-07 21:18 ` David Miller
2008-05-08 1:37 ` Jerry Chu
2008-05-08 1:43 ` David Miller
2008-05-08 3:33 ` Jerry Chu
2008-05-12 22:22 ` Jerry Chu
2008-05-12 22:29 ` David Miller
2008-05-12 22:31 ` David Miller
2008-05-13 3:56 ` Jerry Chu
2008-05-13 3:58 ` David Miller
2008-05-13 4:00 ` Jerry Chu
2008-05-13 4:02 ` David Miller
2008-05-17 1:13 ` Jerry Chu
2008-05-17 1:29 ` David Miller
2008-05-17 1:47 ` Jerry Chu
2008-05-12 22:58 ` Jerry Chu
2008-05-12 23:01 ` David Miller
2008-05-07 4:28 ` David Miller
2008-05-07 18:54 ` Jerry Chu
2008-05-07 21:20 ` David Miller
2008-05-08 0:16 ` Jerry Chu
[not found] <d1c2719f0804241829s1bc3f41ejf7ebbff73ed96578@mail.gmail.com>
2008-04-25 7:06 ` Andi Kleen
2008-04-25 7:28 ` David Miller
2008-04-25 7:48 ` Andi Kleen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1e41a3230804231041x6fc7cba7pd73447201faf555d@mail.gmail.com \
--to=johnwheffner@gmail.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=rick.jones2@hp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).