From: Dave Taht <dave.taht@gmail.com>
To: "Steinar H. Gunderson" <sgunderson@bigfoot.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] using tcp_notsent_lowat in various apps?
Date: Tue, 16 Jun 2015 09:31:26 -0700 [thread overview]
Message-ID: <CAA93jw5Yf_PKZnYjDLnK+bd53dwyFL2+3zXe4C1rXL9pG3oDsw@mail.gmail.com> (raw)
In-Reply-To: <20150616161807.GA31289@sesse.net>
On Tue, Jun 16, 2015 at 9:18 AM, Steinar H. Gunderson
<sgunderson@bigfoot.com> wrote:
> On Tue, Jun 16, 2015 at 09:11:08AM -0700, Dave Taht wrote:
>> I just tossed off a quick patch for rsync, not that I have a clue as
>> to whether it would make any difference there.
>
> For bulk applications (like rsync), how would this make sense at all?
> I thought the entire point of this option was if you knew what data to send
> now, but that you might want to change your mind later if it takes some time
> to send it. The latter doesn't apply to rsync.
That was mostly there for a quick coding example (I have also had out
of tree patches
for classification and tcp cc selection in there, and was fiddling
with cdg, so it was seconds
more to toss off that patch. rsync does also mix command and control
in the data flow).
What I'd wanted to do was measure the cpu impact of the
additional context switches along the lines of the original posting on
this option
https://lwn.net/Articles/560082/
(In the case of rsync and scp I have been known to abort it part of
the way through, too.)
The larger question was about anyone trying vnc and similar questions
in chrome and other web
browsers, and servers. ex:
https://insouciant.org/tech/prioritization-only-works-when-theres-pending-data-to-prioritize/
> /* Steinar */
> --
> Homepage: http://www.sesse.net/
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
--
Dave Täht
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast
next prev parent reply other threads:[~2015-06-16 16:31 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 [this message]
2015-06-16 16:33 ` Jonathan Morton
2015-06-16 17:22 ` Dave Taht
2015-06-16 18:12 ` Eric Dumazet
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=CAA93jw5Yf_PKZnYjDLnK+bd53dwyFL2+3zXe4C1rXL9pG3oDsw@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=sgunderson@bigfoot.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