From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from r-mail1.rd.orange.com (r-mail1.rd.orange.com [217.108.152.41]) by huchra.bufferbloat.net (Postfix) with ESMTP id 8A78E21F2E0 for ; Wed, 22 Apr 2015 09:35:09 -0700 (PDT) Received: from r-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9DD60DE4009; Wed, 22 Apr 2015 18:35:07 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail1.rd.orange.com (Postfix) with ESMTP id 936F0DE4006; Wed, 22 Apr 2015 18:35:07 +0200 (CEST) Received: from [10.193.116.35] (10.193.116.35) by FTRDCH01.rd.francetelecom.fr (10.194.32.11) with Microsoft SMTP Server id 14.3.224.2; Wed, 22 Apr 2015 18:35:05 +0200 Message-ID: <5537CDB7.60301@orange.com> Date: Wed, 22 Apr 2015 18:35:03 +0200 From: MUSCARIELLO Luca IMT/OLN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Eric Dumazet References: <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> <25065_1429716388_5537BDA4_25065_2328_1_63pyislbvtjf653k3qt8gw2c.1429715929544@email.android.com> <1429717468.18561.90.camel@edumazet-glaptop2.roam.corp.google.com> In-Reply-To: <1429717468.18561.90.camel@edumazet-glaptop2.roam.corp.google.com> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit Cc: bloat Subject: Re: [Bloat] DSLReports Speed Test has latency measurement built-in X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list Reply-To: MUSCARIELLO Luca IMT/OLN 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 16:35:38 -0000 On 04/22/2015 05:44 PM, Eric Dumazet wrote: > On Wed, 2015-04-22 at 15:26 +0000, luca.muscariello@orange.com wrote: >> Do I need to read this as all Google servers == all servers :) >> >> > Read again what I wrote. Don't play with my words. let the stupid guy ask questions. In the worst case don't answer, but no reason to get nervous. > >> BTW if a paced flow from Google shares a bloated buffer with a non >> paced flow from a non Google server, doesn't this turn out to be a >> performance penalty for the paced flow? >> >> > What do you think ? Do you think Google would still use sch_fq if this > was a potential problem ? Frankly, I do not understand this statement as it seems you tell me that that would be the right choice as Google does it. I believe that Google does it for technical reasons and that would be part of your possible answers. You have the right not to share with the list of course. > >> fq_codel gives incentives to do pacing but if it's not deployed what's >> the performance gain of using pacing? > 1) fq_codel has nothing to do with pacing. FQ gives you flow isolation. Extreme example: If you share the link with a flow that saturates the buffer (for whatever reason) flow isolation gives you the comfort to do whatever works better for your application. Without flow isolation how can you benefit from the good features of pacing if the buffer get screwed by a competing flow? This is what I meant with incentives to do pacing in presence of flow isolation, as you get rewarded if the sender behaves better no matter what others do. > > 2) sch_fq doesn't depend on fq_codel or codel being used anywhere. that's clear to me. >