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 [[email protected]] Inviato: lunedì 24 dicembre 2012 13.15 A: Alessandro Bolletta Cc: [email protected] 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 <[email protected]<mailto:[email protected]>> 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 [email protected]<mailto:[email protected]> https://lists.bufferbloat.net/listinfo/codel
_______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
