From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 351FF21F5D0 for ; Fri, 17 Apr 2015 23:57:07 -0700 (PDT) Received: by oiko83 with SMTP id o83so91052016oik.1 for ; Fri, 17 Apr 2015 23:57:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=LsLJQSL27zC/g/aOOI5AhBo6e9omaL30dO5047l4SZA=; b=WrwINIW6aitW7vBHSWBeMEd3xBWEYiClTDYx7cZXip/QWx+nVANvW+waHkyhn5cgNT Be0jMfWoOVWJPuykVUF0GFSA2j3dCAJUhRITSHmuET3HhjYXUFBdYhWv3j5jK5J6KM/1 hGswJO0tuHyxP4YLwqKLXWjVecx2rZHnb91971gdEBr0fAfLleKF40P8lJ5rPt91SqGT ML7acEMXEkveeWri6sri0GaQ/7F6dIvQhR2IonNIbfALT5ksyEuXZAQ0CsBqS1vv2OBH QOisDVRxPIBThi+Ax59wHVx3KriI7sFE4IijAwWQnrl7SHoce+Ol3hjbYAOBD2GAylr1 OUjw== MIME-Version: 1.0 X-Received: by 10.202.216.87 with SMTP id p84mr5714429oig.133.1429340227007; Fri, 17 Apr 2015 23:57:07 -0700 (PDT) Received: by 10.202.71.139 with HTTP; Fri, 17 Apr 2015 23:57:06 -0700 (PDT) In-Reply-To: References: Date: Fri, 17 Apr 2015 23:57:06 -0700 Message-ID: From: Dave Taht To: leetminiwheat Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cerowrt-devel Subject: Re: [Cerowrt-devel] ath9k WMM not obeying DSCP/TOS flags? X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Apr 2015 06:57:36 -0000 On Fri, Apr 17, 2015 at 11:06 PM, leetminiwheat w= rote: > 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=3DWksh2DPHCDI&feature=3Dyoutu.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 tempo= rary 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=C2=B4t recall disabling it i= n 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 > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67