What's new

[Fork] FlexQoS - Flexible QoS Enhancement Script for Adaptive QoS

dave14305

Part of the Furniture
Is there anyway to revert to older versions?
You would need to manually overwrite the existing files in /jffs/addons/flexqos with the files from the v1.0.0 tag on GitHub.

 

SomeWhereOverTheRainBow

Very Senior Member
Version 1.0.1 released on this fine Labor Day (before I forget how to use git).
  • NEW: Added ability to set custom iptables rule names (27 char max)
  • NEW: Added ability to force update when switching branches (@maghuro)
  • NEW: WebUI appdb search will pre-fill Class with original Class value
  • NEW: Added bandwidth utilization meters per class
  • CHANGED: Reduced the number of slow tc calls
  • CHANGED: Improved appdb and iptables rule validation during start and check functions
  • CHANGED: Flush conntrack table by default (disable with flexqos noflushct)
  • CHANGED: Simplified Tracked Connections sorting code by adopting Merlin's approach
  • CHANGED: Increased webui Apply wait time from 15-30 seconds since QoS can be slow to initialize
  • FIXED: Renamed VoIP to Work-From-Home in appdb CLI output
Update via amtm or flexqos update. If you were testing the develop branch, it may be wiser to now switch back to stable with flexqos stable.

If you have made a backup of your rules, it would be a good idea to back them up again after you fix the new iptables rule names in the WebUI, so that the names become part of the backup file.

This was a long time coming from the 1.0.0 release, so there may have been bugs I forgot to fix, or didn't notice I added. Appreciate your feedback!
So far so good, no issues yet.
Thanks Dave!
 

Yiannis

Occasional Visitor
I'm watching youtube on my laptop and on the FlexQoS page I see this traffic labeled as Others, is this normal?
 

Morris

Regular Contributor
Hi Dave,

Suggestion: Auto Scale the graphs or make them a log bar graph.
Reason: The bar is nearly invisible when small amounts of bandwidth are involved and it's particularity noticeable when there is little activity for any class.

Thank you,

Morris
 

andresmorago

Senior Member
hello @dave14305
I have 2 custom iptables rules at the very end. They are called JM_VPN_1 and JM_VPN_2.
When looking at the tracked connections, i see JM_VPN_1 but with a different name: JM


1599704423170.png

1599704476498.png
 

dave14305

Part of the Furniture
hello @dave14305
I have 2 custom iptables rules at the very end. They are called JM_VPN_1 and JM_VPN_2.
When looking at the tracked connections, i see JM_VPN_1 but with a different name: JM


View attachment 26124
View attachment 26125
Yes, I see how that can be a problem, due to another trick I was using before implementing custom rule names. For now, just remove any underscores to avoid the bad parsing, until I can fix it. I think the same would happen for all your rules with underscores, where only the first fragment is displayed.
 

dave14305

Part of the Furniture
Hi Dave,

Suggestion: Auto Scale the graphs or make them a log bar graph.
Reason: The bar is nearly invisible when small amounts of bandwidth are involved and it's particularity noticeable when there is little activity for any class.

Thank you,

Morris
How would that work? Auto-scale them against what? It’s showing the current rate as a percentage of the total upload or download bandwidth.
 

Morris

Regular Contributor
How would that work? Auto-scale them against what? It’s showing the current rate as a percentage of the total upload or download bandwidth.
One option would be to make the full bar the highest of any of the bars. That would be simple math

If you want to maintain that the full bar is always the maximum bandwidth then a log scale would allow this and still show more for small values.

Possibly I'm an odd case as my pipe is usually not full yet there are times when it fills due to downloads and that's when I need QOS.

Thank you for considering this.

Morris
 

dave14305

Part of the Furniture
Version 1.0.2
  • CHANGED: Use QoS nvram priority list to differentiate Streaming from Learn-From-Home, eliminating the FlexQoS requirement that Learn-From-Home be a lower priority than Streaming. It's still not a good idea to have Learn-From-Home above Streaming or Web Surfing because it will still hijack any category 04 or 13 traffic since the first matching rule in the tc filter list will win. This change just fixes the script logic to differentiate which is which when reading the duplicate categories.
  • CHANGED: Changed internal class marks from 0001 to ffff to avoid collisions with AppDB marks and rules
  • FIXED: Fixed a long-standing issue where the device identification bits in the Adaptive QoS mask were zeroed out, resulting in all modified traffic hitting the default leaf class 1[0-7]:256. This would negatively impact anyone who is trying to use device priorities, even though it's usually been advised against.
  • FIXED: Properly handle situation where an existing user-script does not end with a newline and we append our command to the end of file.
Update via amtm or flexqos -update
 

dave14305

Part of the Furniture
I also added a hotfix (just now) to fix handling of iptables rule names with underscores. Since it only affected the asp page, you'll have to force an update since it won't be detected by a normal update check.
 

maghuro

Very Senior Member
I also added a hotfix (just now) to fix handling of iptables rule names with underscores. Since it only affected the asp page, you'll have to force an update since it won't be detected by a normal update check.
The updater does detect changes in asp page, since we made it so it also compares the local and server asp md5 :)

 

QuikSilver

Very Senior Member
Minor item...Can we remove the "U" option. Almost uninstalled FlexQOS when updating it. Bad habit since other scripts use U to update.
 

dave14305

Part of the Furniture
Another hotfix pushing now to correct a typo in the VOIP_mark_up variable. Pretty important if you have custom rules for Work-From-Home.
 

dave14305

Part of the Furniture
I've been spending a lot of time reading about HTB and fq_codel ("the classics" in the age of CAKE). I was always happy to ignore the complexity of the device priority classes lurking beneath the more pleasant "Category" classes that we usually talk about (Net Control, Work-From-Home, Streaming, etc.). It's quite a fascinating subject, technically and one that can blow your mind especially when trying to unravel the Adaptive QoS classes, qdiscs and filters.

For anyone with more than 10 devices on their network, and who do not use any form of device priority on the Bandwidth Monitor tab of the QoS webUI, I'm interested to know the output of this command on your router:
Code:
tc class show dev br0 | grep -E "parent 10:1 .* prio "
I personally have no device priorities assigned (everything is Default) but I still see some devices assigned to classes that are at prio 3, when everything else is at prio 2.
Code:
# tc class show dev br0 | grep -E "parent 10:1 .* prio "
class htb 10:2 parent 10:1 leaf 1002: prio 2 rate 16Kbit overhead 18 ceil 322560Kbit burst 3200b cburst 403200b
class htb 10:3 parent 10:1 leaf 1003: prio 2 rate 16Kbit overhead 18 ceil 322560Kbit burst 3200b cburst 403200b
class htb 10:4 parent 10:1 leaf 1004: prio 2 rate 16Kbit overhead 18 ceil 322560Kbit burst 3200b cburst 403200b
class htb 10:5 parent 10:1 leaf 1005: prio 2 rate 16Kbit overhead 18 ceil 322560Kbit burst 3200b cburst 403200b
class htb 10:6 parent 10:1 leaf 1006: prio 2 rate 16Kbit overhead 18 ceil 322560Kbit burst 3200b cburst 403200b
class htb 10:7 parent 10:1 leaf 1007: prio 2 rate 16Kbit overhead 18 ceil 322560Kbit burst 3200b cburst 403200b
class htb 10:8 parent 10:1 leaf 1008: prio 2 rate 16Kbit overhead 18 ceil 322560Kbit burst 3200b cburst 403200b
class htb 10:9 parent 10:1 leaf 1009: prio 2 rate 16Kbit overhead 18 ceil 322560Kbit burst 3200b cburst 403200b
class htb 10:11 parent 10:1 leaf 1011: prio 3 rate 16Kbit overhead 18 ceil 322560Kbit burst 3200b cburst 403200b
class htb 10:10 parent 10:1 leaf 1010: prio 2 rate 16Kbit overhead 18 ceil 322560Kbit burst 3200b cburst 403200b
class htb 10:256 parent 10:1 leaf 1256: prio 3 rate 16Kbit overhead 18 ceil 322560Kbit burst 3200b cburst 403200b
class htb 10:13 parent 10:1 leaf 1013: prio 2 rate 16Kbit overhead 18 ceil 322560Kbit burst 3200b cburst 403200b
class htb 10:12 parent 10:1 leaf 1012: prio 3 rate 16Kbit overhead 18 ceil 322560Kbit burst 3200b cburst 403200b
class htb 10:14 parent 10:1 leaf 1014: prio 2 rate 16Kbit overhead 18 ceil 322560Kbit burst 3200b cburst 403200b
I can't tell yet if this is an issue that requires a reboot (I had tested a device priority to see what happens underneath the covers, but reverted my change). So is this a flaw in Trend's kernel module that assigns some default priority devices a lower priority class (not all same-priority devices are created equally)?

Anyhow, my latest quest is to see if there's a way to understand and make better use of the device priority structure in Adaptive QoS, which has always been poo-poo'd by FreshJR.

Also, as I've been reading and studying more, I did become quite dismayed at just how old the Linux kernel is on my AC68U. I think I measured the sch_htb.c file from circa January 2010. The more you learn about the latest advances in traffic control, the more you want to play with the latest ideas (e.g. CAKE). OpenWRT is where it's at for CAKE, but I don't really like (or maybe understand?) the best HW options. It becomes rather frustrating to keep trying to crack the Adaptive QoS code (figuratively) when so many other QoS solutions are more "open".

Anyway, I'm not going anywhere anytime soon, but it gets rather lonely trying to unravel this in a vacuum. If anyone is seriously interested in how it all works, I've also started reading the archives of the Bufferbloat mailing list. Especially you CAKE users. You can pick the brains of the authors and other smart people, if you can formulate an intelligent enough question to catch their attention. ;)
 

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top