That can work, so long as you don't give ipv4 only or ipv6 only options... like for example if you want to filter based on source or dest addresses, or ipsets etc. Also I discovered that it's probably a good thing to put $@ in quotes like "$@" because otherwise you can get problems with comments involving quoted strings with spaces -m comment --comment "here is my comment" for example
Has the "shaper_burst" option been removed from /usr/lib/sqm/defaults.sh?
In current sqm-scripts master it has been superceded by:
# HTB without a sufficiently large burst/cburst value is a bit CPU hungry
# so allow to specify the permitted burst in the time domain (microseconds)
# so the user has a feeling for the associated worst case latency cost
# set to zero to use htb default butst of one MTU
[ -z "$SHAPER_BURST_DUR_US" ] && SHAPER_BURST_DUR_US=1000
[ -z "$ISHAPER_BURST_DUR_US" ] && ISHAPER_BURST_DUR_US=$SHAPER_BURST_DUR_US
[ -z "$ESHAPER_BURST_DUR_US" ] && ESHAPER_BURST_DUR_US=$SHAPER_BURST_DUR_US
# use the same logic for the calculation of htb's quantum
# quantum controlls how many bytes htb tries to deque from the current tier
# before switching tiers.
[ -z "$SHAPER_QUANTUM_DUR_US" ] && SHAPER_QUANTUM_DUR_US=$SHAPER_BURST_DUR_US
[ -z "$ISHAPER_QUANTUM_DUR_US" ] && ISHAPER_QUANTUM_DUR_US=$SHAPER_QUANTUM_DUR_US
[ -z "$ESHAPER_QUANTUM_DUR_US" ] && ESHAPER_QUANTUM_DUR_US=$SHAPER_QUANTUM_DUR_US
The idea is to configure the burst buffer by the time required to empty it, as that gives a better estimate about the worst-case latency increase caused by this buffer. Also the old implementation had a few rough edges, that should be better with the newer code (which has not seen major testing yet, as it is only in the OpenWrt master snapshots and not in the 18.X.X releases).
Hope this helps.
That explains why I can't find it in the stable branch. my next question is why is the default SHAPER_BURST_DUR_US=1000usecs if the kernel is 10ms? Shouldn't it be for example @ 10mbit > 10e6/1/100/8=12500 or 10,000,000bits(1/100hz)/8? or 10,000,000*.010/8?
Because, the motto for sqm-scripts is "do the right thing by default, at least to do no harm", and larger burst buffers will increase latency under load and jitter. So ideally we would like to keep this at a single MTU-sized packet, but if we do, shaping becomes prohibitively expensive CPU-wise (for HTB and TBF the consequence of this are a severe decrease in effective bandwidth).
The idea about exposing these values in defaults.sh, is that users like yourself can actually change this/ experiment with this.
Makes sense. I only ask because the recommended formula is r2q for htb, and a friend was engaging me with a notice of "htb quantum rate is lower that 1749 bytes" I believe it. I'll have to get him to send me a log or screenshot to confirm. That being said, it's lower than at least 1 mtu at 1250b @ 10mbit is why I'm chasing this rabbit lol.
Below 1ghz I do believe it becomes a factor. As router are becoming more powerful it may become less of an issue.
It is all about the balance between router CPU speed and internet access bandwidth; even >>1GHz multi-core routers can get in trouble if hooked up to a say 1000/500 Mbps link (assuming the shaper is set to say 950/450). With some ISPs already offering 10Gbps links (for acceptable prices) the underlaying issue is going to stay with us.
I believe that most instructions for HTB are really really ancient and do not faithfully reflect how the linux kernel or the HTB code operates in detail anymore.
sqm-scripts used a single MTU as lower bound for a loong time, it was just not easily configurable...
This is good information, as these errors could be misleading
Most of the Linux documentation is outdated or written as if one has coded the the program themselves, rather than explaining it to someone who has never used it.
.
Oh, I do not claim that there are no errors in sqm-scripts, and I am happy to fix them. So if you have any error messages, please post them here or better as a new issue on https://github.com/tohojo/sqm-scripts.
I meant no offense to sqm, as most of it is revelant, although older views should be categorized as such.
I still use fq_codel over cake for gaming, as it just “feels” right. In which case separating docs for each disc would be helpful.
are you about to get that installed? how much does it cost, where are you and what level of svc?
Hi,
I would like to try the script that @dlakelan pasted here, but I am not as technically literate when it comes to networking as others on this forum.
I have similar internet usage as @mindwolf, and was struggling with some rather basic stuff. If any of you here can help me, or point me to the appropriate resources, I'd really appreciate it. Here are my questions:
-
Where do I put the first script that @dlakelan submitted? Does it go inside its own .sh file in /bin/ ? And, how do I run it? Does it get automatically run on boot?
-
I am on version 18.06.04, and I am running OpenWRT on an Archer C7 V2. Is there anything in this code that I might have to alter to make it compatible with my current version?
-
Are there any other packages I would have to install? And, if so, would I just use
opkg installto install them? -
A lot of the terms used after the post containing @dlakelan 's script confuse me. Can anyone explain what tx rings and interrupt coalescing are? Are they supremely important to this setup?
I admit I am a little lost, since I am still relatively a beginner, but I think with some guidance I can get this to work. I have really enjoyed getting lost in this forum and it has helped me learn a lot about networking basics, so I would really appreciate your help. Thanks, and please let me know if you need any other information from me.
I would propose the following as a stepping stone to your own custom tailored QoS configuration:
Follow the instructions in
https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm
and
https://openwrt.org/docs/guide-user/network/traffic-shaping/sqm-details
to get a "boring" run-of-the-mill QoS up and running, and then start to look at understanding the more intricate details about creating a bespoke QoS configuration. IMHO this should give you a bit more ease of mind to master the required concepts and programs without suffering terrible performance under load.
Good luck!
Hi @moeller0, thanks for your quick reply. I actually am already up and running with SQM, using cake as qdisc and piece of cake as setup script. SQM has worked well for me.
I wanted to try my hand at something more complicated for a couple of reasons.
-
I wanted to tailor my network for reducing latency/jitter on my gaming console's connection, while accepting higher latency/jitter for all other devices, something that SQM does not allow a user to explicitly do (as far as I know).
-
I wanted to learn more about traffic shaping in OpenWRT in general, especially in the context of negotiating packet delay and jitter.
I know I shouldn't attempt to break what isn't broken, so please let me know if you'd strongly advise against this. I do want to be safe about it, while also learning more about creating bespoke QoS configs that suit me best. If you have any resources on using QoS (as opposed to SQM) for this, I would appreciate it.
Ah, I guess I should have asked instead of blindly assuming...
True, you can try to DSCP mark latency insensitive stuff as Background (for layer_cake.qos and simple.qos) but that also means lower priority and bandwidth... so you are right SQM does not offer that, but itt should give sparse traffic precedence over bulk transfers, which often seems enough. Now if a game sends/receives too many packets to be classified sparse, this will not help much.
I fully endorse that 
I just wanted to make sure you do not start from a no QoS baseline, as that is more suffering that I think is justified.
No, by all means go for it, the best way to learn this is getting one's feet wet.
In this forum I would recommend to summon @dlakelan, as the resident expert on custom QoS rules, IMHO he has excellent taste in what to put in heuristic rules and were to stop, much more than I do (I aim for good enough for 80-90% of users/use-cases )
Sorry to disappoint you, I have no great resources at hand.
Good luck.