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!

I had a feeling all this was coming :) I sensed a tunnel vision like focus on qos from asus. I would expect quite a few more changes and appdb changes as well which is why ive reverted to a more stock old school with just unidentified traffic to others and a corrected html ssl tls on prio 20/21/22 setup to keep an eye on whats going where. Id just prefer to have as few rules as possible and hoping to catch them correcting things in the appdb.
 
I'm pretty keen to try FlexQoS, I have an RT-AC88U, I had tried FreshJR some time ago with bad results but I'm 100% sure that was my fault since I didn't understand at the time what bufferbloat is and always told Adaptive QoS that my available bandwidth is the same as my speed tests rather than 80% - 95% :confused:

I'm currently using a Nighthawk XR700 pro gaming router that has DumaOS, It has great hardware specs and the firmware is built with QoS as a focus, not sure if you guys are familiar with it.

Although I'm personally not having many issues with the XR700 the firmware does seem glitchy and there are people in their forum with many various issues from IPv6 compatibility, PPPoE problems, extremely slow firmware updates from the devs, and even the best case scenarios people are complaining about "shoot first die first" in their games.

I'm wondering if switching back to my AC88U and using FlexQoS would be a better way to go, curious if anyone has been in a similar situation, having 2 routers, not sure which one to stick with, ideally I'd like to sell one but the XR700 is going to have a major firmware overhaul soon (their "soon" is a very long time, compared to Merlin firmware) but maybe I should wait for now.

Any tips or pointers, pros and cons of FlexQoS would be good to know, and I have a couple of questions,
1. Does the Gaming category automatically detect all games and if not what details do I need in order to add the games I play to it, just the ports the game uses or do I need more info like the Mark (what is Mark?), Local and Remote IPs etc?
2. Do the unidentified games fall into the Other category and I can just position that next to the Gaming category for the same result without providing extra info?

cheers in advance for any help :)
 
I'm pretty keen to try FlexQoS, I have an RT-AC88U, I had tried FreshJR some time ago with bad results but I'm 100% sure that was my fault since I didn't understand at the time what bufferbloat is and always told Adaptive QoS that my available bandwidth is the same as my speed tests rather than 80% - 95% :confused:

I'm currently using a Nighthawk XR700 pro gaming router that has DumaOS, It has great hardware specs and the firmware is built with QoS as a focus, not sure if you guys are familiar with it.

Although I'm personally not having many issues with the XR700 the firmware does seem glitchy and there are people in their forum with many various issues from IPv6 compatibility, PPPoE problems, extremely slow firmware updates from the devs, and even the best case scenarios people are complaining about "shoot first die first" in their games.

I'm wondering if switching back to my AC88U and using FlexQoS would be a better way to go, curious if anyone has been in a similar situation, having 2 routers, not sure which one to stick with, ideally I'd like to sell one but the XR700 is going to have a major firmware overhaul soon (their "soon" is a very long time, compared to Merlin firmware) but maybe I should wait for now.

Any tips or pointers, pros and cons of FlexQoS would be good to know, and I have a couple of questions,
1. Does the Gaming category automatically detect all games and if not what details do I need in order to add the games I play to it, just the ports the game uses or do I need more info like the Mark (what is Mark?), Local and Remote IPs etc?
2. Do the unidentified games fall into the Other category and I can just position that next to the Gaming category for the same result without providing extra info?

cheers in advance for any help :)
Welcome to ASUS forums
First of all, may be many like me don't know much about XR700

Secondly, one must have a primary knowledge, general understanding improves you detect problems at core and troubleshoot them accordingly and appropriately

For gaming part of your question also does apply to overall working of your internet with provided bandwidth, try your AC88U with flex and decide yourself

Simple understanding from gamers pov is they have a gaming PC or console or just a mobile gamer, all games play goes from ports other than common http/s ports like 80,443
You can simply add a rule under gaming for your statically fixed ip gaming console with !(not 80, 443) ports (use CIDR for multiple gaming devices) and see how your latency goes, but first you need to set your Qos properly with little trial & error based bandwidth limits, like mine always go fine with 88% of bandwidth showing in Ookla , i determined this comparing in peak hours or relaxed slots of a whole day 24h, secondly i would personally recommend you to find correct or near by wan overhead value, determined by your connection type and sharpers etc
If everything's synced, you can take your latency tests afterwards and compare it with your tests done prior

I hope you can work on it and enjoy your hardware to the fullest , best of luck :)
 
anyone know what this means

"
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10012 is big. Consider r2q change.
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10013 is big. Consider r2q change.
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10014 is big. Consider r2q change.
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10015 is big. Consider r2q change.
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10016 is big. Consider r2q change.
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10017 is big. Consider r2q change."
 
anyone know what this means

"
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10012 is big. Consider r2q change.
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10013 is big. Consider r2q change.
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10014 is big. Consider r2q change.
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10015 is big. Consider r2q change.
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10016 is big. Consider r2q change.
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10017 is big. Consider r2q change."

While I'm not 100% on the technicals behind it, I can tell you it's normal and just simply ignore it.
 
anyone know what this means

"
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10012 is big. Consider r2q change.
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10013 is big. Consider r2q change.
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10014 is big. Consider r2q change.
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10015 is big. Consider r2q change.
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10016 is big. Consider r2q change.
Jul 6 18:11:00 RT-AX88U-2340 kernel: HTB: quantum of class 10017 is big. Consider r2q change."
It comes from here :
https://github.com/RMerl/asuswrt-me...nd/kernel/linux-4.1/net/sched/sch_htb.c#L1510

When your min bandwidth is considered large but the r2q is fixed at 10 in the qdisc, you will get this warning. It’s considered normal, but maybe there’s a way to declare a new quantum based on the new rate. It’s very low level for my understanding, but if someone wants to study it...

EDIT: it looks like Asus/Trend set the quantum to rate / 80 when creating tc classes. I could theoretically add this to my rate changes when I apply the custom min/max rates, but I don’t fully understand the unintended side effects of doing so.

EDIT2: and the quantum is capped at 200000 when we see the “is big” warnings. This only happens if quantum is not specified in the tc class change commands.

EDIT3: or maybe just safest to reassert the quantum of 1514. I like to refer back to @john9527 tQoS implementation when in doubt. :)
 
Last edited:
It comes from here :
https://github.com/RMerl/asuswrt-me...nd/kernel/linux-4.1/net/sched/sch_htb.c#L1510

When your min bandwidth is considered large but the r2q is fixed at 10 in the qdisc, you will get this warning. It’s considered normal, but maybe there’s a way to declare a new quantum based on the new rate. It’s very low level for my understanding, but if someone wants to study it...

EDIT: it looks like Asus/Trend set the quantum to rate / 80 when creating tc classes. I could theoretically add this to my rate changes when I apply the custom min/max rates, but I don’t fully understand the unintended side effects of doing so.

EDIT2: and the quantum is capped at 200000 when we see the “is big” warnings. This only happens if quantum is not specified in the tc class change commands.

EDIT3: or maybe just safest to reassert the quantum of 1514. I like to refer back to @john9527 tQoS implementation when in doubt. :)
I did fair amount of reading on this way back.. the quantum calculation is done automatically and is important to be done so.. that msg is due to the fact that it wasnt originally designed to expect setups for gigabit connections so it is very large at those speeds. it can safely be ignored.

alternatively you get the quantum is small msg when setting the limits very small or a particular category very small % of bandwidth.. can also be safely ignored
 
that msg is due to the fact that it wasnt originally designed to expect setups for gigabit connections so it is very large at those speeds. it can safely be ignored.
What do you think of the recommendations in section 7.1.5 on this page?

http://linux-ip.net/articles/Traffic-Control-HOWTO/classful-qdiscs.html
  • The quantum should be set at MTU or higher. HTB will dequeue a single packet at least per service opportunity even if quantum is too small. In such a case, it will not be able to calculate accurately the real bandwidth consumed [9].
  • Parent classes lend tokens to children in increments of quantum, so for maximum granularity and most instantaneously evenly distributed bandwidth, quantum should be as low as possible while still no less than MTU.
 
It comes from here :
https://github.com/RMerl/asuswrt-me...nd/kernel/linux-4.1/net/sched/sch_htb.c#L1510

When your min bandwidth is considered large but the r2q is fixed at 10 in the qdisc, you will get this warning. It’s considered normal, but maybe there’s a way to declare a new quantum based on the new rate. It’s very low level for my understanding, but if someone wants to study it...

EDIT: it looks like Asus/Trend set the quantum to rate / 80 when creating tc classes. I could theoretically add this to my rate changes when I apply the custom min/max rates, but I don’t fully understand the unintended side effects of doing so.

EDIT2: and the quantum is capped at 200000 when we see the “is big” warnings. This only happens if quantum is not specified in the tc class change commands.

EDIT3: or maybe just safest to reassert the quantum of 1514. I like to refer back to @john9527 tQoS implementation when in doubt. :)
Well I hope the quantum error is fixable do QoS will become more accurate as an aside I'll see if I can dig up what freshjr told me about the quantum error when I asked.

I'd be willing to test a patch for the quantum error if need be.
 
when u get the error you can usually tell what category its for.. id bet if your getting the too big error its because you have one category set really high %

somethig like 5%/5%/5%/5%/5%/5%/70% will cause it for sure if you have a fast connection as well with high qos rates set.

bringing that 70% down should or could eliminate the error
 
im no expert on it but if i recall the error is simply that it is not expecting it to be that large and is warning you.. but infact it is calculated and ok at those speeds and to ignore the error.. thats my understanding of it
quantum is specified in bytes. Asus/Trend initially sets the class rate in bits, which is why they divide by 80 to get their quantum (8 bits per byte and r2q of 10). They explicitly define quantum when setting up classes. The warnings only appear if quantum is derived and not specified in the command line when issuing a tc class change like we do when applying the custom rates. If I calculate the equivalent quantum based on the new custom rate defined in FlexQoS, I think these messages will disappear. Otherwise, we’re potentially missing out on any benefits of Asus’ original large quantum since the log messages also imply that quantum is capped at 200000 bytes when it could be much larger if you have a lot of bandwidth.

Of course, this assumes Asus/Trend know what they’re doing when it comes to QoS in the first place. And it’s against the other docs I’ve read that suggest quantum should be only slightly larger than MTU.

But my instinct is to fix the unintended consequences inflicted on Adaptive QoS when we change the class rate from how Asus set it up initially.
 
Just wanted to add that the backup and restore function for flexqos seems to work perfectly. I uninstalled without removing backup folder then reinstalled. Then went into flexqos menu and restored. Voila! Custom rules were back again. Not sure what else could be done honestly.
 
Just wanted to add that the backup and restore function for flexqos seems to work perfectly. I uninstalled without removing backup folder then reinstalled. Then went into flexqos menu and restored. Voila! Custom rules were back again. Not sure what else could be done honestly.
All contributed by @maghuro! :)
 
Just wanted to add that the backup and restore function for flexqos seems to work perfectly. I uninstalled without removing backup folder then reinstalled. Then went into flexqos menu and restored. Voila! Custom rules were back again. Not sure what else could be done honestly.
Thanks pal :)

Let me ask you something, when you reinstalled, did the installer prompt you if you wanted to restore the existing backup?

Because it is intended to :)
 
Code:
Jul  8 22:33:01 FlexQoS: /jffs/addons/flexqos/flexqos.sh (pid=10750) called with 1 args: check
Jul  8 22:33:01 FlexQoS: No TC modifications necessary
Is this the check that is done after 5 minutes from startup?
 
Getting atm this error after a fresh install of FlexQOS:
Asus 384.18 on AX-58U

Code:
Jul  8 13:12:07 FlexQoS: /jffs/addons/flexqos/flexqos.sh (pid=5478) called with 2 args: -start ppp0
Jul  8 13:12:07 wlceventd: wlceventd_proc_event(464): eth5: Deauth_ind B8:E8:56:3F:CB:D0, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jul  8 13:12:07 flexqos: [*] Killing Delayed Process (pid=3320)
Jul  8 13:12:07 flexqos: [*]  3320 DoctorXX  3536 S    sh /jffs/addons/flexqos/flexqos.sh -start ppp0
Jul  8 13:12:08 spdMerlin: Mounting spdMerlin WebUI page as user3.asp
Jul  8 13:12:08 FlexQoS: Applying iptables static rules
Jul  8 13:12:08 FlexQoS: Applying custom iptables rules
Jul  8 13:12:11 FlexQoS: Applying AppDB static rules
Jul  8 13:12:11 FlexQoS: RTNETLINK answers: Invalid argument
Jul  8 13:12:11 FlexQoS: We have an error talking to the kernel
Jul  8 13:12:11 FlexQoS: Applying custom AppDB rules
Jul  8 13:12:11 FlexQoS: Unknown filter "flowid", hence option "1:16" is unparsable
Jul  8 13:12:11 FlexQoS: RTNETLINK answers: Invalid argument
Jul  8 13:12:11 FlexQoS: We have an error talking to the kernel
Jul  8 13:12:11 FlexQoS: RTNETLINK answers: Invalid argument
Jul  8 13:12:11 FlexQoS: We have an error talking to the kernel
Jul  8 13:12:11 FlexQoS: RTNETLINK answers: Invalid argument
Jul  8 13:12:11 FlexQoS: We have an error talking to the kernel
Jul  8 13:12:11 FlexQoS: RTNETLINK answers: Invalid argument
Jul  8 13:12:11 FlexQoS: We have an error talking to the kernel
Jul  8 13:12:11 FlexQoS: RTNETLINK answers: Invalid argument
Jul  8 13:12:11 FlexQoS: We have an error talking to the kernel
Jul  8 13:12:11 FlexQoS: Unknown filter "flowid", hence option "1:14" is unparsable
Jul  8 13:12:11 FlexQoS: Unknown filter "flowid", hence option "1:14" is unparsable
Jul  8 13:12:11 FlexQoS: RTNETLINK answers: Invalid argument
Jul  8 13:12:11 FlexQoS: We have an error talking to the kernel
Jul  8 13:12:11 FlexQoS: Applying custom bandwidth rates
Jul  8 13:12:11 kernel: HTB: quantum of class 10012 is big. Consider r2q change.
Jul  8 13:12:11 FlexQoS: Illegal "buffer"
Jul  8 13:12:11 FlexQoS: Usage: ... qdisc add ... htb [default N] [r2q N]
Jul  8 13:12:11 FlexQoS:                       [direct_qlen P]
Jul  8 13:12:11 FlexQoS:  default  minor id of class to which unclassified packets are sent {0}
Jul  8 13:12:11 FlexQoS:  r2q      DRR quantums are computed as rate in Bps/r2q {10}
Jul  8 13:12:11 FlexQoS:  debug    string of 16 numbers each 0-3 {0}
Jul  8 13:12:11 FlexQoS:  direct_qlen  Limit of the direct queue {in packets}
Jul  8 13:12:11 FlexQoS: ... class add ... htb rate R1 [burst B1] [mpu B] [overhead O]
Jul  8 13:12:11 FlexQoS:                       [prio P] [slot S] [pslot PS]
Jul  8 13:12:11 FlexQoS:                       [ceil R2] [cburst B2] [mtu MTU] [quantum Q]
Jul  8 13:12:11 FlexQoS:  rate     rate allocated to this class (class can still borrow)
Jul  8 13:12:11 FlexQoS:  burst    max bytes burst which can be accumulated during idle period {computed}
Jul  8 13:12:11 FlexQoS:  mpu      minimum packet size used in rate computations
Jul  8 13:12:11 FlexQoS:  overhead per-packet size overhead used in rate computations
Jul  8 13:12:11 FlexQoS:  linklay  adapting to a linklayer e.g. atm
Jul  8 13:12:11 FlexQoS:  ceil     definite upper class rate (no borrows) {rate}
Jul  8 13:12:11 FlexQoS:  cburst   burst but for ceil {computed}
Jul  8 13:12:11 FlexQoS:  mtu      max packet size we create rate map for {1600}
Jul  8 13:12:11 FlexQoS:  prio     priority of leaf; lower are served first {0}
Jul  8 13:12:11 FlexQoS:  quantum  how much bytes to serve from leaf at once {use r2q}
Jul  8 13:12:11 FlexQoS: TC HTB version 3.3
 
Code:
Jul  8 22:33:01 FlexQoS: /jffs/addons/flexqos/flexqos.sh (pid=10750) called with 1 args: check
Jul  8 22:33:01 FlexQoS: No TC modifications necessary
Is this the check that is done after 5 minutes from startup?
Yes.
 
Getting atm this error after a fresh install of FlexQOS:
Asus 384.18 on AX-58U

Code:
Jul  8 13:12:07 FlexQoS: /jffs/addons/flexqos/flexqos.sh (pid=5478) called with 2 args: -start ppp0
Jul  8 13:12:07 wlceventd: wlceventd_proc_event(464): eth5: Deauth_ind B8:E8:56:3F:CB:D0, status: 0, reason: Class 3 frame received from nonassociated station (7)
Jul  8 13:12:07 flexqos: [*] Killing Delayed Process (pid=3320)
Jul  8 13:12:07 flexqos: [*]  3320 DoctorXX  3536 S    sh /jffs/addons/flexqos/flexqos.sh -start ppp0
Jul  8 13:12:08 spdMerlin: Mounting spdMerlin WebUI page as user3.asp
Jul  8 13:12:08 FlexQoS: Applying iptables static rules
Jul  8 13:12:08 FlexQoS: Applying custom iptables rules
Jul  8 13:12:11 FlexQoS: Applying AppDB static rules
Jul  8 13:12:11 FlexQoS: RTNETLINK answers: Invalid argument
Jul  8 13:12:11 FlexQoS: We have an error talking to the kernel
Jul  8 13:12:11 FlexQoS: Applying custom AppDB rules
Jul  8 13:12:11 FlexQoS: Unknown filter "flowid", hence option "1:16" is unparsable
Jul  8 13:12:11 FlexQoS: RTNETLINK answers: Invalid argument
Jul  8 13:12:11 FlexQoS: We have an error talking to the kernel
Jul  8 13:12:11 FlexQoS: RTNETLINK answers: Invalid argument
Jul  8 13:12:11 FlexQoS: We have an error talking to the kernel
Jul  8 13:12:11 FlexQoS: RTNETLINK answers: Invalid argument
Jul  8 13:12:11 FlexQoS: We have an error talking to the kernel
Jul  8 13:12:11 FlexQoS: RTNETLINK answers: Invalid argument
Jul  8 13:12:11 FlexQoS: We have an error talking to the kernel
Jul  8 13:12:11 FlexQoS: RTNETLINK answers: Invalid argument
Jul  8 13:12:11 FlexQoS: We have an error talking to the kernel
Jul  8 13:12:11 FlexQoS: Unknown filter "flowid", hence option "1:14" is unparsable
Jul  8 13:12:11 FlexQoS: Unknown filter "flowid", hence option "1:14" is unparsable
Jul  8 13:12:11 FlexQoS: RTNETLINK answers: Invalid argument
Jul  8 13:12:11 FlexQoS: We have an error talking to the kernel
Jul  8 13:12:11 FlexQoS: Applying custom bandwidth rates
Jul  8 13:12:11 kernel: HTB: quantum of class 10012 is big. Consider r2q change.
Jul  8 13:12:11 FlexQoS: Illegal "buffer"
Jul  8 13:12:11 FlexQoS: Usage: ... qdisc add ... htb [default N] [r2q N]
Jul  8 13:12:11 FlexQoS:                       [direct_qlen P]
Jul  8 13:12:11 FlexQoS:  default  minor id of class to which unclassified packets are sent {0}
Jul  8 13:12:11 FlexQoS:  r2q      DRR quantums are computed as rate in Bps/r2q {10}
Jul  8 13:12:11 FlexQoS:  debug    string of 16 numbers each 0-3 {0}
Jul  8 13:12:11 FlexQoS:  direct_qlen  Limit of the direct queue {in packets}
Jul  8 13:12:11 FlexQoS: ... class add ... htb rate R1 [burst B1] [mpu B] [overhead O]
Jul  8 13:12:11 FlexQoS:                       [prio P] [slot S] [pslot PS]
Jul  8 13:12:11 FlexQoS:                       [ceil R2] [cburst B2] [mtu MTU] [quantum Q]
Jul  8 13:12:11 FlexQoS:  rate     rate allocated to this class (class can still borrow)
Jul  8 13:12:11 FlexQoS:  burst    max bytes burst which can be accumulated during idle period {computed}
Jul  8 13:12:11 FlexQoS:  mpu      minimum packet size used in rate computations
Jul  8 13:12:11 FlexQoS:  overhead per-packet size overhead used in rate computations
Jul  8 13:12:11 FlexQoS:  linklay  adapting to a linklayer e.g. atm
Jul  8 13:12:11 FlexQoS:  ceil     definite upper class rate (no borrows) {rate}
Jul  8 13:12:11 FlexQoS:  cburst   burst but for ceil {computed}
Jul  8 13:12:11 FlexQoS:  mtu      max packet size we create rate map for {1600}
Jul  8 13:12:11 FlexQoS:  prio     priority of leaf; lower are served first {0}
Jul  8 13:12:11 FlexQoS:  quantum  how much bytes to serve from leaf at once {use r2q}
Jul  8 13:12:11 FlexQoS: TC HTB version 3.3
Please post a flexqos debug
 

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