I have an ISP that offers 100mbit/s during AM hours and 70mbit during PM hours. Naturally, I cant have static SQM setup.
What are my options to automatically adjust it? I guess I could in theory use cron to run a script, sure, but I dont know what commands can help me configure specific SQM parameters.
I think the bash script from the first post in the following thread:
https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848/3249
should work well.
just set the minimal rate to say 50 Mbps, the base rate to 63 Mbps and the max rate to 90 Mbps for starters and start measuring tweaking from there...
Now, this is not exactly what you asked for, but am alternative solution to your challenge that should effectively result in similar performance without you having to configure fixed rate change times (which require that your router has a reasonably correct clock).
1 Like
What does this sentence mean? The clock as in system resolution clock? CPU clock? The datetime clock (which is NTP synced)?
That solution appears to be for dynamic bandwidth ISP, mostly mobile. Granted, I live i n3rd world shithole and my promised bandwidth always labeled by cheeky ISP as "up to X" to absolve them of all sin, but still, going below advertised rate is fairly uncommon within first mile up to the ISP edge-router/server so I'm not really concerned here much. I think for my usecase that script will do more harm then good.
Thanks though, since I now can use that thread to ask specific question!
Configure your am settings and backup your sqm config file.
Configure your on settings and make another backup.
Compare the two backups to guide you what needs to be changed using from scripts.
Also in Luci before you save / apply changes you can see what the changes are going to be and use that as a guide
It appears that if you want to set new bandwidth for DL and UL you have to use different interfaces since the command it just:
tc qdisc change dev $INTERFACE root cake $BANDWIDTH_DOWN
It seems to be the upload interface usually always WAN, but how do I find out what interface should I specify for DL?
I know I can use:
uci set sqm.eth1.download='48100'
uci set sqm.eth1.upload='48100
However this requires applying whole configuration, which is undesirable. tc qdisc change seems to be changing values on the fly so I'd prefer using that
Wall clock, many routes come up with arbitrary time, NTP synchronisation solves that potential...
Not an option unless you use something like autorate, as unless you change uci set sqm.eth1.download/upload on hotplug sqm will just read in the values from /etc/config/sqm.
What does this mean?
It means what I wrote... So the way SQM works is that if SQM's interface goes away (as happens often for PPPoE or sometimes for somewhat flaky ethernet) the hotplug.d code we notice and sqm will try to stop the instances running on the "lost" interface and more importantly will also restart SQM once the interface becomes available again. In such situations however it will pick the rates as defined /etc/config/sqm so unless you also update those rates from your cron job/script you risk running sqm with the wrong rate either sacrificing potential throughput or risking latency increases.
I see. That does make sense.
So what would be "correct" way to apply changes then?
uci set sqm.eth1.download='48100'
uci set sqm.eth1.upload='48100
uci commit sqm
Will write changes but wont apply this, with the same success I can copy over the file.
Sure, but honestly committing and applying the change will cause a few dozen milliseconds without cake being in tight control, twice a day, so I probably would not bother much about the theoretical inferiority of this compared to using tc qdisc change. For autorate with its high frequency of changes that is quite different, but for twice a day I would try to keep the solution as simple as possible.
I still dont know how to apply them, though.
As I said, commit will write changes, wont apply them. Should I then just mirror the changes via tc qdisc change?
I think what you need to do actually is:
uci set sqm.eth1.download='48100'
uci set sqm.eth1.upload='48100
uci commit sqm
/etc/init.d/sqm stop
/etc/init.d/sqm start
That is also a way of keeping existing shaper and UCI file in sync and having seamless shaper-rate changes implemented... in the end you likely will be wrapping this into a script and call it from cron so you can go arbitrarily complex if you want 
For hotplug the only thing that matters is that the UCI file contains the rates you currently want to have re-applied if there should be a relevant hotplug event.
1 Like
This makes sense.
Extra question: do you know how to add some port prioritization with defaul cake/piece-of-cake setup?
Piece_of_cake will not d prioritization at the qdisc, you would need layer_cake.qos for that AND you need rules to re-mark with an appropriate DSCP (one that cake maps into the desired priority tin) based on the port number. For egress traffic that can actually be achieved from within the firewall GUI, but for ingress traffic that is far from trivial. The easiest way way if you want/need cake and port prioritization is to look at qosify. Alterative options are e.g. using tc filters ot do the DSCP marking before cake gets hold of the packets (the problem with the iptables/nftables bases firewall is that it only gets hold of the packets after the ingress qdiscs already did their thing).
However often cakes per-internal-IP-fairness mode can replace a lot of old-school prioritization rules (because if say your gaming traffic is not affected by your SO's video streaming, maybe no additional priority is required).
Actually, just read: Openwrt sqm prioritize a tcp port - #15 by moeller0
So, if I know exact bandwidth limitations for the app that uses specific ports and I want to prioritize and TCP/UDP packets sent to that specific port form my machine - I should use cake 's precedence schemes? Does this involves modifying existing piece-of-cake script?
I just went for something simplest. Wanna try and stay as light on CPU as possible.
In theory maybe, but in practice cake does not seem to actually implement strict precedence, so this is not likely to help, but you can try it out yourself and see, I only looked at the code...
I think compared the the actual traffic shaping doing prioritization on top is relatively cheap CPU-wise. And qosify's eBPF approach seems like a very efficient way, so if you need prioritization then qosify might be your ticket.
Can I get a little bit more info on this
I think this thread:
https://forum.openwrt.org/t/qosify-new-package-for-dscp-marking-cake/111789
covers most relevant information about qosify.