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