From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-da0-f48.google.com (mail-da0-f48.google.com [209.85.210.48]) (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 A126321F197 for ; Mon, 24 Dec 2012 04:16:00 -0800 (PST) Received: by mail-da0-f48.google.com with SMTP id k18so3156809dae.21 for ; Mon, 24 Dec 2012 04:16:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer; bh=Syf6MeFBNIEGYjAchrxp9fvYQjN3Gh5LFs4jzSpq9R4=; b=HnGJNNr5KGripBf7UoTygs+WmhmG6sBNd02iPuE7vbE8Tsp0LbjrTy7OsoUE3jRjwM ihDTzZv5FsITF68KjzTJPhgyR5PLXX34LosoCdcXzNbQUVemQNZDBfA5ZzRwfuNL96Fa ZNbpoClKKL8LU9juAzPGIuB/mDQuB1VujYF8NUai1oBoySd+3+HTevUWbwmm5gO6ghnO 1FNipNn+Ou8ralifjMubdKsp7+lWrPeFlUqwciyzkmz2G2yKweU0yGB7LlBgQecDr9O7 1eAblVK6mViZEdn+Z2mKgmibP1e0Fv20isQPZd0hnmYMan36iNc8mBjYkmZRL3302xLo u74Q== X-Received: by 10.68.236.2 with SMTP id uq2mr65868693pbc.55.1356351359903; Mon, 24 Dec 2012 04:15:59 -0800 (PST) Received: from ?IPv6:2406:e000:63ad:1:495b:d998:d659:7f00? ([2406:e000:63ad:1:495b:d998:d659:7f00]) by mx.google.com with ESMTPS id a4sm12757365pax.25.2012.12.24.04.15.56 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 24 Dec 2012 04:15:58 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_9E481EE4-EF30-44D4-9DB1-36DE706B9897"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Andrew McGregor In-Reply-To: Date: Tue, 25 Dec 2012 01:15:49 +1300 Message-Id: <8674C071-D403-4221-B2AA-535ECC8208F3@gmail.com> References: To: Alessandro Bolletta X-Mailer: Apple Mail (2.1499) Cc: "Codel@lists.bufferbloat.net" Subject: Re: [Codel] fq_codel and 802.11n packet aggregation 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, 24 Dec 2012 12:16:00 -0000 --Apple-Mail=_9E481EE4-EF30-44D4-9DB1-36DE706B9897 Content-Type: multipart/alternative; boundary="Apple-Mail=_8982E0D3-6D3E-4793-952B-27310321F304" --Apple-Mail=_8982E0D3-6D3E-4793-952B-27310321F304 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 You don't ever want to increase either target or interval... in fact, = leaving interval completely alone and slightly reducing target is all = you should do. fq_codel suffers a little on wireless... but to be sure, it isn't bad, = it is still a vast improvement on basically anything else, it simply = isn't quite optimal for that environment. As to how long it will take to get this sorted, I don't think anyone = will know for a month or two... but that might be all it takes. Andrew On 24/12/2012, at 11:17 PM, Alessandro Bolletta = wrote: > Hi everybody, > thanks to Dave, I just learned that fq_codel suffers from every type = of queuing technique made on underlaying layers (as in device drivers, = for example), and one of these queuing techniques are 802.11n/ac packet = aggregation and 802.11e QoS. > David said that, at this time, the problem isn=92t going to be solved = shortly, even if it seems that there are already some ideas in order to = solve this problem. > =20 > In my specific case, I would like to run fq_codel in a new (and very = extended) mesh network that doesn=92t match with some limitations; for = example, if it will occur that a link bandwidth falls below 4Mbit/s, = mesh net will consider that link not available to carry traffic, because = I surely know that it will not be sufficient to suit bandwidth = requirements of my network. > Also, I could increase target and interval values whenever i=92ll need = to adjust settings that I can=92t expect now. > =20 > So, i was thinking that, maybe, if i increase target and interval = values to include packet aggregation delay times in the overall delay, I = could just overall the problem, waiting for a fix in the future. > What do you think about? Is it a good compromise or there are other = aspects that i=92m leaving behind? > =20 > Thanks so much for your help! > =20 > Alessandro > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel --Apple-Mail=_8982E0D3-6D3E-4793-952B-27310321F304 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 You don't ever want to increase = either target or interval... in fact, leaving interval completely alone = and slightly reducing target is all you should = do.

fq_codel suffers a little on wireless... but to = be sure, it isn't bad, it is still a vast improvement on basically = anything else, it simply isn't quite optimal for that = environment.

As to how long it will take to get = this sorted, I don't think anyone will know for a month or two... but = that might be all it = takes.

Andrew

On = 24/12/2012, at 11:17 PM, Alessandro Bolletta <alessandro@mediaspot.net> = wrote:

Hi = everybody,
thanks to Dave, I = just learned that fq_codel suffers from every type of queuing technique = made on underlaying layers (as in device drivers, for example), and one = of these queuing techniques are 802.11n/ac packet aggregation and = 802.11e QoS.
David said that, at = this time, the problem isn=92t going to be solved shortly, even if it = seems that there are already some ideas in order to solve this = problem.
In my specific = case, I would like to run fq_codel in a new (and very extended) mesh = network that doesn=92t match with some limitations; for example, if it = will occur that a link bandwidth falls below 4Mbit/s, mesh net will = consider that link not available to carry traffic, because I surely know = that it will not be sufficient to suit bandwidth requirements of my = network.
Also, I could = increase target and interval values whenever i=92ll need to adjust = settings that I can=92t expect now.
So, i was thinking = that, maybe, if i increase target and interval values to include packet = aggregation delay times in the overall delay, I could just overall the = problem, waiting for a fix in the future.
What do you think about? Is it a good compromise = or there are other aspects that i=92m leaving = behind?
Thanks so much for = your help!