From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by huchra.bufferbloat.net (Postfix) with ESMTP id C133021F353 for ; Wed, 22 Apr 2015 11:39:25 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DACF15D88D1; Wed, 22 Apr 2015 20:39:23 +0200 (CEST) Received: from FTRDCH01.rd.francetelecom.fr (unknown [10.194.32.11]) by r-mail2.rd.orange.com (Postfix) with ESMTP id D280C5D84F0; Wed, 22 Apr 2015 20:39:23 +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 20:39:23 +0200 Message-ID: <5537EAD8.3060806@orange.com> Date: Wed, 22 Apr 2015 20:39:20 +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: <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> <5537CDB7.60301@orange.com> <1429722979.18561.112.camel@edumazet-glaptop2.roam.corp.google.com> <5537DA20.1090008@orange.com> <1429726944.18561.122.camel@edumazet-glaptop2.roam.corp.google.com> In-Reply-To: <1429726944.18561.122.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] Pacing --- was 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 18:39:54 -0000 This is not clear to me in general. I can understand that for the first shot of the IW>=10 pacing is always a win strategy no matter what queuing system you have because it reduces the loss probability in that window. Still fq_codel would reduce that probability even more. But for long flows going far beyond that phase isn't clear to me why the paced flow is not penalized by the non paced flow in FIFO. TCP will start filling the pipe at some point in bursts and that would hurt. Now, I forgot how sch_fq pacing rate is initialized to be effective from the very first window. On 04/22/2015 08:22 PM, Eric Dumazet wrote: > It really does. > > This is why we deployed sch_fq and let our competitors find this later.