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 [email protected] https://lists.bufferbloat.net/listinfo/codel
