How did you measure? I ask as I initially did not look at the idle value, but it turns out that %idle going to zero is the best indicator for an overtaxed CPU, and most often it is sort interupts (sirq) that increase accordingly if idle decreases, unfortunately shaping is quite costly...
"They" did not remove this, it was never on sqm's todo list. The goal was/is to make an AQM/QoS system where the detailed configuration by creating (heuristic) rules is not necessary for most users. And telling people to net do latency-sensitive and bandwidth-hungry applications concurrently on the same computer seems like a simple work-around for the latency issues you encounter.
BUT, as I stated before sqm will still honor DSCPs (you need to look into the code to figure out which DSCPs are mapped to which priority tier in the different diffserv-modes) so all you need to do is make sure the packets are appropriately marked.
Well, that plus the fact that most bandwidth hungry applications now-a-days use multiple flows, so the flow-fairness that sqm applies within each IP-addresses traffic will easily starve the (typically low-flow-count) latency-sensitive application. Now one could solve this by configuring a secondery IP-address on the PC and have the latency sensitive applications use a different IP than the bandwidth-hungry ones. But at least to me the "solution" would really be not game while downloading (or rather game on a different machine, the OP seems to have no shortage of devices )
Doesn't this device suffer from lag spikes when using lede?
There are multiple topics like this one: [SOLVED] Router (Netgear R7800) introduced latency spikes >100ms
Blame router chipset companies for not open sourcing their drivers!
Edit: This was already mentioned and I am going to drink a cup of coffee to wake up
Yes the topic about R7800 and latency spikes figured out a lot of what was wrong, and I believe the patches are already in master branch. One of the major things that helped there was to make the kernel voluntarily preemptible, and set a higher HZ value (250 or 1000) as mentioned here: Possible cause of R7800 latency issues
In addition there are some switch specific patches involved for the full fix.
@Help_ME the 18.06 snapshots have the Luci GUI included, so you can try those if you want
If I'm not downloading anything, my ping never goes up, it always stays at 70, it never gives me disconnections, thanks to ip-isolation (I have Tenda Nova WM6 in AP/Bridge mode connected to a LAN port on the router and disable the WIFI on the router R7800 to make ip-isolation work in the cellphones) the problem is when I'm downloading something on the same console or PC that I am playing.
I have 25 mb of download and 5 upload. (modem Motorola MB7220)
If I know, but I wanted to try SQM Cake because many recommended it, but it is not better than Adaptive QoS with Script of FreshJR or Tomato QoS, because it needs category and prioritization.
I'm trying luci-app-qos (needs to be more customizable) without any other installed package (in this same way i test luci-app-sqm) and I configure with something similar to this The best QoS for Gaming! Tomato, luci-app-qos work much better that luci-app-sqm when I download something on the same console or PC that I'm playing, sometimes give me lag but I could play, in luci-app-sqm is impossible.
I repeat again, “We advance 2 steps forward and 5 steps backwards.”
That is the bottom line for all of this. You have some reasonably unique requirements that do need categorization and prioritization. Period. You're asking for your gaming traffic (categorization) to take precedence (prioritization) over your download traffic. No general-purpose algorithm is going to solve that.
Yes, you can find all kinds of "magic" tunings of various algorithms on the web that "work for me", but unless you're willing to tune those algorithms to your specific categories and priorities, you probably won't get the results you want.
The characteristics of your line and your ISP are likely different than those of the author. With a 25 Mbps line, you're crawling compared to the near-gigabit speeds that are available today over DOCSIS 3.1, which has the added complexity of PIE queue management in the head end. 70 ms ping time? I get concerned when mine, on a 300 Mbps line, goes over 15 ms. What works for me isn't going to work for you, even if we had the same goals.
The various scripts behind the UI of the luci-app-* do a good job for many people, without needing hours of tuning for every line, and re-tuning "when it rains" and the characteristics of the line change. They are a huge step forward for most users, including twitch gamers who wisely would never think of doing anything on their gaming machine while playing in any important situation.
Much as I choose to use my own firewall rules, you can choose your own categorization and prioritization rules. The scripts can be adopted to your needs.
Again, please do not take me wrong, sqm is working as intended on your link, and adaptive QoS is working as intended, you like the configurability of the latter better and would prefer detailed configuration by rule compared to simply not running applications with noticeable different latency requirements concurrently on the same host. By all means stick to adaptive QoS or try gargoyle's qos system which also seems to be well liked by gamers.
SQM does not aim to be the one true AQM, but rather it aims to be the mostly automatic AQM for people who dislike having to create and maintain more detailed rules as part of their AQM. So I venture a guess the kind of detailed configurability is not going to come to sqm. That said the current version of sqm basically has most of the "logic" sitting in small bash scripts which you could simply edit to add all the rules your heart desires
But really why not stick to the AQM solution that works well for your use-cases?
For my SQM cake with ip-isolation was thought for company or business, not for Gaming and in this time who does not play games?
My RT-AC86U with Asuswrt-Merlin with the Script FreshJR Adaptive QoS + Tenda Nova MW6 in AP/Bridge Mode (RT-AC86U WiFi disable both band) I'm fine, I never have lag, disconnections, etc. (in the tests already mentioned)
I hope that some SQM cake developer looks at this post or a friend of him and he mentions these options category and prioritization to add them in the future or I will keep in my warehouse the router R7800.
You defend something that is not complete, instead of looking more to the future and adding more options to make it complete and better.
That is not entirely true: SQM Is simply geared towards a different use case. It works wonders in my environment and I would not go back to Asus Merlin myself. I really prefer not having to worry about low level classification, but the devices on my network are much more specialized than yours and each has its own IP. I got a gamer here and there is in no impact from other clients downloading and streaming.
One just needs to pick a right tool for the job: you cannot use the same screw driver on all kinds of screws.
You can set the dcsp flags on the hosts machines.
Under Linux with iptables, obviously.
Under windows you can use the build QoS management for it. You have to create a group policy for it.
This will only work for upload/outgoing packets.
Also set cake to one of the diffservs presets.
If you also want to set dscp flags for incoming/ingress packets you have to do it on the router. I made a thread about it here in the forums.
Well for ingress using an ifb you might need to use "raw" tc to re-map the dscps. Otherwise you will need to either use the imq-route that @shm0 developed and documented or @dlakelan's method of routing ingress via a veth pair (these both methods allow to use iptables instead of tc).
BTW, the currently in process of being upstreamed cake builds will also allow to directly mark packets to go intro specific shaper tins, which will make things slightly easier (but then havin the desired dscps has the advantage that they can also be used on the internal network for say, wifi WMM)
I dropped the imq path.
The approach now uses ifb and tc filters to set the dscp flags.
But that also doesnt work out of the box with openwrt.
Because some tc extensions (pedit, csum) are not available in the standard openwrt configuration.
Mmh, if your approach can be expressed as a script inside the sqm-scripts framework/machinery, I believe we could try to get it integrated into the sqm package, assuming you want to share your work with others
What kind of script do you think of?
If my approach is something useful,
feel free to use it and make it better
It also seems like cake is checking for every possible dscp flag (which are 15)?
But in the end they all come to the “IP Precedence” (which has only 7 flags/classes)
So instead of checking for 15 dscp flags, only consider the first 3 bits (or more like the first 2?)
of the dsfield and get the IP Precedence.
Use those values to put packets in the appropriate cake tin.
This would be a somewhat more generalized solution and is maybe also faster?
actually i think this will not work x)
I believe you at one point used conntrack to copy the easier for the user to configure dscp marking from egress to ingress packets of the same connection; I believe that is something quite a number of users would like. Especially since DSCPs on ingress are often a mess and occasionally need to be re-mapped tp make sense in the ligh of say wifi wmm priorities.
There is 6 bits worth of dscp space, but only a subset pf code points are widely enough in use to have any meaning. cake tries to account for those few common dscps as these are the only ones one can realistically expect to come from the upstream (also some like EF have traditional use cases, like ssh and VoIP).
How? It is true that the most priority tins that cake currently supports is 8 with the recommendation to only use 3 or 4.
There are a number of cute schemes, like splitting the 6 bits into 2 groups of 3, one for the endpoint to signal intent (that stays for the full trip) and on group for the current packet handler to put their own priority markings (VLANs only offer 3 priority bits as does wifi's WMM). That sounds great in theory, but in practice it fails as everybody needs to participate and that is hard to ascertain.
Well, as I hope I explained, cake does not try to design a great new green-field dscp to priority mapping scheme, but rather tries to accomodate those mappings that actually seem to be used in the wild.
Yes i think this is the best way. Since all connections will originate from the lan side anyway.
And as you said, most ISPs are overwriting the dscp flags anyways.
first 3 bits = 111 = 7
first 3 bits = 110 = 6
bin: 101000, 101110
first 3 bits: 101 = 5
bin: 100000, 100010, 100100, 100110
first 3 bits: 100 = 4
Until here it works quite well...
bin: 11000, 11010, 11100
Here we need some padding i guess (to fill up to 6bit)
So we get
011000, 011010, 011100
First 3 bits: 011 discard the first 0 = 3
bin 10000, 10010, 10100, 10110
pad to 6bit: 010000, 010100, 010110
first 3 bits: 010 = 10 = 2
bin: 1000, 1010, 1100, 1110
pad to 6 bit: 001000, 001010, 001100, 001110
first 3 bits: 001 = 1 = 1
so i think only the first 3 bits are of interest.
No need to map all dscp classes to values as cake does.
Instead use the 3 bit IP Precedence field.
IIRC EF was designed to still have the correct class selector/CS value so the idea was even people only looking at the first three bits will more or less do the right thing with EF.
So you basically propose to only use CS as markings, certainly a defensible position, and as you can deduce from the names the people who made the AFNn code points took cake that N matches the CSN with the same starting bits. But the whole point I want to make is there are multiple ways to skin this cat and cake's designer decided to not push their own private pet dscp scheme but simply accommodate to the existing reality
And honestly 6 bits is not that much that the lookup table uses too much space and is flexible enough to support the next killer DSCP marking scemes that will only use primes or somesuch...
Yes they made the dscp flag system backwards compatible so it works with the old ip precedence system.
Also there will one downside when using ip precedence for the in mapping,
its not possible to map sub classes (AF*) into a different tin.
On the other side when using ip precedence mapping for example 7,6,5,4 for the voice tin
it will catch everything ef, va ,cs7, cs6, cs5, cs4, af41-43.
Without the hassle to map every (sub) dscp class.