Help prioritizing games with alternative qdisc design

That is a good illustration about the difference of our approaches. I seem willing to accept that different use cases/challenges require different tools, while you seem to be trying to solve all issues with just one tool. Classifying by size is IMHO orthogonal to classifying by internal-IP, there can be use cases where one can stand in for the other but that is by no means true for any specific use case of either.
Again, I am happy to accept that marking by internal IP/port is not very important for you.

More power to @nbd for implementing that (EDIT: classification by size), but that does not IMHO change the fact that these are different classification methods that are not equivalent to each other.

That you are welcome to, but please without thrashing valid alternatives as "obsolete". If you claim that the onus is on you to demonstrate convincingly why you consider alternatives as obsolete... Just as food for thought, nobody, including cake's principal author is pushing for making cake the default qdisc in Linux, most de-bufferbloaters agree that fq_codel is an excellent default (and hence hardly obsolete).

But from a user perspective you are trading off a limited and specialized tool that does a few things well versus tools that allow to do much more... and in a way where users now need to learn both... Again, I am not arguing against quosify here, just against your claim that iptables/nftables are obsolete.

That will take a while sure, we are in the process of exchanging the back-end behind the iptables binary with nftables, so going eBPF for everything (if possible) will take a bit longer.
If the options that quosify offers suit your use-case, I fully endorse your recommendation and support of it, but again, please do not trash other use-cases that are currently not well served by quosify.

As they say, if all you have is a hammer, all problems look like nails (but we have a fuller toolbox and hence can use a screwdriver if the problem looks more like a screw than a nail, no?)


The original reason for this script was to handle the cases where bandwidth was so low that cake by itself with DSCP had simply failed to achieve sufficient responsiveness. In particular the DSL connection for @Knomax was something like 10 Mbps down and 0.75 Mbps up and he wanted to play games that required ~0.5 Mbps dedicated upstream (numbers approximate).

The HFSC qdisc used here with a realtime class can achieve this whereas CAKE simply couldn't.

Of course this script is designed to be used for everything from that limited connection all the way through maybe 1Gbps with sufficient hardware. However it specifically takes a different view than cake, and the performance is based on the split slope nonlinear service curve. Unless you understand how those work, please stop saying that this script and others like it are obsolete. Cake is a good piece of software however it is nowhere near as precisely tunable as HFSC and is not designed to be.


Exactly, cake offers only a very limited set of capacity sharing hierarchies (IIRC, 1, 3, 4 or 8 trees), when ever one needs a more bespoke set-up (including targeted un-fairness) it is time to built appropriate shaper trees. Different traffic shapers have different pros and cons, but cake's biggest short coming is IMHO the fact that one can not configure the min and max rates individually for the different tiers (many use-cases should be solvable with either 3, 4, or 8 different priority tiers). As you say, that is on purpose, as cake is aimed to be usable by mere mortals so it tries to avoid too complicated configuration options that are hard to get right.


You could end up just using the existing includes structure to add new chains to the inet fw4 table, unless you plan to do a netdev table. (Sorry to bring the thread back on-topic).

1 Like

Qosify is what I've always wanted (thanks @nbd) and that is the reason why I share it, but I see that many like to reinvent the wheel.

Wrong meme, more like this, pick and choose the best that suits you, some of us did.


An argument that is not that convincing given that the script this thread discusses existed well before quosify, no? As temporally seen quosify would be the reinvented wheel (not that the thread-script is conceptually the first wheel either), but you are not arguing for quosify to be scraped?

IMHO there is no reason why we should only have one specific model of wheel, like in reality having a choice of diameter, weight, load bearing capacity and what not seems a good thing :wink:

1 Like

hello to all so this night I had fun retesting the script I had some pretty good games, a little later I put QoSify and my games were much better it's not necessarily qosify but the settings that elan has proposed which in my humble opinion are perfect for gamers, small bonus I used banip to block bad servers, I was only in good lobbies with a very good ping


Don't understand whats the deal on spamming this thread with qosify. Anyone registered in this forum acknowledged the existence of qosify and im sure they are smart enough to find the thread with your guys suggestions.

hello, has anyone tried the script in dsa??? I connect to the ps4 via cable to port 1 and my ap to port 4. In swconfig I am clear that my lan network is eth0.1 and my wan network is eth1.1074. Can someone help??