On 1/29/17 7:36 AM, Jaap Buurman wrote: > One more question if you don't mind :) With the "mac80211 debloated > intermediate queues" do you also mean fq_codel (phase 2), or just > phase 1? > Also, has cake ever been tried instead of fq_codel to try and debloat wifi?
We used various simluations of wifi in cake, as one way to verify the performance of the codel algorithm. Simple example would be, firing up a test, and have a script... sleep 10; tc qdisc change dev whatever cake bandwidth 10mbit sleep 1; tc qdisc change dev whatever cake bandwidth 20mbit sleep 1; tc qdisc change dev whatever cake bandwidth 40mbit sleep 1; tc qdisc change dev whatever cake bandwidth 6mbit I fear, after getting some major testing done in the past week now that things are stabler, that this sort of emulation was insufficient to emulate the real behaviors of wifi in a noisy environment. (yes, we did do tons of live testing, too) I am, admittedly, now testing with 51 APs within listening distance, at the moment, which is far, far, far worse than the lab ever was. Some of the things we deferred for further research were ratcheting down on retries, and rate limiting multicast. It still seems, overall, better, (I haven't had a single crash or error in the log in 3 days of testing a build done friday on the archer) It's my hope we can get more people pounding things with flent's rtt_fair* tests to see how "right" the ATF is, and taking packet captures (aircaps) so we can see what else can be improved. I'm about to go try upping the multicast rate and/or re-enabling the igmp and multicast-unicast code.... _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev