From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 7247F21F2BD for ; Wed, 22 Apr 2015 01:51:22 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 7F4C318C355; Wed, 22 Apr 2015 10:51:19 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 5C68B27C087; Wed, 22 Apr 2015 10:51:19 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Wed, 22 Apr 2015 10:51:18 +0200 From: To: Eric Dumazet , "Steinar H. Gunderson" Thread-Topic: RE : [Bloat] DSLReports Speed Test has latency measurement built-in Thread-Index: AQHQfNl/0S2yOFJLvU+hqU/bOMNDDw== Date: Wed, 22 Apr 2015 08:51:18 +0000 Message-ID: <12383_1429692679_55376107_12383_9099_1_p7gmr0psut68sen0sao8o4lp.1429692550899@email.android.com> References: <75C1DDFF-FBD2-4825-A167-92DFCF6A7713@gmail.com> <8AD4493E-EA21-496D-923D-B4257B078A1C@gmx.de> <8E4F61CA-4274-4414-B4C0-F582167D66D6@gmx.de> <2C987A4B-7459-43C1-A49C-72F600776B00@gmail.com> <14cd9e74e48.27f7.e972a4f4d859b00521b2b659602cb2f9@superduper.net> <20150422040453.GB36239@sesse.net>, <1429676935.18561.42.camel@edumazet-glaptop2.roam.corp.google.com> In-Reply-To: <1429676935.18561.42.camel@edumazet-glaptop2.roam.corp.google.com> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_p7gmr0psut68sen0sao8o4lp1429692550899emailandroidcom_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.4.22.65722 Cc: bloat Subject: [Bloat] RE : DSLReports Speed Test has latency measurement built-in 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: Wed, 22 Apr 2015 08:51:51 -0000 --_000_p7gmr0psut68sen0sao8o4lp1429692550899emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable cons: large BDP in general would be negatively affected. A Gbps access vs a DSL access to the same server would require very differe= nt tuning. sch_fq would probably make the whole thing less of a problem. But running it in a VM does not sound a good idea and would not reflect usu= al servers setting BTW -------- Message d'origine -------- De : Eric Dumazet Date :2015/04/22 12:29 (GMT+08:00) =C0 : "Steinar H. Gunderson" Cc : bloat Objet : Re: [Bloat] DSLReports Speed Test has latency measurement built-in On Wed, 2015-04-22 at 06:04 +0200, Steinar H. Gunderson wrote: > On Tue, Apr 21, 2015 at 08:35:21PM +1000, jb wrote: > > As I understand it (I thought) SO_SNDBUF and SO_RCVBUF are socket buffe= rs > > for the application layer, they do not change the TCP window size either > > send or receive. > > I haven't gone into the code and checked, but from practical experience I > think you're wrong. I've certainly seen positive effects (and verified wi= th > tcpdump) from reducing SO_SNDBUF on a server that should have no problems= at > all sending data really fast to the kernel. Well, using SO_SNDBUF disables TCP autotuning. Doing so : Pros: autotuning is known to enable TCP cubic to grow cwnd to bloat levels. With small enough SO_SNDBUF, you limit this cwnd increase. Cons: Long rtt sessions might not have enough packets to utilize bandwidth. > > Then again, this kind of manual tuning trickery got obsolete for me the > moment sch_fq became available. Note that I suppose the SO_MAX_PACING rate is really helping you. Without it, TCP cubic is still allowed to 'fill the pipes' until packet losses. _______________________________________________ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_p7gmr0psut68sen0sao8o4lp1429692550899emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
cons: large BDP in general would be negatively affected. 
A Gbps access vs a DSL access to the same server would require very di= fferent tuning. 

sch_fq would probably make the whole thing less of a problem. 
But running it in a VM does not sound a good idea and would not reflec= t usual servers setting BTW 









-------- Message d'origine --------
De : Eric Dumazet
Date :2015/04/22 12:29 (GMT+08:00)
=C0 : "Steinar H. Gunderson"
Cc : bloat
Objet : Re: [Bloat] DSLReports Speed Test has latency measurement buil= t-in

On Wed, 2015-04-22 at 06:04 +0200, Steinar H. = Gunderson wrote:
> On Tue, Apr 21, 2015 at 08:35:21PM +1000, jb wrote:
> > As I understand it (I thought) SO_SNDBUF and SO_RCVBUF are socket= buffers
> > for the application layer, they do not change the TCP window size= either
> > send or receive.
>
> I haven't gone into the code and checked, but from practical experienc= e I
> think you're wrong. I've certainly seen positive effects (and verified= with
> tcpdump) from reducing SO_SNDBUF on a server that should have no probl= ems at
> all sending data really fast to the kernel.

Well, using SO_SNDBUF disables TCP autotuning.

Doing so :

Pros:

autotuning is known to enable TCP cubic to grow cwnd to bloat levels.
With small enough SO_SNDBUF, you limit this cwnd increase.

Cons:

Long rtt sessions might not have enough packets to utilize bandwidth.


>
> Then again, this kind of manual tuning trickery got obsolete for me th= e
> moment sch_fq became available.

Note that I suppose the SO_MAX_PACING rate is really helping you.

Without it, TCP cubic is still allowed to 'fill the pipes' until packet
losses.



_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.buff= erbloat.net/listinfo/bloat
 
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_p7gmr0psut68sen0sao8o4lp1429692550899emailandroidcom_--