FlexQoS FlexQoS 1.0 - Flexible QoS Enhancement Script for Adaptive QoS

[dave14305]

This is my custom categorization setup:

Others
Gaming
Work from Home
Web Surfing
Video/Audio
File Transfer
Learn from Home

You recommend I bring ''others'' down? I heard for gaming, some gaming traffic can be included under others.

It confuses me because your FlexQoS rules shouldn’t be present after a service restart_qos. But working with @Kanji-San it looks like the tc filter rules keep duplicating the longer the router is up and QoS gets restarted. Or more accurately the previous tc rules aren’t removed. A reboot resets everything, so maybe my excitement was premature and Adaptive QoS is bugged on the AX88U 19 beta1.

tc filter show dev br0 | grep -c flowid

Should be less than 50. Kanji-San was in the 500s before a reboot.

 

[Vexira]

This is my custom categorization setup:

Others
Gaming
Work from Home
Web Surfing
Video/Audio
File Transfer
Learn from Home

You recommend I bring ''others'' down? I heard for gaming, some gaming traffic can be included under others.

I use the old freshjr setup for priority, but instead of work from home (VoIP) I have gaming at the top.

 

[Kanji-San]

After a lengthy beta period, tonight I am drawing a line in the sand and declaring FlexQoS v1.0.0 to be officially released!

I've added a lengthy readme on GitHub trying to describe the functionality and basic usage of the script and WebUI.

Thanks to everyone who supports this project and provides valuable feedback. Please update so I can know what bugs I introduced with v1.0.0.

Thank you very much, Dave, for your dedication. You have done a lot of hard work when you took over the development. FlexQoS is incredibly useful and makes Adaptive QoS on Asus routers so much better.

Also, I am grateful for your debugging FlexQoS on the RT-AX88U
Keep up the great work!

 

[geobernd]

Upgraded my AC68U to 384.19beta1 and FlexQoS to v1.0.0 - all running well. As a plus 384.19beta1 seems to handle fast download rampup quicker: The short bufferbloat periods when QoS kicks in are much short. Suspect it has to do with the merge of bwdpi components from 385_20630.
Thanks for all the hard work you put in

 

[Kingp1n]

I use the old freshjr setup for priority, but instead of work from home (VoIP) I have gaming at the top.

Is this your setup below?

Gaming
Work from Home
Others
Web Surfing
Video/Audio
File Transfer
Learn from Home

 

[Kanji-San]

Is this your setup below?

Gaming
Work from Home
Others
Web Surfing
Video/Audio
File Transfer
Learn from Home

I have the exact same priorities as you. It has worked well in the past with my RT-AC68U. Now I migrated to the RT-AX88U.

 

[SomeWhereOverTheRainBow]

It confuses me because your FlexQoS rules shouldn’t be present after a service restart_qos. But working with @Kanji-San it looks like the tc filter rules keep duplicating the longer the router is up and QoS gets restarted. Or more accurately the previous tc rules aren’t removed. A reboot resets everything, so maybe my excitement was premature and Adaptive QoS is bugged on the AX88U 19 beta1.

tc filter show dev br0 | grep -c flowid

Should be less than 50. Kanji-San was in the 500s before a reboot.

My rtax88u has been running for a whole day and a half with flexqos and adaptive turned on and mine reports as 49. This is on .19 beta 1.

 

[dave14305]

My rtax88u has been running for a whole day and a half with flexqos and adaptive turned on and mine reports as 49. This is on .19 beta 1.

If you restart QoS, does it stay that way? service restart_qos

 

[chris.at]

Here is an example from my 68U:

ASUSWRT-Merlin RT-AC68U 384.19_beta1 Sun Aug  2 22:48:44 UTC 2020
admin@router:/tmp/home/root# tc filter show dev br0 | grep -c flowi
d
50
admin@router:/tmp/home/root# service restart_qos

Done.
admin@router:/tmp/home/root# tc filter show dev br0 | grep -c flowi
d
0
admin@router:/tmp/home/root# tc filter show dev br0 | grep -c flowi
d
0

 

[dave14305]

Here is an example from my 68U:

ASUSWRT-Merlin RT-AC68U 384.19_beta1 Sun Aug  2 22:48:44 UTC 2020
admin@router:/tmp/home/root# tc filter show dev br0 | grep -c flowi
d
50
admin@router:/tmp/home/root# service restart_qos

Done.
admin@router:/tmp/home/root# tc filter show dev br0 | grep -c flowi
d
0
admin@router:/tmp/home/root# tc filter show dev br0 | grep -c flowi
d
0

Yes, our AC68Us are just fine with beta1.

 

[SomeWhereOverTheRainBow]

If you restart QoS, does it stay that way? service restart_qos

Yes

 

[SomeWhereOverTheRainBow]

If you restart QoS, does it stay that way? service restart_qos

It changed on second time of restarting the service.

 

[dave14305]

Thank you very much, Dave, for your dedication. You have done a lot of hard work when you took over the development. FlexQoS is incredibly useful and makes Adaptive QoS on Asus routers so much better.

Also, I am grateful for your debugging FlexQoS on the RT-AX88U
Keep up the great work!

I think the workaround is that if you change the AppDB rules you will want to reboot the router to ensure only the new rules are in effect in tc filter. Otherwise, you may end up with old and new rules together with unpredictable results.

If you reboot and let FlexQoS startup, does your original download traffic show up correctly?

 

[Kanji-San]

I think the workaround is that if you change the AppDB rules you will want to reboot the router to ensure only the new rules are in effect in tc filter. Otherwise, you may end up with old and new rules together with unpredictable results.

If you reboot and let FlexQoS startup, does your original download traffic show up correctly?

After a router reboot all the traffic seems to show up correctly.

What happens during a reboot vs when AppDB settings on the web page are changed?

 

[dave14305]

What happens during a reboot vs when AppDB settings on the web page are changed?

It’s just a matter of ensuring the tc filters are cleared if you’re changing the priority of an existing AppDB rule. I’m happy I don’t see this behavior on the AC68U, but I’m unclear on the side-effects of the current AX88U build.

 

[dave14305]

It changed on second time of restarting the service.

Can you quantify that to confirm you’re seeing the same issue as Kanji-San?

 

[SomeWhereOverTheRainBow]

Can you quantify that to confirm you’re seeing the same issue as Kanji-San?

right now i am at 131
the first time the number changed it went to the 90's and now it is at 131

 

[SomeWhereOverTheRainBow]

in my experience, it does not go any higher than 131

 

[dave14305]

in my experience, it does not go any higher than 131

That’s too bad that it even goes over 50.

 

[Vexira]

I believe it should work on 384.15 after a few tweaks I made weeks ago.

FreshJR_QOS and FlexQoS employ the same techniques to customize QoS, so results should be similar, but you can try it out and see how it goes. Zoom calls usually result in Untracked udp connections that need to be forced to Work-From-Home.

EDIT: this is the iptables rule I added for Zoom calls:
View attachment 25251

Will that become a new default rule?