From: Jonathan Morton <chromatix99@gmail.com>
To: Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>
Cc: bloat-devel <bloat-devel@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>
Subject: Re: using tcp_notsent_lowat in various apps?
Date: Fri, 19 Jun 2015 07:07:56 +0300 [thread overview]
Message-ID: <6644BD81-1FFC-450C-89FD-91E138B7824A@gmail.com> (raw)
In-Reply-To: <87y4jgbejc.wl-jch@pps.univ-paris-diderot.fr>
> On 19 Jun, 2015, at 05:47, Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr> wrote:
>
>> I am curious if anyone has tried this new socket option in appropriate apps,
>
> I'm probably confused, but I don't see how this is different from setting SO_SNDBUF. I realise that's lower in the stack, but it should have a similar effect, shouldn't it?
What I understand of it is:
Reducing SO_SNDBUF causes send() to block until all of the data can be accommodated in the smaller buffer. But select() will return the socket as soon as there is *any* space in that buffer to stuff data into.
TCP_NOTSENT_LOWAT causes select() to not return the socket until the data in the buffer falls below the mark, which may (and should) be a mere fraction of the total buffer size.
It’s a subtle difference, but worth noting. The two options effectively apply to completely different system calls.
You could use both in the same program, but generally SO_SNDBUF would be set to a higher value than the low water mark. This allows a complete chunk of data to be stuffed into the buffer, and the application can then spend more time waiting in select() - where it is in a better position to make control decisions which are likely to be latency sensitive, and it can service other sockets which might be draining or filling at a different rate.
- Jonathan Morton
next prev parent reply other threads:[~2015-06-19 4:08 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-16 16:11 Dave Taht
2015-06-19 2:47 ` Juliusz Chroboczek
2015-06-19 4:07 ` Jonathan Morton [this message]
2015-06-19 7:10 ` [Bloat] " Eric Dumazet
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=6644BD81-1FFC-450C-89FD-91E138B7824A@gmail.com \
--to=chromatix99@gmail.com \
--cc=bloat-devel@lists.bufferbloat.net \
--cc=bloat@lists.bufferbloat.net \
--cc=jch@pps.univ-paris-diderot.fr \
/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