From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.mediaspot.net (mail.mediaspot.net [109.73.92.181]) by huchra.bufferbloat.net (Postfix) with ESMTP id 0C67821F155 for ; Mon, 24 Dec 2012 16:57:28 -0800 (PST) X-Spam-Status: No, hits=4.0 required=6.5 tests=BAYES_99: 4.07, HTML_MESSAGE: 0.001, TOTAL_SCORE: 4.071, autolearn=no X-Spam-Level: **** X-Footer: bWVkaWFzcG90Lm5ldA== Received: from exchange.mediaspot.net ([192.168.0.22]) by mail.mediaspot.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for Codel@lists.bufferbloat.net; Tue, 25 Dec 2012 01:57:25 +0100 Received: from EXCHANGE.mediaspot.local ([fe80::59f7:a31d:de3f:869b]) by EXCHANGE.mediaspot.local ([fe80::59f7:a31d:de3f:869b%26]) with mapi id 14.02.0328.009; Tue, 25 Dec 2012 01:57:25 +0100 From: Alessandro Bolletta To: "Codel@lists.bufferbloat.net" Thread-Topic: [Codel] fq_codel and 802.11n packet aggregation Thread-Index: Ac3hvTfMlk/Jf0FoRG6HUhVZ7NoZ6wACs8qAABwE8iI= Date: Tue, 25 Dec 2012 00:57:24 +0000 Message-ID: References: , <8674C071-D403-4221-B2AA-535ECC8208F3@gmail.com> In-Reply-To: <8674C071-D403-4221-B2AA-535ECC8208F3@gmail.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.0.55] Content-Type: multipart/alternative; boundary="_000_F52F175DFC537F48A43937B50B44BCA276D1021AEXCHANGEmediasp_" MIME-Version: 1.0 Subject: [Codel] R: 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: Tue, 25 Dec 2012 00:57:29 -0000 --_000_F52F175DFC537F48A43937B50B44BCA276D1021AEXCHANGEmediasp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Now I understand... I also tried to find out more specific causes for this = problem and I found them on Cerowrt wiki. Unfortunately, i'm not a networking programmer and I can't offer my (direct= ) support to the project, but I will give my effort into trying to find out= resources that could be helpful in order to fix this bug. As David described in his article on wiki: "It bugs us that there are milli= on activations of android a month with a wifi stack that can be so dramatic= ally improved by a variety of queue management techniques - and 10s of mill= ions of APs and 100s of millions of deployed wifi devices, all with problem= s -" I totally agree with his thought. I hope to find a way to help fq_codel's d= evelopment in the future. Thanks Alessandro Bolletta ________________________________ Da: Andrew McGregor [andrewmcgr@gmail.com] Inviato: luned=EC 24 dicembre 2012 13.15 A: Alessandro Bolletta Cc: Codel@lists.bufferbloat.net Oggetto: Re: [Codel] fq_codel and 802.11n packet aggregation You don't ever want to increase either target or interval... in fact, leavi= ng 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 i= s still a vast improvement on basically anything else, it simply isn't quit= e optimal for that environment. As to how long it will take to get this sorted, I don't think anyone will k= now 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 que= uing technique made on underlaying layers (as in device drivers, for exampl= e), and one of these queuing techniques are 802.11n/ac packet aggregation a= nd 802.11e QoS. David said that, at this time, the problem isn=92t going to be solved short= ly, even if it seems that there are already some ideas in order to solve th= is problem. In my specific case, I would like to run fq_codel in a new (and very extend= ed) mesh network that doesn=92t match with some limitations; for example, i= f it will occur that a link bandwidth falls below 4Mbit/s, mesh net will co= nsider 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 a= djust 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! Alessandro _______________________________________________ Codel mailing list Codel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/codel --_000_F52F175DFC537F48A43937B50B44BCA276D1021AEXCHANGEmediasp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Now I understand... I also tried to find out more specific causes fo= r this problem and I found them on Cerowrt wiki.

Unfortunately, i'm not a networking programmer and I can't offer my (direct= ) support to the project, but I will give my effort into trying to find out= resources that could be helpful in order to fix this bug.

As David described in his article on wiki: "It bugs us that there are = million activations of android a month with a wifi stack that can be so dra= matically improved by a variety of queue management techniques - and 10s of= millions of APs and 100s of millions of deployed wifi devices, all with problems -"

I totally agree with his thought. I hope to find a way to help fq_codel's d= evelopment in the future.

Thanks

Alessandro Bolletta

Da: Andrew McGregor [andrewmcgr@gmail.com= ]
Inviato: luned=EC 24 dicembre 2012 13.15
A: Alessandro Bolletta
Cc: Codel@lists.bufferbloat.net
Oggetto: Re: [Codel] fq_codel and 802.11n packet aggregation

You don't ever want to increase either target or interval... in fact, = leaving interval completely alone and slightly reducing target is all you s= hould 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 w= ill 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 que= uing technique made on underlaying layers (as in device drivers, for exampl= e), and one of these queuing techniques are 802.11n/ac packet aggregation a= nd 802.11e QoS.
David said that, at this time, the problem isn=92t going to be solved short= ly, even if it seems that there are already some ideas in order to solve th= is problem.
 
In my specific case, I would like to run fq_codel in a new (and very extend= ed) mesh network that doesn=92t match with some limitations; for example, i= f it will occur that a link bandwidth falls below 4Mbit/s, mesh net will co= nsider that link not available to carry traffic, because I surely know that it will not be sufficient to sui= t bandwidth requirements of my network.
Also, I could increase target and interval values whenever i=92ll need to a= djust 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!
 
Alessandro
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.ne= t
https://lists.bu= fferbloat.net/listinfo/codel

--_000_F52F175DFC537F48A43937B50B44BCA276D1021AEXCHANGEmediasp_--