FlexQoS FlexQoS 1.0 - Flexible QoS Enhancement Script for Adaptive QoS

[skeal]

Heyy now that i have you have set i should Reset the ip rule it doesnt track cs go in the right category, it flows into others?

how can i add cs go that all of this application flows into gaming ?

I have tried set up the gaming rule but it dont show up in the script

I think i need to Go back to FreshJR because it worked way better!

Sadly not even the biggest fps game is recogniced properly

its really sad that i have to switch to an old script just because its to hard to priorize the biggest game in esports. nice job i tried all rules nothing is workig i dont see even a rule that says rule1 for example

is there not a way that lets say all of the traffic that my pc have and is categoried into gaming ??

Do you even play games to See if it works?

I was playing CS-GO last night using this and my traffic wasn't classified as other. It was properly classified as gaming even the gaming download was classeed right.

 

[Smokey613]

The only drawback to running any Asus/TM QoS stuff is the constant dcd crashes:

Jul 12 12:30:35 RT-AC86U kernel: [00000000] *pgd=0000000012464003, *pud=0000000012464003, *pmd=0000000001441003, *pte=0000000000000000
Jul 12 12:30:35 RT-AC86U kernel: CPU: 1 PID: 18226 Comm: dcd Tainted: P O 4.1.27 #2
Jul 12 12:30:35 RT-AC86U kernel: Hardware name: Broadcom-v8A (DT)
Jul 12 12:30:35 RT-AC86U kernel: task: ffffffc0170a81c0 ti: ffffffc00c298000 task.ti: ffffffc00c298000
Jul 12 12:30:35 RT-AC86U kernel: PC is at 0xf73e6f44
Jul 12 12:30:35 RT-AC86U kernel: LR is at 0x1dc74
Jul 12 12:30:35 RT-AC86U kernel: pc : [<00000000f73e6f44>] lr : [<000000000001dc74>] pstate: 600e0010
Jul 12 12:30:35 RT-AC86U kernel: sp : 00000000ffcc5388
Jul 12 12:30:35 RT-AC86U kernel: x12: 000000000009ff08
Jul 12 12:30:35 RT-AC86U kernel: x11: 00000000f66ff024 x10: 00000000000a02ac
Jul 12 12:30:35 RT-AC86U kernel: x9 : 00000000f66ffda4 x8 : 00000000000a0764
Jul 12 12:30:35 RT-AC86U kernel: x7 : 00000000f66ffdd4 x6 : 00000000000a075e
Jul 12 12:30:35 RT-AC86U kernel: x5 : 0000000000000000 x4 : 00000000f66ffd88
Jul 12 12:30:35 RT-AC86U kernel: x3 : 0000000000000000 x2 : 0000000000000000
Jul 12 12:30:35 RT-AC86U kernel: x1 : 000000000007c66c x0 : 0000000000000000

 

[dave14305]

The only drawback to running any Asus/TM QoS stuff is the constant dcd crashes:

Jul 12 12:30:35 RT-AC86U kernel: [00000000] *pgd=0000000012464003, *pud=0000000012464003, *pmd=0000000001441003, *pte=0000000000000000
Jul 12 12:30:35 RT-AC86U kernel: CPU: 1 PID: 18226 Comm: dcd Tainted: P O 4.1.27 #2
Jul 12 12:30:35 RT-AC86U kernel: Hardware name: Broadcom-v8A (DT)
Jul 12 12:30:35 RT-AC86U kernel: task: ffffffc0170a81c0 ti: ffffffc00c298000 task.ti: ffffffc00c298000
Jul 12 12:30:35 RT-AC86U kernel: PC is at 0xf73e6f44
Jul 12 12:30:35 RT-AC86U kernel: LR is at 0x1dc74
Jul 12 12:30:35 RT-AC86U kernel: pc : [<00000000f73e6f44>] lr : [<000000000001dc74>] pstate: 600e0010
Jul 12 12:30:35 RT-AC86U kernel: sp : 00000000ffcc5388
Jul 12 12:30:35 RT-AC86U kernel: x12: 000000000009ff08
Jul 12 12:30:35 RT-AC86U kernel: x11: 00000000f66ff024 x10: 00000000000a02ac
Jul 12 12:30:35 RT-AC86U kernel: x9 : 00000000f66ffda4 x8 : 00000000000a0764
Jul 12 12:30:35 RT-AC86U kernel: x7 : 00000000f66ffdd4 x6 : 00000000000a075e
Jul 12 12:30:35 RT-AC86U kernel: x5 : 0000000000000000 x4 : 00000000f66ffd88
Jul 12 12:30:35 RT-AC86U kernel: x3 : 0000000000000000 x2 : 0000000000000000
Jul 12 12:30:35 RT-AC86U kernel: x1 : 000000000007c66c x0 : 0000000000000000

@Delusion had done some analysis about a year ago and came up with the Pixelserv theory. He found a way to make dcd log what it was doing. Off topic for this thread, but see this one: [Solved] AC86U - possible memory leaks. AiProtection(dcd) crashing is guilty

 

[dave14305]

Just an FYI...I 'borrowed' that calculation from Tomato....

If there wasn't a lot of "borrowing" in QoS implementations, I don't think anyone would have QoS as a feature. Very hard to find all the information in one place.

My next deep dive is burst and cburst. What Asus does by default in A.QoS is take the rate and divide by 800 (8 bits per byte and 100 to get 1% of rate) to get the burst. They do the same thing with ceil to get the cburst. In all cases, they set the floor to 3200. But at larger rates and ceils, they seem to be rounding in a way I can't quite follow. Maybe it's time for an Excel spreadsheet...but not today...

Spoiler: Rounded bursts

Jul 12 14:33:10 kernel: DBG[add_htb_class:1527] class add dev br0 parent 1:1 classid 1:10 htb prio 0 rate 16128000bit ceil 322560000bit burst 19200 cburst 403200 quantum 201600
Jul 12 14:33:11 kernel: DBG[add_htb_class:1527] class add dev br0 parent 1:1 classid 1:11 htb prio 1 rate 64512000bit ceil 322560000bit burst 80000 cburst 403200 quantum 806400
Jul 12 14:33:11 kernel: DBG[add_htb_class:1527] class add dev br0 parent 1:1 classid 1:12 htb prio 2 rate 32256000bit ceil 322560000bit burst 40000 cburst 403200 quantum 403200
Jul 12 14:33:11 kernel: DBG[add_htb_class:1527] class add dev br0 parent 1:1 classid 1:13 htb prio 3 rate 16128000bit ceil 322560000bit burst 19200 cburst 403200 quantum 201600
Jul 12 14:33:12 kernel: DBG[add_htb_class:1527] class add dev br0 parent 1:1 classid 1:14 htb prio 4 rate 12896000bit ceil 322560000bit burst 16000 cburst 403200 quantum 161200
Jul 12 14:33:12 kernel: DBG[add_htb_class:1527] class add dev br0 parent 1:1 classid 1:15 htb prio 5 rate 9672000bit ceil 322560000bit burst 11200 cburst 403200 quantum 120900
Jul 12 14:33:13 kernel: DBG[add_htb_class:1527] class add dev br0 parent 1:1 classid 1:16 htb prio 6 rate 6448000bit ceil 322560000bit burst 8000 cburst 403200 quantum 80600
Jul 12 14:33:13 kernel: DBG[add_htb_class:1527] class add dev br0 parent 1:1 classid 1:17 htb prio 7 rate 3224000bit ceil 322560000bit burst 3200 cburst 403200 quantum 40300

Spoiler: Setting 3200b floor

Jul 12 14:33:10 kernel: INFO[rate2burst:1392] Burst value 2940 for 2352000 Bit/s is less than 3200, adjust to minimal.
Jul 12 14:33:10 kernel: INFO[rate2burst:1392] Burst value 2940 for 2352000 Bit/s is less than 3200, adjust to minimal.
Jul 12 14:33:10 kernel: DBG[add_htb_root:1608] class add dev eth0 parent 1: classid 1:1 htb rate 2352000bit ceil 2352000bit burst 3200 cburst 3200 quantum 235200
--
Jul 12 14:33:10 kernel: INFO[rate2burst:1392] Burst value 140 for 112000 Bit/s is less than 3200, adjust to minimal.
Jul 12 14:33:10 kernel: INFO[rate2burst:1392] Burst value 2940 for 2352000 Bit/s is less than 3200, adjust to minimal.
Jul 12 14:33:10 kernel: DBG[add_htb_class:1527] class add dev eth0 parent 1:1 classid 1:10 htb prio 0 rate 112000bit ceil 2352000bit burst 3200 cburst 3200 quantum 1400
--
Jul 12 14:33:10 kernel: INFO[rate2burst:1392] Burst value 2940 for 2352000 Bit/s is less than 3200, adjust to minimal.
Jul 12 14:33:10 kernel: INFO[rate2burst:1392] Burst value 2940 for 2352000 Bit/s is less than 3200, adjust to minimal.
Jul 12 14:33:10 kernel: DBG[add_htb_root:1663] class add dev eth0 parent 10: classid 10:1 htb rate 2352000bit ceil 2352000bit burst 3200 cburst 3200 quantum 235200
--
Jul 12 14:33:10 kernel: INFO[rate2burst:1392] Burst value 20 for 16000 Bit/s is less than 3200, adjust to minimal.
Jul 12 14:33:10 kernel: INFO[rate2burst:1392] Burst value 2940 for 2352000 Bit/s is less than 3200, adjust to minimal.
Jul 12 14:33:10 kernel: DBG[add_htb_class:1527] class add dev eth0 parent 10:1 classid 10:256 htb prio 3 rate 16000bit ceil 2352000bit burst 3200 cburst 3200 quantum 200
--
Jul 12 14:33:10 kernel: INFO[rate2burst:1392] Burst value 20 for 16000 Bit/s is less than 3200, adjust to minimal.
Jul 12 14:33:11 kernel: DBG[add_htb_class:1527] class add dev br0 parent 10:1 classid 10:256 htb prio 3 rate 16000bit ceil 322560000bit burst 3200 cburst 403200 quantum 200
--
Jul 12 14:33:11 kernel: INFO[rate2burst:1392] Burst value 580 for 464000 Bit/s is less than 3200, adjust to minimal.
Jul 12 14:33:11 kernel: INFO[rate2burst:1392] Burst value 2940 for 2352000 Bit/s is less than 3200, adjust to minimal.
Jul 12 14:33:11 kernel: DBG[add_htb_class:1527] class add dev eth0 parent 1:1 classid 1:11 htb prio 1 rate 464000bit ceil 2352000bit burst 3200 cburst 3200 quantum 5800
--

Since this script can modify the rate and ceil per class, it would make sense to recalculate the burst and cburst. FreshJR historically has kept the same burst and cburst as Asus defines before the script overrides the rate/ceil.

 

[Smokey613]

@Delusion had done some analysis about a year ago and came up with the Pixelserv theory. He found a way to make dcd log what it was doing. Off topic for this thread, but see this one: [Solved] AC86U - possible memory leaks. AiProtection(dcd) crashing is guilty

Interesting thread, however I am not running AiProtection or Diversion/Pixelserv so not sure. I do know however, if I withdraw from the Privacy agreement, this error goes away.

 

[immi803]

@dave14305
I've native Ipv6 supported in my connection and I've tried flex for first time on experimental basis with ipv6, it likes to limit DL speed but has no limitation on UL speed, Does this feature for support of ipv6 still needs to be worked out or what can be the possible issue??

 

[dave14305]

@dave14305
I've native Ipv6 supported in my connection and I've tried flex for first time on experimental basis with ipv6, it likes to limit DL speed but has no limitation on UL speed, Does this feature for support of ipv6 still needs to be worked out or what can be the possible issue??

The only limitation I know of is that it won’t support iptables rules that use IPv4 addresses. What tests are you running to show it isn’t limiting upload? What router model? Some models have issues with upload limiting due to an Asus bug.

 

[dave14305]

I never knew that Adaptive QoS will reserve bandwidth for specific apps (mostly streaming) when traffic is detected.

I watched a Vimeo video (cat 4, app 197) as a test and it creates special qdisc and filters for it:

Jul 12 18:04:35 kernel: DBG[prep_app_ses_class:2930] App 3-4-197 qos_flag = 0xc0004
Jul 12 18:04:35 kernel: DETAIL[reserve_ses_bw:2216]
Jul 12 18:04:35 kernel: DBG[create_app_ses_leaf:3180] Reserved bandwidth = 920000 (req = 920000)
Jul 12 18:04:35 kernel: DETAIL[prep_app_ses_filter:2940]
Jul 12 18:04:35 kernel: DETAIL[add_htb_class:1493]
Jul 12 18:04:35 kernel: INFO[add_htb_class:1515] cls->rsv_bw=920000
Jul 12 18:04:35 kernel: INFO[rate2burst:1392] Burst value 1150 for 920000 Bit/s is less than 3200, adjust to minimal.
Jul 12 18:04:35 kernel: DBG[add_htb_class:1527] class add dev br0 parent 12:1 classid 12:326 htb prio 2 rate 920000bit ceil 322560000bit burst 3200 cburst 403200 quantum 11500
Jul 12 18:04:35 kernel: DBG[add_htb_class:1537] qdisc add dev br0 parent 12:326 handle 3326: sfq
Jul 12 18:04:35 kernel: DETAIL[add_htb_filter:1466]
Jul 12 18:04:35 kernel: DBG[add_htb_filter:1481] filter add dev br0 parent 12: protocol all prio 70 u32 match mark 0x80c000c5 0xffc0ffff flowid 12:326
Jul 12 18:04:35 kernel: DETAIL[add_ses_class_to_list:1970]
Jul 12 18:04:35 kernel: DBG[set_app_info_qos_meta:3468] Set meta data for app instance 3-4-197
Jul 12 18:04:35 kernel: htb: htb qdisc 12: is non-work-conserving?

Nothing actionable from this, but I wondered what the /tmp/bwdpi/bwdpi.bndwth.db file was for. 360 and 720 sound like resolutions.

# grep ^4,197 bwdpi.bndwth.db
4,197,4,360,115
4,197,4,720,1024

 

[JAAAAA]

How have you defined each of these 2 rules to separate Gaming from Game Downloads?

Should I add more rules for those specific Warzone ports to classify them as gaming? Or do I not need to do anything to these IP TABLES?

Should I have assigned the Game Downloads to the PS4 or should it just be for the Gaming Row?

 

[dave14305]

Should I add more rules for those specific Warzone ports to classify them as gaming? Or do I not need to do anything to these IP TABLES?

Should I have assigned the Game Downloads to the PS4 or should it just be for the Gaming Row?

Generally, the Game Downloads rule should apply to all devices.

Unless your game uses ports 80 or 443, it should be fine. How does it appear in the connection list?

 

[JAAAAA]

Generally, the Game Downloads rule should apply to all devices.

Unless your game uses ports 80 or 443, it should be fine. How does it appear in the connection list?

Completed the following:

• Removed the manual IP for the PS4 from Game Downloads so that it applies to all devices.

I've attached the recommended ports that the Warzone website requires to be open / think this is the ports that they are using (highlighted in blue for ps4)

Should I do anything here? (PS thanks for taking the time to help!)

 

[immi803]

The only limitation I know of is that it won’t support iptables rules that use IPv4 addresses. What tests are you running to show it isn’t limiting upload? What router model? Some models have issues with upload limiting due to an Asus bug.

My router is AC68U, I've tried different type of tests like Ookla speed test on devices, dslreports, fast etc

 

[dave14305]

Completed the following:

• Removed the manual IP for the PS4 from Game Downloads so that it applies to all devices.

I've attached the recommended ports that the Warzone website requires to be open / think this is the ports that they are using (highlighted in blue for ps4)

Should I do anything here? (PS thanks for taking the time to help!)

What results are you getting in the Tracked connections list with the settings you currently have? Is anything mis-categorized? If your game uses port 80 and 443 for actual gameplay, then maybe it will get incorrectly categorized.

 

[dave14305]

My router is AC68U, I've tried different type of tests like Ookla speed test on devices, dslreports, fast etc

How fast is it going beyond your set upload limit?

 

[immi803]

How fast is it going beyond your set upload limit?

i was just testing the ipv6 functionallity, limit my 100 mb connection to 35mb and it didn't limit at all, and went all the way up to 100 mb UL

 

[dave14305]

i was just testing the ipv6 functionallity, limit my 100 mb connection to 35mb and it didn't limit at all, and went all the way up to 100 mb UL

Ok, I do see IPv6 upload not showing up in the tc charts, but it also happens when the script is disabled, so it could be an Asus bug. It would be helpful to know if other IPv6 users can replicate this. Fast.com seems easier to test on IPv6.

 

[immi803]

Ok, I do see IPv6 upload not showing up in the tc charts, but it also happens when the script is disabled, so it could be an Asus bug. It would be helpful to know if other IPv6 users can replicate this. Fast.com seems easier to test on IPv6.

obviously other ipv6 user's situation will help us
can we rectify this at our end as its not showing in tc or we have to wait from @RMerlin / asus end to recify it?

 

[dave14305]

obviously other ipv6 user's situation will help us
can we rectify this at our end as its not showing in tc or we have to wait from @RMerlin / asus end to recify it?

It’s not going to be a Merlin problem based on other QoS issues reported in the past. If it affects tQoS, maybe he could identify something, but Adaptive QoS is not fixable since there is no open source for it.

I’m not sure how to troubleshoot an issue like this. I’ll have to play around with ip6tables to log some traffic and see if it’s marked.

 

[immi803]

It’s not going to be a Merlin problem based on other QoS issues reported in the past. If it affects tQoS, maybe he could identify something, but Adaptive QoS is not fixable since there is no open source for it.

I’m not sure how to troubleshoot an issue like this. I’ll have to play around with ip6tables to log some traffic and see if it’s marked.

looking forward to your efforts
quote : playing is learning
thank you

 

[raion969]

@immi803 @Dave gaming is learning ping/stable connection and co