Microlags with SQM

And that is just fine, typically CS6 and CS7 are super sparsely used, so do not put application traffic into those classes. That said diffserv is a mess and as long as your marks do the right thing with your AQM you should be fine.

I still believe it to be sub-optimal advice to steer people to use CS6 for gaming traffic, but as I said cake, does not make a difference. For most user the internet link is << 1 Gbps while switches will be = 1 Gbps so the switch's behavior should have no measurable effect anyway. And a switch that by default will interpret dscp will be a rare unicorn... (switches tend to react to VLAN priorities, as is appropriate for an L2 device, looking at IP headers seems out of line for a switch). But as long as the cheap switch puts your game packets into something better than the background and default priority tier you should be fine. The trick is to only up-prioretize packets from a few select applications :wink:

This is not uncommon as this, IIRC was/is the definition for VLAN priority tags... But a device that looks into IP headers is not a "switch" in my book....

Well, it's super common, and they're often marketed to gamers. Prices start at under $40, and I don't know how you'd better describe this compared to "switch" for devices like:

https://www.amazon.com/TP-Link-Ethernet-Unmanaged-Replacement-TL-SG108E/dp/B00K4DS5KU/

Does DSCP based QoS using dead-stupid prioritization.

https://www.amazon.com/D-Link-EasySmart-Gigabit-Ethernet-DGS-1100-05/dp/B00AKRTLXA

Does DSCP based QoS, not sure what its scheme is.

https://www.amazon.com/Netgear-ProSafe-8-Port-Gigabit-GS108T-200NAS/dp/B003QTZN3G/

Does DSCP based QoS...

Because we're talking inexpensive and consumer devices, they probably outnumber enterprise devices on the internet by a factor of 10,000 to 1 :wink:

This becomes less true when you consider people doing video streaming and file sharing off their own NAS boxes, so that the gigE between different devices can be occupied quite heavily at certain times. It becomes even more important when you take WiFi WMM into account.

A lot of these consumer level devices, including WiFi / WMM have only really 4 tiers of priority, and they often cut things right at the boundary between EF and CS6 so that EF falls into the medium priority and CS6 and above fall into the top priority. Since most consumers don't have any traffic at all doing router advertisements or source-quench control packets or etc etc which you might want to reserve CS6 and CS7 for on an enterprise network... it seems to me that the main thing is to get gamers to put their game packets into whatever the highest queue they have available is. CS6 seems to do that whereas EF doesn't for WMM typically and often for these consumer QoS gamer switches etc.

1 Like

Not that it will help solving the issue, but I imagine that these speeds are beyond game requirements.

I would suggest that you continuously ping the game server (I mean while not playing) and also another server, simultaneously, and see if these lags will reflect in the ping speed for one or both servers.

Gamers are easy "marks" it seems. IMHO this is all crap and these devices should be avoided if this mis-feature can not be disabled.

EF will still end up AC_VO and hence above AC_BE and AC_BK, so EF still does the right thing. I also am not a big fan of WMM, but that is a different matter, in short I believe using CS6 for nor critical traffic to be not optimal, but hey, everybody needs to set the policy for their local networks and as long as that is consistent there is no better or worse IMHO.
As always, as long as AC_VI stays empty AC_VO will effectively be the one with highest priority and things will just work...

I disagree, the highest one actually in use (or put differently one class higher than the rest seems sufficient), that way one can extend the network to deal with more important packets in the future, turning to 11 from the beginning is too "spinal tap" for my taste :wink:
But again this is a matter of taste, and there is no real right or wrong, except that even a nice ISP will bleach CS7 and CS6 on ingress, while EF might have a chance to survive the internet passage, which might be interesting assuming one trusts the sending parties marking...

well, it can be disabled, but DSCP based switching is a great feature in my opinion. I have a single ethernet link between my desk and my router closet, at my desk are a printer (super low priority), a desktop computer with NFS home directory (low priority), a WiFi AP (priority depends definitely on which packet we're talking about certainly not the port its on, some packets are Smartphone VOIP packets at very high priority, others are NAS packets at low priority, then there's internet surfing or ssh at medium priority) and I have an ATA (highest priority). I don't do anything at all that has higher priority than making my business VOIP calls spotless. If my computer is running a simulation and dumps a gigabyte of data to the NAS (takes 8 seconds), how should packets be delivered down the single wire between my desk and my closet so that

  1. I don't drop a single VOIP packet and they have less than 1ms jitter
  2. Surfing feels unaffected even if my wife is loading netflix over the wifi AP
  3. The NAS uses all the bandwidth available in between those higher priority packets

You can't do it with QoS unless you use DSCP because the port doesn't correlate to the traffic.

Port based QoS works fine if you're going to daisy chain 25 dedicated desk phones and nothing else off a single port, or even off 4 or 5 ports...

Nope, it ends up in the lower priority AC_VI. So if you reserve everything above CS6 for special purpose packets that aren't actually on real-world home/business LANs (like inter-router messaging) then you lose the AC_VO queue entirely, which IMHO for people doing low-bandwidth highly interactive activities over wifi means a big loss, VOIP and games in particular.

If EF did wind up in AC_VO and in the highest queue of typical consumer switches, I'd be much more in favor of your argument. Also if these consumer switches had more than 4 queues, like if they had 6 or 8 queues, I'd be in favor of your argument, but when you only have 4, one is BULK, one is BE, and one is for your Netflix streams.... where do voice and game packets go? You certainly don't want them competing with netflix in the same tin.

Ok, so I tried doing what SaberJ2X suggested, but it made no difference for me. I haven't set up DSCP yet, but a friend of mine suggested to try disabling WMM. With WMM turned off the game ran flawlessly. I played for an hour and there was no stuttering at all. Of course it's not ideal to keep it turned off, because wifi is basically useless without it.

Ok, wait you're playing over WiFi ? Then you definitely want to turn on WMM and put CS6 on your packets to get them in the VOICE queue (EF doesn't do it). Most likely something else on your LAN is briefly using VOICE or VIDEO WMM queue and causing these lags.

Do you know the ports in use by this game? It's easy to add a couple rules for inbound packets to the user firewall... as for putting them on the packets outbound from your gaming rig... if you're on a PC it's doable, if you're on a console I doubt it.

1 Like

No, I'm using ethernet, and yes I know the ports for the game.

Ok, then I guess by disabling WMM you probably throttled your wifi and hence reduced the chance that other people on wifi interfere :wink:

Here's a link to an example script: Creating DSCP markings with iptables? - #4 by dlakelan

In addition to setting up DSCP you can set up a layer-cake instance on your wifi interfaces and set the bandwidth there say 10% lower than you use on your WAN, this will reduce the chance that people on your WiFi will hog the whole WAN, without disabling the high speed features that require WMM

Remember that on your WiFi, the egress should be set at say 10% lower than your WAN download speed, and the ingress at 10% lower than your WAN upload speed. It's reversed from what it is on the WAN.

AS far as I remember EF goes to the AC_VI, aka video queue, that should be fine. Unless you have a heavy user of the voice queue already, but then also using AC_VO will only make things slightly better, as your game packets will not be able to jump ahead of those, it will just be able to compete with them on an even playing field...

Here is a quick way to test, using putty as an example (these commands need to be run in a powershell terminal under windows 10 that was started with the "run as administrator" option):

# set putty to use dscp 46 aka EF on egress temporarily:
New-NetQosPolicy -Name "putty_ps" -AppPathNameMatchCondition "putty.exe" -PolicyStore ActiveStore -NetworkProfile All -DSCPAction 46

# show all defined NetQosPolicies (should show the just defined putty)
Get-NetQosPolicy -Store ActiveStore

# for the fun of if change to dscp 47
Set-NetQosPolicy -Name "putty_ps" -PolicyStore ActiveStore -NetworkProfile All -DSCPAction 47

# clean up
Remove-NetQosPolicy -Name "putty_ps" -PolicyStore ActiveStore

Note that omitting -PolicyStore ActiveStore should make the settings persistent...
See https://docs.microsoft.com/en-us/powershell/module/netqos/new-netqospolicy?view=win10-ps for more documentation. For all I know this might even work on windows 10 home and maybe Xboxen...

1 Like

It might be intersting to try the dual-XXXhost isolation modes as described in @dlakelan's link above, assuming that you have alimited number of computers in your network and game traffic is relatively sparse, that might help a bit already, although I guess with an LTE link there simply are numerous RF issues that can transiently appear as micro lags...

hmm, I tried,

if you find a better solution, I'd be interested too

I believe it is not WMM per se, but rather that wifi modes > N have a mandatory requirement for WMM and so, the issue is that you are stuck at 802.11N... In theory one could "defang" WMM by "bleaching" all DSCP of all packets traversing the wifi link....

Yes, EF goes to VI, the video queue by default. I personally use DSCP AF41 for Fubo (streaming TV) and Netflix and Amazon Video, which also goes in the VI queue. So I really don't want my VOIP or games competing with those. the VO queue has the shortest contention window, so it will generally go first when contending with others. But it has the most bandwidth limit, that's fine because VOIP streams and games are all typically much less than 1Mbps and mainly just need to get their small packets delivered on time, not a large number of them.

Basically I think these are correct usage of the WMM queues (ie. match the design intent), unfortunately, without lots of hacking (at the kernel level, or using hostapd features that aren't commonly available), you can't access the VO queue without CS6 or above... they should have made it EF and above, but at the time this got codified into the linux kernel things weren't so clear cut.

Also, switches like the TL-sg108e https://static.tp-link.com/2018/201805/20180515/1910012413_TL-SG105E_4.0,TL-SG108E_4.0,TL-SG116E_1.0(UN)_UG.pdf

In DSCP based mode, the IP packets are mapped to 4 priority levels based on the DSCP value (Lowest= 0-15; Normal = 16-31; Medium = 32-47; Highest = 48-63). The switch prioritizes packets with IP header based on DSCP priority first. Then, the switch prioritizes packets with VLAN tag but without IP header base on the PRI field. Finally, the switch prioritizes packets without VLAN tag or IP header based on port priority

which means CS1 is higher priority than CS0, and EF (46) is lower than CS6 (48), there are only 4 queues... so you really can't reserve one for special networking packets... It's less than ideal, but it's the way things are there, and I don't think they are the only cheap manufacturers to do something like that. the d-link switch I linked just doesn't say, the Netgear one is configurable with a web interface. Zyxel 1900 series is configurable, I don't know about their cheaper 1200 series...

The biggest problem is that every single prioritization scheme has some conflict with some other prioritization scheme, WMM, cheap switches, advanced switches, cake diffserv, etc etc they all conflict. Finding the lowest common denominator that makes use of the 4 main classes usually available really seems hard.

1 Like

It has the lowest bandwidth for sure as it does not allow to amortize the relative long-duration wifi preamble over more payload octets, for sure. But I do not actually see a total limit for VI (which is actually impossible, since any station can decide to send AC_VI packets potentially leading to a "collision-derby" on the "ether"). As always, fine tuned systems as yours use all of the subtly different priority mechanisms optimally, but for mere mortals it often seems better first to exhaust the conceptually simpler work-arounds ;).

I note the collision derby will also happen if somebody on the same channel close by uses AC_VI...

Yes, the first one is unfortunately common for VLAN priorities as well. There currently is a RFC draft that wants to re-define LE as 000001 (see https://datatracker.ietf.org/doc/draft-ietf-tsvwg-le-phb/) so that CS1 can be made higher priority than CS0 once again, as anybody just looking at the first three bit will treat LE as BE and that while not ideal does not result in priority inversion....

The second is fine as long as EF ends up higher than BE the gamers should be set. The idea is to keep almost everything at BE and only up-mark stuff that truly requires priority...

Honestly, I would either disable such a mis-designed feature, or if not possible replace the unit with something sane.

Again, if AC_VI is not already overused, that should not cause a problem IMHO.

Then don't, just disable the really erratic treatment be the cheap switches (and realize that they are cheap as they are artificially neutered by such weird L2/L3 mixing). Sure WMM is hard to avoid, but also not as weird as the switches you mentioned so can be dealt with. Regarding the mathematical analogy you propose, I would opt for getting rid of the most erratic terms before looking at the denominators :wink:
But everybody needs to make such judgement calls for their own network, just because I am appalled right now by the sheer level of creativity in madness; I am sure that if I had bought such devices I would try to use them instead of disposing them, just with lots of swearing :wink:

Exactly, and I think they're pretty common, so I see it as trying to design defaults that work well... I really think 4 queues is the minimum for anyone who wants to get into prioritization, and they're basically similar to WMM, low, normal, low latency, and realtime... Game is clearly realtime, VoIP is realtime, DNS and video streaming are low latency, web surfing is normal, and bulk data transfers are low priority...

The tags that seem to work widely afaict are:

  1. CS6 realtime
  2. CS5 or AF41 low latency
  3. CS3 best effort
  4. CS1 low priority

I think those work right with WMM, but not with cake due to CS3 going in video tin... :unamused: But cs0 inverts with CS1 in the switches... Meh...

1 Like

And this shitty behavior can really not be disabled? With a soldering iron perhaps?

Sure three or four not a conceptual difference, I just happen to be fine with three, and will only upgrade if unavoidable ;). In the limit two is the absolute requirement for prioritization, but I like the idea of being able to specify more or less than usual, and you just happen to require 2 levels of more, dine with me :wink: . Just because WMM has four does not affect me in the least, but I consider WMM not to be an exceptional great design.

This is not my approach, but leave everything in CS0 and test, if something causes problems figure out whether it causes issues for other traffic, than demote, if the something is in the receiving end promote it. More than one higher priority class only becomes an issue once users of the higher priorety tier start stepping on each others' feet. :wink: Ideally they will not... Personally, I consider web surfing to be more latency sensitive than streaming video (might be service dependent but we rarely/never see glitches), and hence see no reason to move video over browsing (but hey, we rarely stream higher than fullHD, mostly ~720p).

That is still network control, with CS7 being reserved, but I concede that with 4 queue devices like "special" switches and WMM if one needs 4 tiers there seems no way around this...

If a device will not treat CS0 as default it needs to go the way of the dodo, the only reason to use CS3 is if you want to be sure to have re-mapped everything, so CS0 is an indicator of an error. Otherwise, just stick to CS0.

I am not even sure that CS1 make all that much sense inside a homenetwork to beginn with, unless you have heavily congested links inside your own network. But again if stuck with shitty devices and the need for 4 tiers it is not that there are many options left.

I would still maintain, that a) maybe three are enough, and be better devices might be obtainable somehow.

I note that that switch allows to effectively disable this misfeature, by switching to Port Based QoS and keeping all ports at the same priority queue, the DSCP abomination really is optional :wink: . That is fine with me, by all means offer crazy modes that might be useful to someone somewhere somehow, as long as the craziness is either opt-in or opt-out...