I have tried qosify and def my chose is the script from this thread. Im not saying that qosify is bad, this script just fits better my needs.
Please, let us know once its ready, so we could act like a beta testers for this project.
Not really, but https://docs.google.com/a/chromium.org/viewer?a=v&pid=sites&srcid=Y2hyb21pdW0ub3JnfGRldnxneDoxMzcyOWI1N2I4YzI3NzE2 is a somewhat oldish illustration of how adding bandwidth or latency affect page load times. While the actual thresholds for rate ight have changed a bit, the conclusion is that above a certain value adding more rate only reduces page load time mildly, while RTT decrease has a more or less linear effect on page load time. So the quintessence is that you can have "enough" bandwidth (meaning where adding more bandwidth only mildly speeds up tasks) but you can't have too little latency... (this is partly a luxury problem, because in 2010 and still today there a plenty of users that are far away from that ~10Mbps rate that which the rate effect saturates)...
This is funky from that page:
I don't altogether understand it though.
In any case, all of this for me certainly goes to show that the obsession over speed tests and 1Gbit/s as compared to 10-200MBit/s seems misplaced compared to ensuring low latency. It matters if a Zoom meeting is interrupted or website loads slowly. If a Windows update takes a bit longer I don't care.
1 Like
Well, the core of the issue is that some applications are limited not by how much data can be transported by one haul, but by how many hauls you can achieve in a given time. Typically those applications tend having to look at the just received haul to figure out what to haul in next. Think a multi-part website that contains linked in assets, which then require a diversion to the next DNS server to get the IP address before the actual assets can be requested.
Yes and no, when switching from 16 to 50 Mbps I really felt a difference (if only because now multiple concurrent application could get ~10 Mbps each), while switching from 50 to 100 did not pop-out (I can measure an improvement, but it feels more like its a wash).
On the other hand if you do loads of bulk data transfers, you are probably seeing this differently, I just can not imagine that that many users fall into the throughput-avove-latency camp, unless their throughput is atrociously low to begin with (in which case they have my empathy).
Well this partly boils down to competent AQM... with a plain FIFO on the bottleneck even a single capacity seeking flow (as in a software update) can ruin the latency/interactivity for all concurrent flows, it is flow queueing or even per-IP-isolation in fq_codel and/or cake that make live quite bearable even when running a link close to saturation. In the past the only well-known solution was to increase the bandwidth (with a more expensive plan) as that tends to reduce the time a link is saturated and the adverse effects are experienced (a solution the starts to fail once the download users start to make use of the higher capacity by downloading more).
Let me repeat, fq_codel is not really obsolete. It might not be the qdisc of your choice, sure, but that does not make it obsolete.
That can or can not be a desirable policy. Personally on my main work box, I would simply limit either the total torrent bandwidth or the numer of torrent flows (or both), at which point e.g. normal flow-fair queuing like in fq_codel or optional in cake will mostly do the right thing (I would still also use cake's internal-IP fairness mode).
The issue with the bulk class is, that only gets very little guaranteed bandwidth, so if you are waiting for a torrent download it can get hard to predict the ETA.... if however torrents are not waited on but run as a true scavenger service that only needs to finish eventually, then bulk is a good place to put them.
Not knowing a posters use cases and typical traffic volume that seems a bold statement to make.... I try to stay out of telling folks how much bandwidth I assume theyreally need, as this seems to be more of a subjective 'policy' issue than simething easily open to objective determination. It is however a 'good' way of alienating people, unfortunately.
1 Like
Why do you refer to this methods as obsolete? They are still under support and under broad use. Qosify does not suit all my use cases, might happen to others. And mate, I'm shaping 1000/50 Gbps bandwidth on a RPi4 and marking with DCSP and using Cake without veth or Qosify. CoDel is in my WiFi APs and they allow me to play online with only 0.1-0.2 ms jitter, no drops or skipped frames.
Honestly, I don't see the benefit of pushing everyone so strongly to Qosify if it's not needed or required.
2 Likes
Can eBPF work with ifb's?
We have been through this before, and while I respect your right to your own opinion, I do nor believe this assessment to be generally correct. Cake is not a strict superset of fq_codel:
a) fq_codel can use DCTCP style ECN (whether that is a good thing is a different question)
b) fq_codel can be run-time configured to use more than 1024 hash buckets (that is somewhat ameliorated by cake's 8-way associative hash)
c) cake is considerably more CPU intensive than fq_codel
d) fq_codel allows independent manipulation of target and interval
e) fq_codel has, IIRC, the more efficient overload dropper.
So in short, claiming fq_codel is obsolete because cake is better is not true, it very much depends how a user evaluates the different options in the non-overlapping set between the two. Again I am happy to accept that for you cake is unconditionally better (and I have no issues with you making that claim. However claiming cake IS unconditionally better than fq_codel seems to be to strong a statement.
Yes, but that is the situation when it actually matters... let's not speculate how often that situation arises for other users... if they are well informed about the (potential) consequence of putting flows into the bulk class all is fine and dandy, but IMHO that is a decision with side-effects the users should know about.
I do not fully disagree, yet I consider it quite rude to tell others about what they really need based on just of my hunches.
That is again not unconditionally true. The extended Berkeley Packet Filter is an in-kernel virtual machine that allows a number of interesting applications and can be used as a back-end for implementing traffic rules, but unlike iptables/nftables it does not offer a dedicated configuration language for firewall/packet filtering use-cases. IMHO the future might be nftables/iptables front-ends that might compile their rules into eBPF code to run in the kernel. But for end-users both iptables/nftables offer a much richer better documented environment to create traffic rules/filters/matches in.
Or potentially implementing the "internet-ingress" shaping on a LAN interface, in which case LAN<->WAN traffic is easily amendable for ip/nf-tables.
I appreciate you trying to help. It might make sense, however, first to try to understand what specific use-case some one aims at and only then decide what tool to use? For example, qosify can not create marking rules based on internal IP-address-port-protocol tuples; now such a capability is not always required, but when it is qosify does (currently) not cut it.
2 Likes
You’re sounding way too fanatical and ignoring the point of this thread (alternate qdiscs for a specific scenario of gaming). But then again, maybe zealotry is your thing.
1 Like
You did share it, thanks. One guy said it wasn’t right for him. So let it go, please.
3 Likes
I tested this script for a few weeks and thanks again to dlakelan for the efforts made 
but unfortunately it was never too effective for me, the script having worked best for games and the one I couldn't tell you why ...
if dlakelan would be able to transcribe it to nftables that would be a great idea
qosify I find it simpler and works much better it's only my humble opinion
1 Like
Not quite right. As with every new shiny technology and toy it has scenarios where it excels, others where it lacks and others where is not suitable, paraphrasing you, "you just have to use Google search".
Not quite right again. Yes, I'm using iptables, but bear with me, I'm using a combo of it with DSCP (--set-dscp-class) marking per flow, thanks to conntrack and tc-cake to ensure I can recover the marking at ingress too. Once more you only need to use Google, search this forums and search for Kevin's posts. And, the icing on the cake, nDPI (thanks to netify) to automatically create ipset groups per app, protocol and/or type of traffic to automatically classify most of my network traffic (you know, the usual suspects, games, video streaming, Zoom, Teams, GeForce Now, Minecraft, VoIP, VoWiFi, etcetera).
Of course not, I do so too! But, may I suggest to you that in place to tell someone that he is wrong and he stills don't understand how QoS or CAKE works and then just proceed to push down his throat Qosify, please, pretty please, provide proper and sound advise, on why in his case it might be better. Because, I insist, is not better in all the cases, e. g., I cannot replicate my setup with it, hence not better for everyone (or me).
BTW, to put this in context, typical family here, typical use cases, and once more, we game, and the only Windows computers in this house are a laptop that I bought for $85 to run my tele calibration software and my company's computer which I use remotely via Parsec. And the four of us play video games, you see? Too many suppositions... too many...
*) To note that implementing any application-layer policies with eBPF would be inefficient due to the performance trade-off. You can apply your rules once per flow with iptables/nftables (whether it has 1 packet or 10,000 packets) and mark it in the Linux conntrack tables. You don't need to check every packet. If you use eBPF, you must inspect every packet. You'd need to use CPU cycles, bad business for gaming router, right?
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?)
3 Likes
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.
7 Likes
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.
2 Likes
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
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
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
2 Likes