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 7601621F175; Sun, 2 Dec 2012 14:51:41 -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 827641EC0531; Sun, 2 Dec 2012 23:51:39 +0100 (CET) Received: by alrua-laptop.borgediget.toke.dk (Postfix, from userid 1000) id 7426A458; Sun, 2 Dec 2012 23:51:38 +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> <87vcckb0el.fsf@toke.dk> <1354486069.20109.1206.camel@edumazet-glaptop> <87lidgaynn.fsf@toke.dk> <1354487409.20109.1235.camel@edumazet-glaptop> Date: Sun, 02 Dec 2012 23:51:35 +0100 In-Reply-To: <1354487409.20109.1235.camel@edumazet-glaptop> (Eric Dumazet's message of "Sun, 02 Dec 2012 14:30:09 -0800") Message-ID: <87hao4awzs.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 22:51:42 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eric Dumazet writes: > I guess so. It must travel through the old_flows list from the tail to > the head (so each flows in old_flows must be serviced by one quantum), > to get the right to be declared as 'empty' and gain the honor to get > promoted to 'new_flows' next time a packet is enqueued. > > If all flows are slow, but the queue can still build up, because there > are too many flows for the possible bandwidth, than all flows are > actually considered as thick, as if we had a single RR queue. (the > old_flows). Right, that makes sense. Everything is relative. Thanks for clearing things up! :) =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) iQEcBAEBCAAGBQJQu9t3AAoJEENeEGz1+utPNqwH/RlD0lytgR4gfhBeTVST1EWs YFnoe0x5ll/94ZdJxUFf4aqkkBUQoTRoUkuNCSz0uwnTf8xk2ApVFZXXlG24Sm2q 6Q9GzMVx6MiO2/QgmEcUGh9dmoJXmjzssLzktvKJnjXGpTmn1DHZpAqtZrRE4nmz lxHbBGm5AXLoMLnaRt1pwAYJ/v336SzlYNVSojotbyskhung5zZgqWaUZIxBUQMY sK/5zExekeThwQvYA30hEHJFViL36/Woi0R9K7kMNFOJbQFxw1tejZqEObAZInBT aS16HZCeur6gCuu14btJd33Rs/aAZCg2JNroCmO8jYfkwh331BDAODD72grSVwY= =+D2d -----END PGP SIGNATURE----- --=-=-=--