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 E35EB208AA0; Sun, 2 Dec 2012 14:15:46 -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 C05C61EC0531; Sun, 2 Dec 2012 23:15:44 +0100 (CET) Received: by alrua-laptop.borgediget.toke.dk (Postfix, from userid 1000) id 5A65E458; Sun, 2 Dec 2012 23:15:43 +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> Date: Sun, 02 Dec 2012 23:15:40 +0100 In-Reply-To: <1354486069.20109.1206.camel@edumazet-glaptop> (Eric Dumazet's message of "Sun, 02 Dec 2012 14:07:49 -0800") Message-ID: <87lidgaynn.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:15:47 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eric Dumazet writes: > If the next packet arrives while the bucket is still in old_flows, > we wont put the bucket in new_flow, its bucket have to wait its turn in > the RR list. Right. So in order to stay in the new_flows list, the flow needs to be slow enough that no new data is added to it in the time it takes subsequent dequeue invocations to get back to it in the old_flows list? > Think of it this way : If a bucket lost its turn in the RRR mechanism > and became idle, it has its deficit refilled to 'q->quantum', and it has > the right to be elected as a new_flow next time a packet wants to use > this bucket. Yes, I think I missed this, and was somehow assuming that the flow stays "alive" (i.e. in the old_flows list) for as long as the /connection/ is 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) iQEcBAEBCAAGBQJQu9MMAAoJEENeEGz1+utP5R4IAKN6bbTB7xJTS17l13COQhpG nuLMe2JD3A4YLuqOreMd+g+6dqtk6eEhfYUkKSdvsOcsu22mqfHJTQ5Fbw471sGK wru/AQH8ieA3PRKxEXunIerigEKQ02i9BuDFi8xfEwWibGWERte8qN/iBZf3LE1Y VUWj7aVroOy0Z8wAfnBAlwflx//EGzor5hMZApp7WU4XOHuPYb8ZQN6uj5X7MjQy dMXsUs0ssTv2EfDsPo3IYqIMSV+GCgi/pBATK3XeTKjmeGMmw9stth2iFl1Q5CtH te00kqka5MYAvTA/5j4P7UWkwyEUcqwxzYY6eFQ+6Hi3XCcACDnkFBtBpi030fk= =TClR -----END PGP SIGNATURE----- --=-=-=--