There are many people who try hard to game on slow asymmetric lines such as DSL with 768kbps upload. Because cake and SQM do such a good job, they often think they can just tune it right and they'll get good game performance, but they find that no matter how much they tune things, it just never works well when someone else on the network is doing something.
So I posted a blog post that does the math and summarizes why even though games only use a few hundred kilobits per second themselves, you can't expect good game performance unless you have a ~3Mbps symmetric line or better. You will get progressively worse performance until at 768 kbps any other traffic on your network at all will inevitably result in delays so long that it's as bad as a packet drop.
So now, we can just point people to this thread in the future.
I will entertain any questions that are about the mathematics of how this calculation works etc, please DO NOT post in this topic about what to do about it for your personal line. If you have questions about your personal connection and how to tune it, start a NEW THREAD and then point to this thread from the first post if you want to reference this.
After we've got the main questions about the math cleared up fully, I want to mark this post as closed so it's always just ~ 10 posts or less and anyone can read it and understand the core mathematical issue and understand the fundamental limitations of SQM/QoS for gaming at low rates.
Typical games send and receive 100 to 400 kbps of data, and they do so on a "tick clock" that is a UDP packet is sent every time the clock ticks... A typical network tick rate for a decent game is 1/64 of a second as shown in the graphs in the linked article. So... if a bulk packet of size 1500 bytes is sent by your router to your DSL modem and then it immediately receives a game packet and sends it immediately after... the DSL modem, if it operates at R kilobits/s will delay the game packet by
1500*8/R
milliseconds...
If we set this equal to the interarrival time of 1/64 of a second = 15.6 ms then we can solve for the bandwidth R such that even one packet ahead of you in the DSL modem delays your game packet by as much as if you'd dropped that packet...
1500*8/R = 15.6, so R = 1500*8/15.6 = 769kbps
In order for you to game on a shared line, you want at a MINIMUM that one extra packet in the DSL modem ahead of your packet delays you by no more than half the inter-arrival time of the game packets... this means that 2 extra packets in the modem would delay you by an interarrival time... so about:
2*1500*8/15.6 = 1538 kbps
That is THE ABSOLUTE MINIMUM speed you should have in upload to be competitive in gaming on a shared line.
If you DOUBLE that speed to 3000 kbps you will be even better, so I consider 3Mbps to be the minimum speed where you can complain that SQM or another Qdisc is not doing a good job. Anything slower than that and it's really not in the hands of the qdisc, it's all about issues in your modem serialization speeds.
I'm posting this as the TL;DR version of my blog post, and marking it as the answer so this thread closes 10 days after the last clarification below.
Of course there's much more, such as congestion along the path, and your ISP overselling, and wifi vs wired and etc but fixing those things won't matter unless you have the bandwidth to avoid this particular pain point. The point here is just to do the math about this particular pain point to show what is unintuitive to many about why you need much more than the bandwidth your game takes (~ a few hundred kbps) in order to avoid bad gaming performance on a shared connection.
Like light coming in photons, this is kind of the quantum mechanics of packets... they come in chunks, and a 1500 byte packet ahead of you is always possible, unless that won't slow you down too much even ONE packet ahead of you will break your game, and one is the smallest number of packets bigger than zero, and zero is what you get when you have a dedicated line.
Which brings up a good point that was mentioned above... If you have less than ~3Mbps and want competitive gaming, you can get an extra DSL line with a speed at least 2x the game's required bandwidth, and use Mwan3 and cake to send only game packets over this line, and get acceptable game performance down to 700kbps or so.
The way I see it, is that low access rates almost guarantees a relative high jitter (latency variance) and it that jitter that the game servers can not properly correct for and that causes the hanicap in gameplay for the affected users.
The topic is still misleading and "almost guarantees" doesn't translate into "Why", rather "Why you most likely..." is a much more accurate phrasing and still doesn't cover anything else except barely for the customer premises.
I think you're misunderstanding needing something (ie. it's required) compared to it being sufficient... "you need to eat sufficient food daily to have a happy life" is not the same thing as "if you eat sufficient food daily you will be guaranteed to be happy"
Without 3Mbps you can not get good gaming performance, with 3Mbps it's possible you might be able to get good gaming performance if your ISP and all the other ways that things could go wrong cooperate as well.
I would say yes. There quite some users coming to OpenWrt with the primary goal of improving their network for on-line gaming, and hence it seems relevant to properly explain what is and what is not realistically achievable. The alternative, I fear, would be loosing the game users again with the impression that OpenWrt over-promises but under-delivers. IMHO that outcome should be avoided.
Sure that might not be a direct connection to OpenWrt strong enough to convince everybody of this post's relevance to the forum, but honestly that holds for many of the AQM/QoS threads as well.
There have been at least tens of threads about how SQM doesn't fix gaming performance. Often a lot of time gets spent tuning SQM, and then it still doesn't "work"... The problem inevitably is that the user has 700-2000 kbps in the upstream direction and whenever someone else uses the network the game suffers. The point of this thread is to do the math in one place to show why SQM can only isolate your game traffic when the bandwidth is high enough that packets can slip between your game packets without delaying the game by more than a small fraction of the network tick rate. This transition occurs between about 1500 and 3000 kbps and above 3000 kbps SQM can work well, below it can be perfectly tuned and still the math says it will be hurting you to have other traffic on the network.
I'm glad you made this thread...there's a gentleman who makes random threads...always about how to improve their gaming performance...
SQM
UDP tweaks
MSS tweaks
Tunnel UDP thru VPN to another VPN
...but always fails to mention their DSL connection and general latency to the servers in question anyways (i.e. the OP's ISP poor interconnections to the global Internet).
Given HD video streaming, online primary schooling, etc...you need at least 3 Mbps (or much more) anyway.
In essence I think what is effectively being said is that if one full size packet causes the equivalent in jitter of a gaming 'time slot' then the link doesn't have sufficient capacity, ie. even with perfect clocking/queuing (see cake...ok I'm biased ) then there is still the possibility of just missing your time window and a full size packet getting in ahead of you. Cake (with ack filtering etc) will help reduce the chances of that unfortunate timing but it clearly cannot eliminate it. So if you can't eliminate the quanta of one packet, you could reduce the size of packets. For low capacity links tweaking the MTU down (but not below the game's packet size) would help reduce the jitter, I reckon by a bit over half. Anyone remember the Internet over dialup and MTU 512
In total coincidence, CAKE's highest priority tin (Voice) gets 1/4 bandwidth as a minimum guarantee, and 768kbit * 4 = 3Mbit
We are doing some experiments on tweaking the MSS for TCP down. You can't drop MTU below 1280 for IPv6 but at layer 4 you can ask TCP to use smaller packets... Will see how that works
That will work within reason, different systems have different minima, but since IPv4 still is RFC'd to expect an MTU >- 536 or so bytes, your selected 540 Bytes should work.
Macos has a minimum MSS of ~200 Bytes, and Linux also increased that recently to avoid a few DOS attacks in which too small an MSS allowed to exhaust a servers resources too quickly. I think it was one of the code-named exploits, but I do not remember the name, let alone the CVE....
Interesting writeup. I was stuck on an ADSL connection for a little over 12 years (2006-2018), and while I first witnessed what bufferbloat and standard, unfair FIFO queuing can do to such a connection way back in 2010, it was a practically impossible to find any real discussion or relevant documentation of the issues back then. Back then, people generally pointed the finger at ADSL being too slow, and to "get better Internet", even though I've seen similar problems affecting DOCSIS connections as well.
Although much faster than any ADSL connection on paper, I know that gigabit DOCSIS 3.0 connections can have problems with TCP throughput, due to the downstream/upstream ratio exceeding 28:1 (!). That's worse than ADSL2+ which is already bad at 24:1 on a short line (and assuming the Annex M bandplan isn't in use).
For me personally, it wasn't until 2016 that I first heard the terms bufferbloat and fair queuing, along with the relevant discussions online. Soon after I switched to pfSense and started using FQ_CODEL, but in my time trying to fix these problems with my ADSL connection, I came to the conclusion that I was just polishing a turd. I really was overdue for a better Internet connection, although I had no other options for uncapped Internet access until VDSL2 arrived in my area in 2018. I'm now running at close to 100 Mbps down and 20 Mbps up.
I feel really bad for anyone still stuck on an ADSL connection in 2020.
Sure, but account for any other upstream traffic alongside TCP ACKs, and it won't be a good experience, at least from my own personal experience with ADSL connections. The single megabit you typically get (or rather, some 860 kbps after ATM overhead) is practically useless in reality.
Ok, there's enough data now on the other thread to point at least to the fact that by MSS clamping to reduce the TCP datagram size down to 540 bytes gaming can work well down to about 700kbps upstream with highly tuned scripts.
) then there is still the possibility of just missing your time window and a full size packet getting in ahead of you. Cake (with ack filtering etc) will help reduce the chances of that unfortunate timing but it clearly cannot eliminate it. So if you can't eliminate the quanta of one packet, you could reduce the size of packets. For low capacity links tweaking the MTU down (but not below the game's packet size) would help reduce the jitter, I reckon by a bit over half. Anyone remember the Internet over dialup and MTU 512 