TL;DR Is there a way to configure SQM such that my wired performance is the same, but I can set up a separate 100mbit/s SQM limit just on wlan0?
I have the WRT1200AC set up behind a SB6183 cable modem. I have a 5ghz wifi network as well as a 2.4ghz network set up. I am using cybernook's latest beta build for WRT1200AC (Build for WRT3200ACM (Discontinued) -- https://www.dropbox.com/sh/ytz7gwtpa75rlrs/AAC2BJpxHcs-7nE9Oq1itWoea?dl=05)
The 2.4 ghz is set to auto-channel/auto-power/20Mhz width since I have so many 2.4ghz networks in my apartment complex, and I kinda don't care about performance on this channel, it's mostly for webbrowsing and basic connectivity.
The 5ghz network is set to channel 149/80hz width and 30db/m power.
When I enable SQM with cake/piece_of_cake.qos with everything default and ingress at 210000 kbits/sec and egress at 10000 kbits/sec through LUCI, I am getting fantastic wired latency and perf of around 5ms or so. Essentially the entire 200 mbit/s down (I know I am overprovisioned to 240/10 down, but I'll squeeze the last drop out of that once I get WIFI fixed).
For wifi over 5ghz, my latency is awful because the speed I'm getting down is only about ~150mbit/s due to WIFI link being poor. This causes the ping to oscillate to ~200ms. If I set the ingress to 100000 kbit/s, I get the full 100mbit/s at 15ms latency, so I know the problem is because WIFI link speed isn't high enough to get >100mbit/s. I don't want to hobble my wired devices to 100mbit/s just because my wifi sucks -- but I would like SQM on both wired and wifi.
Is there a way to configure SQM such that my wired performance is the same, but I can set up a separate 100mbit/s SQM limit just on wlan0?
So it is possible to concurrently use multiple concurrent sqm instances as long as each "lives" on its own dedicated interface, so if the wlan interfaces show up in the interface selection box of the GUI you can just configure your new sqm instance. But please note that the download and upload direction are always in relation to the current interface, so for WLANs I would expect that the filed label download actually controls internet upload, while the field named upload controls internet downloads, so make sure to put in the correct values and/or try both combinations...
If I change the values for wlan1 in the LUCI dropdown though, it changes it for eth1 as well (seemingly, anyway).
I figured it out, just use the "add" button in the GUI top right! 
Great work, that button is a bit subtle 
So this ends up working some of the time, but I have to constantly turn this off when I want more bandwidth when I'm trying to run intra-WAN traffic like Steam Link (this encodes a video stream from my PC on 5ghz wifi to my steam link box which is also on 5ghz wifi).
Is there a way to effectively apply the 100mb limit/SQM to the internet traffic that's coming into the network and discount all the inter-WAN traffic that's going on in my house? I suppose not, because I would have to constantly update that 100mbit number based on the max signal on my wireless box. Is SQM the best way to achieve low latency here? Should I be using something else that deals better with differing bandwidth, is there any kind of SQM that does auto-negotiation of the WAN speed limit?
Yes this pretty much sums up the downside of using a fixed bandwidth shaper on a variable bandwidth link; you need to leave significant amounts of bandwidth on the table so that the shaper has a chance of reducing bufferbloat most of the times; the more bufferbloat avoidance you need the more bandwidth you need to sacrifice.
That is not going to work well. The issue is that t control WIFI bufferbloat the source and destination of the packets are irrelevant all that is important is that packets are on the WIFI link, so if you would only shape internet traffic on wifi, but not internal traffic, than high bandwidth internal traffic will overload the wifi link and you will see bufferbloat on the link for all packets independent of provenance or destination (and with wifi being half-duplex even traffic in one direction can hose bufferbloat in the other direction as well).
There is the make-wifi-fast project which made some inroads in increasing the responsiveness of ath9k based wifi in linux and there is also some effort on ath10K radios, but ath9K is furthest along, But I have a hunch that "adding another wifi router as AP" was not the response you were looking for given that your WRT1200AC is quite capable otherwise....
Ok, I figured as much.
Kinda bummed out that most likely, the ath9k work won't make it into mlwifi driver that will help the 1200AC. I thought long and hard about getting the R7800 before my entire fiasco with the 1900/1200. I should have gone with the 7800, but I got a little scared by the WIFI driver stability I kept reading about, and the price difference between $75 USD and ~$190USD for the R7800. I should have just gotten the 7800. Oh well, maybe in a couple of years I'll have more options.
Thanks again for all the help!
try " tc qdisc add/replace dev wlan$ root cake unlimited besteffort " from the command prompt and if you like the results add it rc.local or create a hotplug script.
I know this was ancient history, but since mindwolf dug it up 
you can set DSCP tagging rules in your firewall and then the WMM queues should be engaged. If you have low latency traffic just make sure it gets tagged with DSCP CS6 as it transits the router towards your LAN, and it will go into the voice queue. CS5 will go into the video queue, and CS1 will go into the bulk queue.
There's really no need to keep latency low for all traffic, only for latency sensitive traffic. For example multi-hour torrent streams could experience minutes of stalling and no one would really notice.
Old threads can provide new education 
1 Like
PLease also note that the diffferent WMM classes have different access probabilities and different payload size restrictions, so VO and VI will probably get air time sooner, but at the cost of reduced throughput. And since wifi is a shared medium they will sort of jump in front of all traffic on all radios/APs that can receive them. With an unfortunate traffic pattern, lots of VO packets can starve the other classes for air-time and since VO does no meaningful aggregation, the effective bandwidth even for VO will be relatively low.
Tl;dr: the effect of the 4 wifi priority classes and their mixed use on latency and throughput is less pedictable than one would like. Case in point for some time cerowrt did away with the 4 classes (by forcing DSCP 0 on all packets IIRC) and still VoIP worked reasonably well. The current air-time fairness patches in ath9k and ath10k? might also help on getting better VoIP quality over WIFI even without the use of WMM priority classes.
It seems to me that the VO queue works quite well for VoIP type traffic. It's a good idea to manage the dscp in router so that only low bandwidth traffic similar to VoIP uses VO, so that starvation can't occur. VI I'm less sure of but I use it on the output of my proxy when downloading YouTube or Netflix for the first 20MB and it generally means zero waiting during streaming. After the first 20mb a conntrack rule remarks to CS1 and the remaining traffic goes into a low priority queue since streaming has typically tens of seconds of buffers.
The results seem to work well so I think the wmm queues work as intended for their purpose. I imagine they might fall apart for traffic patterns different from the intended.
Haha, the issue I see is that they are a cooperative best effort kind of thing that might work in a friendly environment, but considering one's RF-suround as anything but hostile seems a bit optimistic.
I am not sure, I believe with DASH nowadays the streaming applications buffer and quality control relies heavily on latency and bandwidth, so a few VO users in your RF environment might be sufficient to noticeably degrade dash -type applications like youtube and netflix, but it is a long time since I tried this, so maybe all I was running into was a sub-optimal implementation instead of a somewhat temperamental technology...
Seems to work for me, but I'm not in a terribly hostile environment like a hundred unit apt building with one wifi per unit.... I suspect streams tend to set their quality based on the initial characteristics and have some resistance to changing quality midstream. The high priority for first few tens of mb seems to get me a stable high quality buffer setting which doesn't suffer once it is retagged cs1 later.
In any case I don't have tons of stalling, even in the bulk queue it probably has only 100ms delays typically. I've seen unmanaged public WiFi with 5000 ms bufferbloat and I'd not recommend this type of strategy with those sorts of conditions 