From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id AAEE021F462 for ; Tue, 16 Jun 2015 09:31:27 -0700 (PDT) Received: by oiha141 with SMTP id a141so15330405oih.0 for ; Tue, 16 Jun 2015 09:31:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=t9tytdA+gmdH0xQkiuT6dNJiQngk+FJE1ZI2XOf9+1w=; b=jd5+H4DFtFQ8Ojs31kCE0NvUEMGlA5v/4BkeEC18szsrKlBWvMRLK2YEVlJ0tKyyfI kgIZ+Vrxr96R/CAnRe34AIc9sNpHSRLNtPb0exl8IFv/8dZ4zrNvS9ouTJp87T2oeZUj nTSfKbiWkciKdreapIdrTY+e2+Wm3Pn8oDjmtua/6/2PdWcE3ykEk3vjeMrSBLXmvFpn gWh9Orjj/hg0vZGpPl8BtvzXa43QVtMYM1x3jMmQMudCiqnhyqT0yk8dXaNssRFLc9SH iXFkEWjgzr1sQEziofE5iWpl98s6bOjSgI3ooh42Mkx0N4/gRg4EYMoA01aiAnqmDBOU bQwg== MIME-Version: 1.0 X-Received: by 10.182.88.201 with SMTP id bi9mr946430obb.29.1434472286311; Tue, 16 Jun 2015 09:31:26 -0700 (PDT) Received: by 10.202.105.129 with HTTP; Tue, 16 Jun 2015 09:31:26 -0700 (PDT) In-Reply-To: <20150616161807.GA31289@sesse.net> References: <20150616161807.GA31289@sesse.net> Date: Tue, 16 Jun 2015 09:31:26 -0700 Message-ID: From: Dave Taht To: "Steinar H. Gunderson" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: bloat Subject: Re: [Bloat] using tcp_notsent_lowat in various apps? X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2015 16:31:55 -0000 On Tue, Jun 16, 2015 at 9:18 AM, Steinar H. Gunderson 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 se= nd > now, but that you might want to change your mind later if it takes some t= ime > 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-d= ata-to-prioritize/ > /* Steinar */ > -- > Homepage: http://www.sesse.net/ > _______________________________________________ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat --=20 Dave T=C3=A4ht What will it take to vastly improve wifi for everyone? https://plus.google.com/u/0/explore/makewififast