Like a NAS home directory 
.
Well imagine you are watching live soccer and your colleague at some university dumps a bunch of videos of migrating cells in a petri dish on Google drive and your desktop, laptop, and your wife's laptop all decide to sync them over https, 800 MB *3 = 5-10 minutes later your video returns to normal resolution... 
Just about everything goes over http/s these days.
Of course you're right that it's good to have options, but I do think it's funny how different our opinions are here. Literally if the switch didn't have DSCP based QoS I wouldn't have bought it and would have bought the more expensive ZyXEL that does. I'm not happy that the implementation is so dumb, but it can be worked around. I see more and more of these low end switches with DSCP QoS I think it's practically required for a web managed switch these days. After all, the DSCP tag is where the priority info is. Port priority is literally only useful for single use equipment like a desk phone, ATA or game console, and then it only affects the switch directly connected, doesn't propagate through the network.
Cisco's opinion is
Following this rule, it is recommended to use DSCP markings whenever possible, because these are end-to-end, more granular, and more extensible than Layer 2 markings. Layer 2 markings are lost when the media changes (such as a LAN-to-WAN/VPN edge). There is also less marking granularity at Layer 2.
Of course they recommend DSCP code points more in line with your recommendations, but then their switches are seriously configurable with special queues that have different behavior per mark... Whereas home users typically get 4 fixed or if you pay more 8 adjustable weighted round robin...
In any case I think there are two approaches here, one is to try to minimize the role of specific rules, and one is to try to make the specific rules do what you want, and I think gamers tend to fall into the specific rules to do what they want category, from among all the users gamers and voipers are the most sensitive. So if @zsolszesz tries out DSCP, putting the game into the top tin of diffserv4 cake is probably the best strategy to ensure low latency and no conflict with other things that might be somewhat sensitive but less than games, like video.
It is correct that the signal is OFDM, but resource blocks still use TDM
Okay, how about switching to 2.5 or 5BaseT? 
Well, I assume that fair queueing and per-internal-host-IP fairness should have that covered pretty much.
Exactly, so fq really shines here; identifying the "true" traffic category is unfortunately a heuristic process and unless as fine-tuned as yours prone to suffer from both false positives and false negatives, so my recommendation is always start with as little classification/prioritization as possible and just move if you have to. In some cases like yours this process can end up with quite elaborate and optimized configurations (especially for a use case were network saturation is not the exception); for most users however, I believe something simpler to be good enough
There we differ, especially since the cheap switches only seem to offer some sort of precedence, which is nice in that it is relatively easy to reason about but dangerous as one can easily starve low priority traffic (and if the http traffic to manage the switch sits below a "ping -f -Q ${EF} 192.168.1.1"'s priority the best way to get access to the switch again is to unplug the cable to the offending machine...). What I want to say is, refined classification and layering does not come without side-effects, and few are as careful and diligent as you are to understand and minimize/eradicate those side-effects.
Anyway with your switch I would, if I absolutely had to use VLAN tag based prioritization.
To which I say, a) if only DSCP would be end-to-end, b) more granular only if you ever use more than 4 or 8 priority tiers (IMHO one should only do so under duress), I am not convinced that one needs 63 code points to map into 4 or 8 tiers, and c) VLAN tags allow for the same 8 tiers, so seem to be a good match IMHO.
This I agree with as being uncomfortable enough to grudgingly accept going the DSCP route, but only if that actually happens often enough in ones network.
Flattering, but I believe I just happened to read the same RFCs
Aka Precedence, as stated above easy to get the corner-cases wrong (starvation).
I do not see a dichotomy here, I am mainly arguing for keeping the number of bespoke rules and traffic classes as low as possible, to keep complexity at bay and the QoS set-up "easy" to understand and mentally debug. That very much includes the concession, that if the rules are not sufficient to maintain the desired behavior, more need to be added ;).
I use VoIP myself, and agree that this is a very sensitive application and a good measure of whether the QoS set-up is good enough, if calls suffer noticeably there is more work to be done
And there I disagree anything short of isochronously streamed video should not require a higher priority than default, I can see tough the rationale for placing video into its own tier to be able to have tighter control over the bandwidth consumed by video streams (but that very much seems to rule out using simply precedence prioritization in switches). That said, the proof is in the pudding and the OP should simply try what works better for his use-case. so +1
Pretty sure they mean end-to-end across the campus, ie the domain you control. So for example from my wifi AP to the switch on my desk to the switch in my closet to the router LAN vlan interface, through the router and back to the switch on the WAN vlan, or from an AP to a switch to a power line modem to a switch to a router and out the wan interface. Once it hits the ISP you're on a different "domain" and dscp should be laundered and folded.
Typically weighted round robin, and the $30 8 port switch offers 16 Gbps switching fabric, so you will always be able to talk to the switch from a direct connection, no single link can get close to saturating it.
I think the biggest issue encountered in the real world is starving sparse high priority traffic like a game or VoIP call or a "live" sporting event because few home LANs have malicious actors, and when a compromised device shows up DoSing your LAN it's detected and unplugged because there aren't 20000 ports on a university campus to search through.
My experience suggests that these switches are pretty useful, even if only to reorder packets before they go down your bandwidth limited power line modem link where a single smartphone syncing your photo collection to Google photos can saturate the link and bork your TV. That kind of accidental DoS is more common than the intentional style of flood pinging. Before I set these up my soccer games would go through regular periods of fuzzing out for 10 seconds, usually right during a goal attempt 
I set up CS6 for the game's packets. I tested it for a few hours and the results were really good. There were rarely minor stutterings, which can easily be because of the instability of LTE. Also, I have no idea why, but I no longer have spikes in bufferbloat when I do a speedtest on DSLReports.
Ah, great that I misunderstood this, much saner that way.
I guess I would sandwich such a link with competent qos on both ends instead ; but sure point taken.
I will also try to stop this side-discussion here, as much fun as it is, to not de-rail the thread.
Do these go away, when you undo, using CS6 (so use CS0) for the game, and how well does EF marking work instead of CS6?
Final question, which method did you use to set the game to CS6? I ask as that question often comes up and I would like to be able to reliably answer that question.
I somewhat have the same problem...
There is some small lag in cs:go.
Like when switching weapons there is a small delay.
But in game latency is completely fine.
There is also no packet loss.
With fq_codel it is the same.
Also the in game latency fluctuates by around 10ms.
I have the feeling with pie it is better.
Latency doesn't fluctuates as much as with fq_codel/cake and stays on the lower end for a longer period of time.
This on a docsis connection.
But it could also be that my ISP is messing around or somewhere on the path to the servers something is going on.
I need to test a bit more.
Which version of CS:GO, i just installed cs;go warzone, but didn't tried it yet.
Latest version.
Hit registration also seems weird sometimes.
On my 50+ ms LTE connection (phone/USB tethering) hitreg seems better then on my 20+ ms docsis connection with sqm.
Diablo 3 also feels snappier with pie.
The docsis connection seems fine, according to the modem stats. Speed test shows good results, doing a manual ping test also doesn't show any anomalies.
what's your upload speed on the DOCSIS connection vs on the LTE?
I believe there was another thread here were a higher RTT (within reason) resulted in subjectively better game experience. Maybe CS's latency equalization method favors some RTTs over others. I had assumed that the match-making algorithms on a game's server would attempt hard to only match players with reasonably equal RTT and RTT jitter....
Upload speed on the docsis connection should be 40 Mbit/s.
But most of the time only 20 Mbit/s are going through.
I think it is a congestion problem, sometimes 40 Mbit/s are achievable.
Technician was here, of course everything was fine then.
But i don't care about that because i actually don't need 40 Mbit/s Upload.
Was a cheap offer... xS
Upload on the LTE connection, i don't know,
speedtest only work for the download direction for some strange reason.
Download is around ~10 Mbit/s, so i think Upload is somewhere in this range...
@moeller0
Yes, seems like players with higher latency have an advantage over players with a lower latency...
Worst latency is like 35ms but i it feels laggy.
This i a bit hard to diagnose.
Could be congestion here at the segment, congestion on the path or the servers are just bad.
The servers are behind a "routing cluster" to prevent ddos i think.
So doing a long time latency test is not possible.
Last time i played d3 a few months ago latency was like 25ms.
A few days ago i started to play it again, latency is now at 50ms.
Don't know whats going on here xS
And for the sqm-scripts, the simple.qos uses 3 htb tiers, all with the same latency target.
Doesn't it make more sense to have higher latency target for the bulk queue for example?
do you set your upstream shaper to 20Mbps? or do you try to have it shape to 40?
I was more concerned you might have like 3 Mbps up or something, resulting in 4ms of jitter right off the bat due to 1500 byte MTU
Setting the upstream shaper to either 20 Mbit/s or 40 Mbit/s makes no difference.
I also tried limiting the max packet size through a in game setting to 576 (default 1200).
Also makes no difference...
I can think of several issues:
the PIE shaper on the DOCSIS device might increase the latency in a stable way, and the game might be more forgiving for somewhat higher latency players...
The PIE shaper and the Cake/SQM shaper might interfere with each other, and you get more drops in PIE due to presence of SQM?
SQM might be dropping some of your game packets, set up layer_cake and make sure the game has a high priority DSCP, like EF or CS6, either one will be the same for Cake, being in the higher priority tins means probably fewer drops for the game packets.
I've heard claims by several that specifically CS:GO "lags" on newer (computer) builds and a friend looked into one of those instances and came to the conclusion that it was more or less placebo/not fixable (read on).
If it's another issue, it should be easily logged by the numerous gaming frame rate utilities available.
Pie is only mandatory in DOCSIS 3.1 CPEs (modems) and if the router pre-shapes egress traffic to < contractual rate, PIE will never really trigger (unless the DOCSIS link is congested to such a degree that the contracted bandwidth can not reliably reached). @shm0 are you using DOCSIS 3.1 already?
Should not happen otherwise DOCSIS-PIE would be buggy, which I consider to be unlikely.