From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (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 E2F6521F23A for ; Wed, 22 Apr 2015 08:26:30 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 3693F3740B7; Wed, 22 Apr 2015 17:26:28 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 1058215808A; Wed, 22 Apr 2015 17:26:28 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0224.002; Wed, 22 Apr 2015 17:26:28 +0200 From: To: Eric Dumazet Thread-Topic: RE : [Bloat] DSLReports Speed Test has latency measurement built-in Thread-Index: AQHQfRCzK63sD2Xkf0aP3abcVUrl1Q== Date: Wed, 22 Apr 2015 15:26:27 +0000 Message-ID: <25065_1429716388_5537BDA4_25065_2328_1_63pyislbvtjf653k3qt8gw2c.1429715929544@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> <12383_1429692679_55376107_12383_9099_1_p7gmr0psut68sen0sao8o4lp.1429692550899@email.android.com>, <1429710657.18561.68.camel@edumazet-glaptop2.roam.corp.google.com> In-Reply-To: <1429710657.18561.68.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_63pyislbvtjf653k3qt8gw2c1429715929544emailandroidcom_" 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 15:26:59 -0000 --_000_63pyislbvtjf653k3qt8gw2c1429715929544emailandroidcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Do I need to read this as all Google servers =3D=3D all servers :) BTW if a paced flow from Google shares a bloated buffer with a non paced fl= ow from a non Google server, doesn't this turn out to be a performance pen= alty for the paced flow? fq_codel gives incentives to do pacing but if it's not deployed what's the = performance gain of using pacing? -------- Message d'origine -------- De : Eric Dumazet Date :2015/04/22 21:51 (GMT+08:00) =C0 : MUSCARIELLO Luca IMT/OLN Cc : "Steinar H. Gunderson" , bloat Objet : Re: [Bloat] DSLReports Speed Test has latency measurement built-in On Wed, 2015-04-22 at 08:51 +0000, luca.muscariello@orange.com wrote: > cons: large BDP in general would be negatively affected. > A Gbps access vs a DSL access to the same server would require very > different tuning. > Yep. This is what I mentioned with 'long rtt'. This was relative to BDP. > > 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 usual servers setting BTW > No idea why it should mater. Have you got some experimental data ? You know, 'usual servers' used to run pfifo_fast, they now run sch_fq. (All Google fleet at least) So this kind of argument sounds not based on experiments. ___________________________________________________________________________= ______________________________________________ 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_63pyislbvtjf653k3qt8gw2c1429715929544emailandroidcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Do I need to read this as all Google servers =3D=3D all servers :)&nbs= p;

BTW if a paced flow from Google shares a bloated buffer with a non pac= ed flow from a non Google server,  doesn't this turn out to be a perfo= rmance penalty for the paced flow? 

fq_codel gives incentives to do pacing but if it's not deployed what's= the performance gain of using pacing? 


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

On Wed, 2015-04-22 at 08:51 +0000, luca.muscar= iello@orange.com wrote:
> cons: large BDP in general would be negatively affected. 
> A Gbps access vs a DSL access to the same server would require very
> different tuning.
>
Yep. This is what I mentioned with 'long rtt'. This was relative to BDP.
>
> 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 usual servers setting BTW
>
No idea why it should mater. Have you got some experimental data ?

You know, 'usual servers' used to run pfifo_fast, they now run sch_fq.

(All Google fleet at least)

So this kind of argument sounds not based on experiments.


 
______________________________________________________________________=
___________________________________________________

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_63pyislbvtjf653k3qt8gw2c1429715929544emailandroidcom_--