FlexQoS FlexQoS 1.2.4 - Flexible QoS Enhancement Script for Adaptive QoS

  • ATTENTION! You'll notice a Prefix dropdown when you create a thread. If your post applies to one of the topics listed, please use that Prefix for your post. When browsing the thread list you can use the Prefix to filter the view.
  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

rlj2

Regular Contributor
What's most striking about the output is that the only traffic logged in the download classes seems to be the traffic you explicitly mark with an iptables rule. All the other 1:10-15 and 1:17 classes have zero bytes, which seems very hard to do on a network. If you remove that last iptables rule and run the test again, does that traffic show up anywhere? Maybe the Trend marking engine is broken on the AX86U. Feels weird to me. Is anything else connected to this router right now?
remember on that test, i set everything on that ip to go to gaming. Is that why?
 

dave14305

Part of the Furniture
I removed the rule , only one device on the router right now.
Just did some random crap using bandwidth.
OK, if there was only one device on the network and it was forced to Gaming, that makes sense. So you never saw that traffic showing in the bandwidth charts or counters? What about on the Classification page?
 

rlj2

Regular Contributor
@dave14305 Let me sit down tonight to do some more testing. I have the AX86u and AC86u both hooked directly to the modem with different SSID's. So its
very easy to bounce back and forth. Interested in a AX?
But from memory (damn classifcation page keeps disabling over to many connections) it, and flexqos charts show the same.
 

rlj2

Regular Contributor
@dave14305 your charts and classification page are pretty much same. both show "some" traffic moving, but nowhere close to the majority. Whats also
strange is. When i set one of those rules and run speedtest. both those items dont show it, but apps analysis in bandwidth monitor shows "speedtest.net" and the correct info.
 

sentinelvdx

Very Senior Member
Bash:
tc qdisc ls | grep fq_codel
Hi, I have switched to develop channel, but when issuing " tc qdisc ls | grep fq_codel " thought ssh, nothing happens
I'm on AC88U 386.1 b5
 

dave14305

Part of the Furniture
Hi, I have switched to develop channel, but when issuing " tc qdisc ls | grep fq_codel " thought ssh, nothing happens
I'm on AC88U 386.1 b5
Have you also switched the option below (it will have a better description soon)?

1611942607137.png
 

sentinelvdx

Very Senior Member
Have you also switched the option below (it will have a better description soon)?

View attachment 29986
Doh! didn't check that haha

[email protected]:/tmp/home/root# tc qdisc ls | grep fq_codel
qdisc fq_codel 800a: dev eth0 parent 1:2 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 800c: dev eth0 parent 1:10 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 800e: dev eth0 parent 1:11 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8010: dev eth0 parent 1:12 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8012: dev eth0 parent 1:13 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8014: dev eth0 parent 1:14 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8016: dev eth0 parent 1:15 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8018: dev eth0 parent 1:16 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 801a: dev eth0 parent 1:17 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8001: dev br0 parent 1:2 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 800b: dev br0 parent 1:10 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 800d: dev br0 parent 1:11 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 800f: dev br0 parent 1:12 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8011: dev br0 parent 1:13 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8013: dev br0 parent 1:14 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8015: dev br0 parent 1:15 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8017: dev br0 parent 1:16 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8019: dev br0 parent 1:17 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
[email protected]:/tmp/home/root#
 

rlj2

Regular Contributor
Doh! didn't check that haha

[email protected]:/tmp/home/root# tc qdisc ls | grep fq_codel
qdisc fq_codel 800a: dev eth0 parent 1:2 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 800c: dev eth0 parent 1:10 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 800e: dev eth0 parent 1:11 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8010: dev eth0 parent 1:12 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8012: dev eth0 parent 1:13 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8014: dev eth0 parent 1:14 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8016: dev eth0 parent 1:15 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8018: dev eth0 parent 1:16 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 801a: dev eth0 parent 1:17 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8001: dev br0 parent 1:2 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 800b: dev br0 parent 1:10 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 800d: dev br0 parent 1:11 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 800f: dev br0 parent 1:12 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8011: dev br0 parent 1:13 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8013: dev br0 parent 1:14 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8015: dev br0 parent 1:15 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8017: dev br0 parent 1:16 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 8019: dev br0 parent 1:17 limit 1024p flows 1024 quantum 1514 target 5.0ms interval 100.0ms ecn
[email protected]:/tmp/home/root#
Is this adaptive qos? I thought fq_codel was no longer available.
 

rlj2

Regular Contributor
It's "Dave-adapted" Adaptive QoS. I like to think of it as comparable to CAKE with diffserv8 but still keeping HW acceleration. :)
I tried it, switched to dev, enabled it. But it still shows sfq... figures its me right? :) EDIT: nevermind, i switched to dev, but it didnt automatically go to 1.1.1, once that happened its showing fq_codel
 

Sinner

Senior Member
Switched to develop once again, thank you! :) BTW, had an eye on the cronjob at 3:30 am and it never had to reinitialize qos in the last weeks. Looks like it's really not needed anymore like you already mentioned/asked in the past.

Regarding fq_codel testing: How could we check/verify if it's still active on a regular basis to give feedback?
it was implemented if i recall way back because the trend db updates at 2am when it updates and resets qos. When this happens the script is no longer running and requires the cronjob to fire it back up.
 

geobernd

Occasional Visitor
Upgraded my RT-AC68P to 386.1 and latest FlexQoS 1.1 development branch this morning.
Adaptive QoS manual limits and Queue Discipline fq_codel set.
It was a bit choppy after even after the router settled down and while FlexQoS seemd to be running the router did not adhere to the set bandwidth limits...
Toggling QoS off and on and restarting FlexQoS fixed the issue.
I then did a router reboot for good measures and I think everything is still running fine.

Thank you for the great work you do on FlexQoS - it makes this router so much better!
 

chris.at

Regular Contributor
Also upgraded to the new 386.1 and got the following entry after upgrade and again after a reboot:
Code:
Jan 31 15:42:29 FlexQoS: TC Modification Delay reached maximum 300 seconds. Aborting startup!
FlexQoS isn't running afterwards, a flexqos restart command works.
Tried to fix with a reinstall now, will keep an eye on it.
 

geobernd

Occasional Visitor
Also upgraded to the new 386.1 and got the following entry after upgrade and again after a reboot:
Code:
Jan 31 15:42:29 FlexQoS: TC Modification Delay reached maximum 300 seconds. Aborting startup!
FlexQoS isn't running afterwards, a flexqos restart command works.
Tried to fix with a reinstall now, will keep an eye on it.
I now remember seeing exactly the same message this morning. Didn't come back after manual restart and another reboot after so may just be related to the router being too busy to do something in the first 10 minutes or so after the update...
 

raion969

Senior Member
when does the fq_codel come to stable version ?
 

Similar threads

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