From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.tohojo.dk (mail.tohojo.dk [188.40.53.186]) (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 DE4C9208AA0; Sun, 2 Dec 2012 13:38:01 -0800 (PST) Received: from alrua-laptop.borgediget.toke.dk (1809ds4-ro.0.fullrate.dk [90.184.46.60]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.tohojo.dk (Postfix) with ESMTPSA id C39321EC0531; Sun, 2 Dec 2012 22:37:58 +0100 (CET) Received: by alrua-laptop.borgediget.toke.dk (Postfix, from userid 1000) id B3F29458; Sun, 2 Dec 2012 22:37:57 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Eric Dumazet 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> Date: Sun, 02 Dec 2012 22:37:54 +0100 In-Reply-To: <1354129222.14302.508.camel@edumazet-glaptop> (Eric Dumazet's message of "Wed, 28 Nov 2012 11:00:22 -0800") Message-ID: <87vcckb0el.fsf@toke.dk> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.2 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Cc: Paolo Valente , "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: Sun, 02 Dec 2012 21:38:02 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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". Now, talking about thin flows being distinguished from thick ones, it seems to me that if a flow sends packets at a low enough rate it can in principle stay 'thin' indefinitely. So I'm assuming I've missed something in the code that allows a flow to stay in the new_flows list if it is sufficiently thin. Could someone please point out to me what I'm missing? :) Thanks, =2DToke =2D-=20 Toke H=C3=B8iland-J=C3=B8rgensen toke@toke.dk --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCAAGBQJQu8oyAAoJEENeEGz1+utPngUH/2zwheuBGMduTv1qNzWrffyd xtyyizeSSvTcks0twCGMq2my6mh5pSfL3ekZxEx54yvcqWAuPqr6i1LA3QjleRxS zlHVPfeNwl5t1ZVXokqIiVJok8WvrqNTSyM+s9BLn+lB/MznhbS6897n+8crs2hb wCFEVo/4Nmw1kIe49oCq4M3EXghmEopF+I376vvvNSxVGRbbxlJrvE3a9naS8V2j UR4FyeA18x8/3bXk1p4mF53BOCfoY/UmbswGq0QsILTXT2Mw4bGyv+gRSWGjopQy 6cNwUQUV7npkpe48jiXkoQVgeaBtjKtcSNlgHp0BsIzj4Nbvhhk77YUV1+iKcv0= =NqBr -----END PGP SIGNATURE----- --=-=-=--