From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ia0-x229.google.com (mail-ia0-x229.google.com [IPv6:2607:f8b0:4001:c02::229]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id CA354201ACC; Fri, 3 May 2013 15:15:52 -0700 (PDT) Received: by mail-ia0-f169.google.com with SMTP id l29so1802803iag.28 for ; Fri, 03 May 2013 15:15:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:content-transfer-encoding; bh=VMtWmr7hCgLSgDbwC63hmVzHOl8A7k7kcz3qTDFehB8=; b=zDI+qSewrAHoP6lMOYEr30YpKZ7L1Z8bU0sGYWqaCS8Sx0btInLN/lao0dSQRZjjwz /4ZZl8Fuu/Ofb7jsHXPSWBA+2DrHtS9ZAMFmNW7ybOL2a+sG+NCmlozcDGzn+UdFbpEM GOwWFlnONyhksZR6pm9mp+d/YlydacMvkoX/jp+tI2q6SVgJwr4tCrH30CA2BpsBAnum gqPn9aQ1G1X6P26T5RCwAbsPCIh2slM0dcr5cADMWUCgDE2K0TecrEiGtoTtjo5d8stu u5cmi+nlMvpOWhBPO7sVzXKzuPcikKjVN1GZxYlIeqM4Nocdc6QkNiPWpCFfc1J7XXsb n/+A== MIME-Version: 1.0 X-Received: by 10.42.26.12 with SMTP id d12mr5081265icc.1.1367619351763; Fri, 03 May 2013 15:15:51 -0700 (PDT) Received: by 10.64.7.51 with HTTP; Fri, 3 May 2013 15:15:51 -0700 (PDT) In-Reply-To: <7ibo8sngwv.wl%jch@pps.univ-paris-diderot.fr> References: <7ibo8sngwv.wl%jch@pps.univ-paris-diderot.fr> Date: Fri, 3 May 2013 15:15:51 -0700 Message-ID: From: Dave Taht To: Juliusz Chroboczek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bloat-devel , cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] optimizing for very small bandwidths with fq_codel better? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 May 2013 22:15:53 -0000 On Fri, May 3, 2013 at 9:53 AM, Juliusz Chroboczek wrote: > tc qdisc add dev eth2 handle a root fq_codel flows 16 quantum 300 > > What's the deal with the small quantum? Less than the MTU? What this does is optimizes for interactive traffic over bulk. fq_code, which is DRR based,l has a "new" flow idea in it, packets that exceed a given quantum, never become new. So a 1500 byte packet will be passed over 5 times before being delivered, while other flows smaller than the quantum have a chance of being bumped into the new flow queue and delivered most rapidly, depending on how "sparse" they are. It's a very old trick, going back as far as the venerable wondershaper. (which did this, but badly, resulting in packet re-ordering on some kinds of traffic) I note that what I'm doing here (with the oddball filters) is an experiment in progress. There are some comments in the tc code as to where I'd like it to go... We get very good results from fq_codel with a quantum this size at 4Mbits, but below that bandwidth things are dicy. Prior to this experiment I'd been using a 3 tier shaper with htb, but that too had trouble getting below 2Mbits, and relied on classification in order to push background traffic into the background queue. This is an attempt to be able to run at the line rate (whatever it is) (or under a single htb), at 2Mbit or lower (384k, being the lowest). It may be that we may also need to fiddle with fq_codel's target and/or interval in order to work well at these rates. For some detail as to what spurred this, please see the recent cablelabs re= port: http://www.cablelabs.com/downloads/pubs/Active_Queue_Management_Algorithms_= DOCSIS_3_0.pdf Once you get above 4Mbit extensive fiddling with fq_codel's defaults seems increasingly unnecessary. We've also been fiddling with various forms a "pfq_codel", which tries to emulate pfifo_fast behavior in similar ways. > > -- Juliusz --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html