On Fri, Apr 17, 2015 at 11:06 PM, leetminiwheat <[email protected]> wrote: > I've tried, to no avail, to get certain traffic to go to the BK and VO > queues via DSCP and/or TOS mangling (with HTB+fq_codel egress/ingress > DSCP stripping/squashing turned OFF, i.e. flags enabled).
The VO queue is disabled in cerowrt in favor of better aggregating those sorts of packets into the VI queue. > > Is this a known issue? Or intentional behavior? Or something > misconfigured in qdiscs? Shoving tons of traffic down wifi which > should be DSCP/TOS flagged for BK or VO only puts it in VI or BE from > what I can tell from /sys/kernel/debug/ieee80211/phy0/ath9k/queues and > /sys/kernel/debug/ieee80211/phy1/ath9k/queues CS1 should land in BK, as best as I recall. > I've tried -j DSCP --set-dscp xxx in mangle PRE/POST and I see the > MARKing going on in QOS_MARK_$IFACE zone(s), so the traffic is clearly > getting marked for QoS bins > > A wireless "expert" friend of mine was saying a lot of WMM issues > weren't fixed until kernel 3.17-3.18? WMM is basically broken, conceptually, since the arrival of wireless-n and the existing structure of the wifi queue drivers in linux. See mit talk here, 2nd half: https://www.youtube.com/watch?v=Wksh2DPHCDI&feature=youtu.be > WMM seems particularly useful for mobile devices and/or crowded > airspace, so I'd like to somehow get this working right. No it is not useful for crowded airspace, unless you are trying for a temporary game theory win over everyone else that is not using wmm. I have long documented the ills of the VO queue in general in benchmarks and documentation on how it interacts badly with aggregation. As for using the BK queue effectively, a common problem is that much traffic is mis-marked as CS1 that should not be. I don´t recall disabling it in the stable release of cerowrt, nor did I attempt to push the patch up to openwrt, so openwrt probably continues to (mis)use the VO queue. In general, you do best by minimizing TXOPs and maximizing aggregation in crowded wifi environments. It is not "fixed" in any current kernel. Although it may be working better "as specified" in current kernels, the spec is basically wrong. We do propose a set of fixes in make-wifi-fast that will promote or demote aggregates to a more appropriate wmm queue when enabled. This is partially laid out in pp 26- http://snapon.lab.bufferbloat.net/~d/ieee802.11-sept-17-2014/11-14-1265-00-0wng-More-on-Bufferbloat.pdf One of these days we will get around to writing a paper on this, but I thought it would be best to focus on fixing it, first, then showing the differences with wifi behavior in real environments after, in particular, we get per station queues working with minstrel-blues. Gaining the resources to fix wifi has eaten most of the last 10 months of my life, AFTER helping come up with some of the theoretical fixes over the last 4 years. We are finally in a position to make a run at making deployable some of the same latency reducing techniques we have successfully applied to wired links to wifi, but MUCH work remains, and nearly zero funding exists, still. I had honestly hoped to be able to fully prototype and test the fixes over the summer, but that hope fades more and more every day. > _______________________________________________ > Cerowrt-devel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
