I am using a 4G+ modem in bridge mode, connected to my Linksys WRT1900ACS. The advertised speed is 225 Mbps down and 50 Mbps up, but the download is usually around 150-170. The problem is when I play CS:GO I randomly experience microlags, even though I get good results on DSLReports.
Here are my speedtests:
SQM off: http://www.dslreports.com/speedtest/47347524
SQM on: http://www.dslreports.com/speedtest/47347351
And these are my SQM settings
I'm not sure what "microlags" are, but I'm guessing it refers to short-term increases in packet transit time.
As even 4G wireless tends not to be as robust and predictable as most contemporary, wire-based transport, are these anomalies present without SQM?
They are, but only when I play CS:GO though. Other games run perfectly.
If they are present both with and without SQM then they are probably something caused by some other place in the path between you and the server... SQM can only really control the link between you and your ISP, and even then only really control the buffering behavior. It won't control brief loss of connection, packet loss at routers, buffering at your ISP's core routers, issues on the server, etc.
Also, cake with piece_of_cake will not distinguish between your game and other flows... so if it has to drop packets there is some probability your game packets will be dropped. Turning on per-ip-fairness and making sure that your gaming machine is not doing other kinds of traffic during games should make your machine stay well below its "fair share" and that will mean it will not be subject to cake dropping its packets.... see how to enable per-ip fairness on the cake advanced options wiki page https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details?s[]=cake&s[]=sing
on my ATT LTE connection Ido the following...
go to speedtest from ookla, run the benchmark...
mine stably landed in the 50mbps zone in the morning, but during congestion it usually dropped to 20-27mbps
I made a config with "rtt 33ms" in the ingress in the really advanced settings
and now my connections has low bufferbloat when it's good and it's bad, and it throttles with the connection all day long, 40-50mbps in the morning depending on pings, and 25mbps when it's bad.
you can say it's a poor man's auto-ingress
Cake doesn't really work that way, so I'm a bit confused how this works
may be that reducing cake rtt effectively limits the tcp congestion window and thus the size of data-bursts enough so it does not cause noticeable serialization delay in the upstream router?
The cake rtt affects how quickly it begins to drop packets to throttle connections, but if you set it to throttle at the high speed, then it won't do anything at the low speed... The provider will control the bottleneck, if you set it to throttle the low speed then it will never go above the low speed.
not neccsarily; if the upstream network is fast enough so that a data-burst takes longer than cake-rtt to drain from the ingress queue, it will drop a packet even thou the effective transfer rate is below the cake limit.
If cake is set to 50Mbps and the upstream is currently operating at 20Mbps how will you build up a queue? Even if it "bursts" at 20Mbps forever cake will let 50Mbps through and you will have zero queue. I suppose if it's doing something like time division multiplexing, giving you a few packets at a gigabit and then nothing for a long time... Is that what you meant?
yes
wireless and cable are especially affected due to mentioned tdm
i meant the "upstream" network i.e. the isp
NOT the transfer speed to it (upload-speed)
@zsolszesz have you tried?
but on the greater topic: as mentioned wireless is inherently plagued by jitter.
most ppl use dsl-internet + lan-cable for competetive online gaming.
Reading up on LTE it seems to be OFDM so the user gets a frequency slot not a time slot.
Your dslreports results seem pretty darn good. I have to go back to this statement. It indicates to me either an issue in the game client or in the path to the server or in the server itself.
I haven't yet, but I will. I tried fq_codel on ddwrt though. When I prioritised the ports of CS:GO, it became a lot better. It wasn't perfect, but there was much less stuttering. Maybe I should try layer_cake with dscp marks?
Absolutely, if you know how to get the DSCP on your packets this is the way to go. I'd recommend using CS6
@dlakelan I think our UDP rule will catch CS"GO traffic!
THe actual code point does not matter, as long as your AQM honors it respectively. Speaking generally a game should not be placed in CS6 IMHO, as CS6 and CS7 "traditionally" are used for Network Control (think routing, or PPP keep-alive packets). EF would be more traditional marking even if you consider gaming to be important 
For layer_cake this does not matter too much as both diffserv3 and diffserv4 will put CS6/CS7/EF into the high priority tin anyways
IMHO this concept was put in place in 1998 or so by network researchers when zero people were doing realtime anything on the internet especially at the edge where DSL 1.5/0.768 was absolutely an emperor compared to the 56k dialup modems we were all used to.
Since then there are lots of cheap consumer QoS enhanced switches that basically treat CS as an ascending priority, (Tp-Link even puts CS1 above CS0 !) and will put EF in a different bucket below CS6, also the Linux kernel + hostapd does this same thing by default in WMM queues for wifi. Basically the horse left the stable in like 2007 or so when these cheap switches and 802.11n WMM came on the scene.
Based on that observation, CS6 is likely to work slightly better in circumstances where those extremely widespread cheap switches are deployed or where you try to game over wifi (yeah, not a good idea, but still).