Rate limiting is implemented in the snapshot version of qosmate, latest release doesn't include it yet. You can install the snapshot version by issuing the command
service qosmate update -v snapshot
1 Like
In general much better than rate limiting is to force traffic to/from a group of machines into the appropriate category. HFSC Will automatically unfairly share the bandwidth between the different tiers. Unlike cake it actively tries to be unfair in order to accomplish some other goals (you could say it sort of tries to maximize some kind of utility)
1 Like
thanks much
What if I want to change qosmate speed input for download and upload on ssh (putty) without accessing interface. What command should I use?
Could someone help me find the ideal Manual Overhead (bytes)? My connection is GPON fiber that requires PPPoE connection. So far I tried 44 but i feel like there is a better one. Any help is more than appreciated!
GPON FTTH PPPOE works pretty well with overhead 44 and MPU 84, good to be on higher side
Do tests and keep eye on your bufferbloat, hopefully they're good enough values for you
Overhead 44 and MPU 84 works the best thank you. In addition i also disabled ACK Filter (Egress) because it caused some issues with the games i play. Is there something i can do regrading the Ingress side, firewall is already optimized.
Don't disable it, leave it auto even if your bandwidth is symmetrical, moreover i didn't understand your comment regarding firewall being optimized, we've fw4 in latest releases and what you've done to it?
On ingress side, make sure nat is ON for both ingress and egress and you'll be fine, as you're running your device in pppoe and your openwrt router being nat accountable. Keep everything else in qosmate as default and you'll be on super tight latency parameters 
1 Like
Regarding the firewall it looks like this, nothing else changed. What i noticed that whenever i set the mpu to 84 i get this weird stutters, while on default Ethernet value its not present. So my question is what is the default mpu value when we set link type to Ethernet.
IIRC, there is no explicit default mpu, so that would be zero.
Does it tell you if you use the command tc -s qdisc?
Depending on the qdisc in question it is worth also trying tc -d qdisc
1 Like
Default mpu seems to be already 84, but i updated this morning to the latest version 1.8.0
bandwidth 200Mbit diffserv4 dual-dsthost nat wash ingress no-ack-filter split-gso rtt 100ms noatm overhead 40 mpu 84
@Hudra @antonk
Previously i was beating bush and was unable to make sense for qosmate going disabled after reboot, i did notice it very keenly and concluded and showing in below link, please be patient with this video and I'm expecting your response, I'm observing same clash for adblock-fast and adblock-lean with qosmate , though backend says it's all good, please see this video, thank you in advance
I'll summarize what I'm seeing in your video:
- You restart your router
- After boot, Luci -> Startup shows qosmate service as enabled
- You wait for adblock-lean to wake up (it's sleeping for 120 seconds after boot)
- After adblock-lean wakes up and completes lists processing, Luci -> Startup shows qosmate service as disabled
- You restart the qosmate service and then Luci -> Startup reports it as enabled
- qosmate's own Luci app shows service as enabled all the time
Is this correct?
If so then I'm not aware of any mechanism by which adblock-lean could interact with qosmate. The only thing adblock-lean does which is system-wide is restarting the dnsmasq service (with the compiled blocklist). So to me it looks like restarting the dnsmasq service somehow may be confusing the rpc. Please try issuing the command
service dnsmasq restart
and see whether this has a similar effect.
Also what's the output of
ubus call system board
1 Like
Yes service qosmate status showed everything is alright, this is also shown in video
I did as you said and get following results in uci, but qosmate was unaffected in this case, weird
root@OpenWrt:~# service dnsmasq restart
udhcpc: started, v1.36.1
udhcpc: broadcasting discover
udhcpc: no lease, failing
root@OpenWrt:~# ubus call system board
{
"kernel": "6.6.110",
"hostname": "OpenWrt",
"system": "ARMv8 Processor rev 4",
"model": "GL.iNet GL-MT6000",
"board_name": "glinet,gl-mt6000",
"rootfs_type": "squashfs",
"release": {
"distribution": "OpenWrt",
"version": "24.10.4",
"revision": "r28959-29397011cc",
"target": "mediatek/filogic",
"description": "OpenWrt 24.10.4 r28959-29397011cc",
"builddate": "1760891865"
}
}
root@OpenWrt:~#
In video, i did reboot, and qosmate went disabled after 99 adblock-lean is up, qosmate also listed 99, is it conflicting?
I tried restarting adblock-lean but before checked lean status and I'm totally unaware what it showed
root@OpenWrt:~# service adblock-lean status
adblock-lean (PID: 12966) is performing action 'Delaying adblock-lean by: 42 minutes (thundering herd prevention)'.
root@OpenWrt:~#
root@OpenWrt:~# service adblock-lean restart
Restarting adblock-lean.
Stopping adblock-lean.
Error: Failed to kill running adblock-lean processes.
root@OpenWrt:~#
adblock-lean started the automatic blocklist update routine after a cron job triggered it. It was sleeping a random number of minutes before update (in this case 42 minutes)
You found a bug in adblock-lean: while it's waiting on the sleep process, it does not respond to the normal kill signal. This in itself is not a bug. However the stop command tries to stop other running adblock-lean process by sending the normal kill signal and this is not working in this case. We will change the code to send the kill -9 signal when stop or restart command is issued. Anyway, this is unrelated to qosmate.
1 Like
Can you please try to reproduce qosmate disabling at your end? As like in shared video?
Indeed, I can reproduce the issue. Will need some time to investigate. In the meantime I'm not seeing evidence that there is anything functionally wrong with either adblock-lean or qosmate - both applications appear to be working fine, regardless of what is reported in the "Startup" luci page.
Edit: the issue was introduced with this PR by yours truly. Specifically, this line:
is what's causing the issue. Before the PR, the line was
/etc/init.d/qosmate enable
How this change is causing this particular strange behavior is unclear to me but we can mitigate the issue by changing the line to something like
enabled || /etc/init.d/qosmate enable || return 1
The reason I changed it in the first place was that the call /etc/init.d/qosmate enable creates a new subshell and runs 400+ lines of shell code in it - this seemed unnecessary to do every time the service starts. enable runs 10 lines of code and doesn't involve a subshell.
2 Likes
thank you nailing down this issue, yes everything works but when i discovered initially and saw it disabled, it gave me panic attack, lol, now i'm sure it works OK in background as we discussed. AS now you've cornered the problem, hope to get snapshot release with the fix. Thank You SIR 
2 Likes