[Codel] fq_codel and 802.11n packet aggregation

[Codel] fq_codel and 802.11n packet aggregation

[Alessandro Bolletta]

[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]

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't 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't 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'll need to adjust settings that I can't 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'm leaving behind?

Thanks so much for your help!

Alessandro

[-- Attachment #2: Type: text/html, Size: 3495 bytes --]

Re: [Codel] fq_codel and 802.11n packet aggregation

[Andrew McGregor]

[-- Attachment #1.1: Type: text/plain, Size: 2020 bytes --]

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’t 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’t 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’ll need to adjust settings that I can’t 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’m leaving behind?
>  
> Thanks so much for your help!
>  
> Alessandro
> _______________________________________________
> Codel mailing list
> Codel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/codel


[-- Attachment #1.2: Type: text/html, Size: 4556 bytes --]

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2326 bytes --]

[Codel] R: fq_codel and 802.11n packet aggregation

[Alessandro Bolletta]

[-- Attachment #1: Type: text/plain, Size: 3067 bytes --]

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 million activations of android a month with a wifi stack that can be so dramatically 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 development in the future.

Thanks

Alessandro Bolletta

________________________________
Da: Andrew McGregor [andrewmcgr@gmail.com]
Inviato: lunedì 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 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<mailto: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’t 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’t 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’ll need to adjust settings that I can’t 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’m leaving behind?

Thanks so much for your help!

Alessandro
_______________________________________________
Codel mailing list
Codel@lists.bufferbloat.net<mailto:Codel@lists.bufferbloat.net>
https://lists.bufferbloat.net/listinfo/codel


[-- Attachment #2: Type: text/html, Size: 5785 bytes --]