From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (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 2547D208AAD; Mon, 3 Dec 2012 00:04:36 -0800 (PST) Received: by mail-ie0-f175.google.com with SMTP id qd14so3776242ieb.34 for ; Mon, 03 Dec 2012 00:04:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=4XlmPEjwBdoF9TqqXnud1JRM3NUs6dnqne46TEfrSWg=; b=sTS88Xk4QJlbzU2Kx4KrZIScjWZxLVJ2W0PH0bgV3b1ABJMOp56WU2OuD5/9TfwmEm C0trkEGL9IHYwXv8WKd/9dOo111lU8zsYTmh2rY8xKVFRnlBrMIj0ERPLdbzzELCmduh 4pVfD25R/iAfOG9KH5x1FJDgK82ArSyU6viN7ePU/08LXZm/FCxm3PrKEdmNySU5AOrx N9e+js1N27xZpAIlQdah3YYXxfDnPTl/+vvSRQByvsbuNyUIf1joVMlms9QVE5/BSfpp +/xNC2NHZ5GSvoZGMIUTNfodGQrA4HuDOf9fYV/97M47BIuz6hePlRhT+DcMZV/Gc6T5 Upeg== MIME-Version: 1.0 Received: by 10.50.171.4 with SMTP id aq4mr5380565igc.68.1354521875235; Mon, 03 Dec 2012 00:04:35 -0800 (PST) Received: by 10.64.135.39 with HTTP; Mon, 3 Dec 2012 00:04:35 -0800 (PST) In-Reply-To: <344628E4-C813-4410-AB39-57C7081021B6@gmail.com> References: <20121127224915.GM2474@linux.vnet.ibm.com> <20121128002710.GS2474@linux.vnet.ibm.com> <50B5887C.7010605@pollere.com> <20121128043838.GX2474@linux.vnet.ibm.com> <20121128160133.GA16995@linux.vnet.ibm.com> <20121128174440.GD2474@linux.vnet.ibm.com> <1354129222.14302.508.camel@edumazet-glaptop> <87vcckb0el.fsf@toke.dk> <344628E4-C813-4410-AB39-57C7081021B6@gmail.com> Date: Mon, 3 Dec 2012 09:04:35 +0100 Message-ID: From: Dave Taht To: Andrew McGregor Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Paolo Valente , =?ISO-8859-1?Q?Toke_H=F8iland=2DJ=F8rgensen?= , "codel@lists.bufferbloat.net" , "cerowrt-devel@lists.bufferbloat.net" , bloat , paulmck@linux.vnet.ibm.com, John Crispin Subject: Re: [Codel] [Bloat] [Cerowrt-devel] FQ_Codel lwn draft article review X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 08:04:36 -0000 On Sun, Dec 2, 2012 at 10:47 PM, Andrew McGregor wro= te: > > On 3/12/2012, at 10:37 AM, Toke H=F8iland-J=F8rgensen wrot= e: > >> Eric Dumazet writes: >> >>> This can help if you really want to avoid a thick flow sharing a thin >>> flow bucket, but given that all packets are going eventually into the >>> Internet (or equivalent crowded network), its not really a clear win. >> >> I've been trying to grok the fq_codel code by reading through it while >> following the discussion in the article, and I'm having a bit of trouble >> squaring the thin/thick (or "hog"/"non-hog") flow designation of the >> article with the code. As far as I can tell from the code, there are two >> lists, called new_flows and old_flows; and a flow starts out as 'new' >> and stays that way until it has sent a quantum of bytes or codel fails >> to dequeue a packet from it, whereupon it is moved to the end of the >> old_flows list. It then stays in the old_flows list for the rest of its >> "life". > > 'new' is what I was calling 'thin', and 'old' is the 'thick' list. The phrasing that I use for this stuff is "sparse" rather than "thin", if that helps any. TCP mice are VERY sparse as they are a function of RTT, and thus most web flows on a home router end up staying in the new flow queue. --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html