What's new

FlexQoS FlexQoS 1.0 - Flexible QoS Enhancement Script for Adaptive QoS

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

You firmware version doesn’t support the new QoS categories, so your “Game Transferring” is really the former “Defaults” category, instead of the new “Learn-From-Home” category.
No I didn't downgrade from .19. Do I need to install the .19 firmware for everything to work as expected?
 
Hahaha. No worries. Does Flex end up starting tho? In other words is there nothing to worry about?
Yes, it seems to start fine later without errors. This was part of the danger when I removed the original 5 minute delay in FreshJR_QOS. Works fine most of the time, but that's why I have the lagging 5 minute check after FlexQoS starts.
 
No I didn't downgrade from .19. Do I need to install the .19 firmware for everything to work as expected?
I could be mixing up my firmware versions in my memory, but your current version doesn't appear to support Learn-From-Home, but your nvram had entries for Learn-From-Home (4,13). As long as it's working now...
 
@dave14305 I know it's easy to remove myself. However I don't like the "Game Download" rule by default. As it will put streaming video like Twitch, and such, into that category. It(Twitch, etc) should stay in the "Video and Audio streaming" category. The rule would be okay, if it's assigned by IP to each "gaming" device. Overall I am running this script again, and I really like the work you have put into this. It's very appreciated by many of us.
 
@dave14305 I know it's easy to remove myself. However I don't like the "Game Download" rule by default. As it will put streaming video like Twitch, and such, into that category. It(Twitch, etc) should stay in the "Video and Audio streaming" category. The rule would be okay, if it's assigned by IP to each "gaming" device. Overall I am running this script again, and I really like the work you have put into this. It's very appreciated by many of us.
I don't make use of the Game-related rules myself, but Twitch is in the Streaming category. How does it end up in Game Downloads? Because it comes from a device impacted by the Gaming rule? Maybe post your rules to better understand, or maybe it's a sequence issue in the rules.
 
I don't make use of the Game-related rules myself, but Twitch is in the Streaming category. How does it end up in Game Downloads? Because it comes from a device impacted by the Gaming rule? Maybe post your rules to better understand, or maybe it's a sequence issue in the rules.

I need to look into this a bit more. But from using the script at default, without any changes on my part. When I was watching a stream on twitch, it was showing the data being logged under "Game Transferring". Twitch shows it using remote port 443, with a mark of 040013. I ended up making a rule for the mark of twitch, and had it moved.

Oddly I removed the twitch rule just a few minutes ago, and it currently shows under video/audio streaming. However under connections below, it does show light blue, as game transferring. There's no question that traffic was placed in the wrong category yesterday though. As I had like 24gb of data under game transferring, and no kind of gaming data was passed yesterday. I will look into this more as well.
 
I add a custom rule as you said now youtube steam via google chrome is going to streaming but also traffic that is not streaming is going to streaming.
also, the bandwidth util doesn't work is just color bars.
I discovered if you have the QoS bandwidth setting as “Automatic Setting”, FlexQoS will display solid color bars likely due to a divide by zero error. It’s recommended to use Manual Setting and specify your bandwidth.

1601769392015.png
 
I've pushed another couple experiments to the develop branch for anyone willing to test them out:
  1. Now allow custom rate percentages as low as 1%. Was always 5% minimum in the FreshJR_QOS script.
  2. Recalculate burst and cburst when applying custom rates to ensure the HTB buckets are appropriately sized for the new rates.
  3. Always apply new quantum when modifying custom rates (old behavior would only apply quantum when it was large enough to cause the "quantum is big" messages).
  4. Set the minimum quantum at WAN MTU + 14 (this had been there before during beta but I removed it when someone reported an issue). Now the brave develop branch users can test it out.
If you want to try these experiments, run flexqos develop

If you switch but experience issues and you or your family members are panicking, return to the stable release with flexqos stable

Thanks.
It's been a while since I've broken anyone's QoS, so it's time to push the develop branch to "stable" and release v1.0.3. The only change above and beyond the develop branch is the addition of a debugging switch (-x) in case I need detailed output from your script when running.

To recap the changes:
  1. Now allow custom rate percentages as low as 1%. Was always 5% minimum in the FreshJR_QOS script.
  2. Recalculate burst and cburst when applying custom rates to ensure the HTB buckets are appropriately sized for the new rates.
  3. Always apply new quantum when modifying custom rates (old behavior would only apply quantum when it was large enough to cause the "quantum is big" messages).
  4. Set the minimum quantum at WAN MTU + 14.
  5. Extra script debugging with -x parameter: flexqos -x check > /tmp/home/root/flexqos.log 2>&1
Nothing visibly exciting, but I think it's a better tuned tc setup underneath.

Update with flexqos update and develop testers may want to switch back to stable with flexqos stable since I will be working on a WebUI-based update next which will probably break develop branch until it's done.
 
I've spent the last couple weeks preparing, studying and passing the AWS Certified Solutions Architect - Associate exam. So I've spent less time working on FlexQoS, but have still spent a lot of time researching the old documentation on Hierarchical Token Bucket (HTB) which is what really powers Adaptive QoS. I've reached a couple of conclusions:
  1. Device priority probably isn't as scary as we've believed all this time. Extremely low quantum and burst for device inner classes should prevent starvation.
  2. I'm not convinced setting device priority in the Bandwidth Monitor actually affects any change. This was related to all my questions a while back about the prio levels 2 and 3. So even if you change priority, I'm not sure it does anything, at least on my router and firmware today.
  3. fq_codel is not of great benefit under Adaptive QoS because traffic is sliced by HTB by category and then device before traffic reaches an fq_codel qdisc. At that point, it’s only shaping traffic of a particular type from a single device.
  4. ASUSWRT kernel is old (i've stated this in my last soliloquy). I think there's a kernel bug related to display of HTB token counters that was fixed a long time ago, but still after the 2.6.36 kernel on my AC68U.
  5. I really want to try CAKE.
  6. I really want a dream router that has a current Linux kernel. I've considered building my own Linux router after reading Jim Salter's article on Ars Technica, but I'm just not that dorky (close, but not quite).
  7. Or I want to be able to try OpenWRT on fast enough hardware to avoid losing bandwidth on my current ISP service with QoS enabled.
  8. Adaptive QoS is really cool in what it tries to do and is probably a great solution for most home users.
 
Last edited:
I've spent the last couple weeks preparing, studying and passing the AWS Certified Solutions Architect - Associate exam. So I've spent less time working on FlexQoS, but have still spent a lot of time researching the old documentation on Hierarchical Token Bucket (HTB) which is what really powers Adaptive QoS. I've reached a couple of conclusions:
  1. Device priority probably isn't as scary as we've believed all this time. Extremely low quantum and burst for device inner classes should prevent starvation.
  2. I'm not convinced setting device priority in the Bandwidth Monitor actually affects any change. This was related to all my questions a while back about the prio levels 2 and 3. So even if you change priority, I'm not sure it does anything, at least on my router and firmware today.
  3. ASUSWRT kernel is old (i've stated this in my last soliloquy). I think there's a kernel bug related to display of HTB token counters that was fixed a long time ago, but still after the 2.6.36 kernel on my AC68U.
  4. I really want to try CAKE.
  5. I really want a dream router that has a current Linux kernel. I've considered building my own Linux router after reading Jim Salter's article on Ars Technica, but I'm just not that dorky (close, but not quite).
  6. Or I want to be able to try OpenWRT on fast enough hardware to avoid losing bandwidth on my current ISP service with QoS enabled.
  7. Adaptive QoS is really cool in what it tries to do and is probably a great solution for most home users.
Maybe we can get you a RT-AX88U so you can mess around with cake haha.
 
I’m stashing away donations for such a purpose when the time is right. :cool:
Small donation sent your way ;) really appreciate all you do with this QoS stuff.
 
fq_codel is not of great benefit under Adaptive QoS because traffic is sliced by HTB by category and then device before traffic reaches an fq_codel qdisc. At that point, it’s only shaping traffic of a particular type from a single device.

Do you suggest another sfq or codel instead?
 
Do you suggest another sfq or codel instead?
There’s nothing wrong with fq_codel, but the fact that the flows are already isolated by device and traffic category before reaching the fq_codel qdisc suggests to me that it doesn’t really matter which qdisc you use. But it’s all theoretical, I haven’t tested it. I just don’t think the benefits are as great for Adaptive QoS where you end up with maybe 100+ different qdiscs instead of say 5 like you would have with Traditional QoS, where the flows really would be commingled.
 
There’s nothing wrong with fq_codel, but the fact that the flows are already isolated by device and traffic category before reaching the fq_codel qdisc suggests to me that it doesn’t really matter which qdisc you use. But it’s all theoretical, I haven’t tested it. I just don’t think the benefits are as great for Adaptive QoS where you end up with maybe 100+ different qdiscs instead of say 5 like you would have with Traditional QoS, where the flows really would be commingled.
I'm wondering how that applies to my AX88U.
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

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