General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Dave Taht <dave.taht@gmail.com>
Cc: Jonathan Morton <chromatix99@gmail.com>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] using tcp_notsent_lowat in various apps?
Date: Tue, 16 Jun 2015 11:12:37 -0700	[thread overview]
Message-ID: <1434478357.27504.185.camel@edumazet-glaptop2.roam.corp.google.com> (raw)
In-Reply-To: <CAA93jw6b1GFhUDdpW4uy-w3bakENHoP3_-a8+umtk-qB3uBTpg@mail.gmail.com>

On Tue, 2015-06-16 at 10:22 -0700, Dave Taht wrote:

> Take samba as another potential example. I commonly see this
> increasing the SO_SNDBUF to a given value, but I am not sure if this
> is the right thing anymore. As samba is commonly used for filesharing
> (and things that take locks and do database-y stuff), improving
> interactivity might be a big win.
> 
> Seeing the 50%! decrease in kernel memory on the original tests of
> TCP_SENT_LOWAT is very exciting in the context of those running samba
> on tiny tiny nas devices common in my world.
> 
> And seeing apple enable it universally points to perhaps exploring the
> effects of just enabling it universally in linux (or in certain kinds
> of linux-based devices) at a "reasonable" value, for whatever value of
> reasonable exists.

Another use case for TCP_SENT_LOWAT is the cancel phase.

If for one reason, application decides to abort the transfer, by doing a
close() or shutdown(), it is better to have at most few KB of data still
queued in socket, that kernel tries to deliver no matter what.

I've seen stupid applications having timeouts on their sockets. When
they believe a flow is stuck, they close it and open a new one. And you
get many flows competing on the same bottleneck.




  reply	other threads:[~2015-06-16 18:12 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-16 16:11 Dave Taht
2015-06-16 16:18 ` Steinar H. Gunderson
2015-06-16 16:31   ` Dave Taht
2015-06-16 16:33   ` Jonathan Morton
2015-06-16 17:22     ` Dave Taht
2015-06-16 18:12       ` Eric Dumazet [this message]
2015-06-19  2:47 ` Juliusz Chroboczek
2015-06-19  4:07   ` Jonathan Morton
2015-06-19  7:10     ` Eric Dumazet
2015-06-21 15:04       ` Juliusz Chroboczek
2015-06-21 16:09         ` Jonathan Morton
2015-06-22  7:02         ` Eric Dumazet
2015-06-22 12:05           ` Juliusz Chroboczek

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

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1434478357.27504.185.camel@edumazet-glaptop2.roam.corp.google.com \
    --to=eric.dumazet@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=chromatix99@gmail.com \
    --cc=dave.taht@gmail.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