Traditional QoS kills router throughput, internet/LAN traffic unaffected

[dawt]

Description:
Enabling Traditional QoS kills throughput for traffic to/from the router itself (eg. built-in FTP server). By "kill", I mean getting throughput of ~100KB/s, whereas with QoS off I'm getting > 20MB/s. Traffic from LAN devices to the internet, or LAN devices to other LAN devices are affected, but nowhere to the extent I see with LAN to router traffic (eg. LAN to LAN I only get 30-40MB/s). This is all over a wired connection and I can reproduce issue with the latest stable firmware and after a factory reset (see steps to reproduce).

What's strange is that this issue appears after a fresh reboot, but logging into the web interface and navigating to the QoS page somehow fixes this. I traced it down to the /getTraffic.asp url. In other words, after a reboot I get slow speeds, but I get much faster speeds if I log into the web interface and visit only the /getTraffic.asp page. The speeds are nowhere as good as the non-QOS speeds, but I'm guessing that's from the inherent overhead of QoS. Furthermore, not connecting the WAN somehow causes the issue to not appear, independently of the /getTraffic.asp fix.

I searched around the forums and it looks like Traditional QoS is fundamentally broken or something and it's hard to fix. Since visiting the /getTraffic.asp seems to fix it, is it possible to add a workaround by automatically visiting that page, or better yet calling the underlying function of bwdpi_status() on startup?

Steps to reproduce:
1. navigate to the firmware update page and upload RT-AC68U_386.3_2.trx (current stable version)
2. after upload success, perform factory reset (using the hold WPS button method https://www.asus.com/support/FAQ/1039077)
3. go through the setup wizard as normal (router mode, DHCP mode for WAN, WAN cable is plugged in).
4. log into web ui, enable built-in FTP server
5. perform speed test by downloading a file from the built-in FTP server [I get around 30-40MB/s throughput at this step]
6. enable traditional QoS (this causes a reboot)
7. perform speed test again [I get 100KB/s download at this step]
8. log into web interface, visit the /getTraffic.asp page
9. perform speed test again [I get 30-40MB/s at this step]

Expected results:
I get good speeds (ie. not 100KB/s) from the router at all times, even after a fresh reboot

Actual results:
I get crap speeds from the router after a reboot, unless I visit the getTraffic.asp in which case it's magically fixed.

 

[alchemy]

For QoS I believe the best to try are CakeQoS or FlexQoS (in amtm: https://www.snbforums.com/threads/f...os-enhancement-script-for-adaptive-qos.73097/)

 

[dawt]

I'll try that, but given that this has such a trivial fix (adding a few lines of code somewhere) I hope RMerl add it to the core code.

 

[Tech9]

I believe the best to try are CakeQoS or FlexQoS

There is no Cake QoS on RT-AC68U and variants. HND models only.

 

[dawt]

There is no Cake QoS on RT-AC68U and variants. HND models only.

What about FlexQoS? Does that also only work on HND models?

 

[Tech9]

FlexQoS is Adaptive QoS custom configuration script. It will work, but I don’t think is necessary. It won’t fix the described issue, if Adaptive QoS doesn’t fix it. I’m not sure why the OP uses Traditional QoS. It’s incompatible with hardware acceleration.

 

[dawt]

I’m not sure why the OP uses Traditional QoS. It’s incompatible with hardware acceleration.

The non-hardware accelerated speeds are fine for me, and I don't want to consent to trendmicro's data collection.

 

[Tech9]

Fair enough.

 

[dawt]

I might have found the issue. After running tc -s -d qdisc, I discovered that one of the queues has a limit of 1p

# tc -s -d qdisc
---snip---
qdisc htb 2: dev br0 root refcnt 2 r2q 10 default 40 direct_packets_stat 0 ver 3.17
Sent 35230459 bytes 24649 pkt (dropped 4156, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
qdisc pfifo 60: dev br0 parent 2:60 limit 1p
Sent 34408305 bytes 18854 pkt (dropped 4156, overlimits 0 requeues 0)
backlog 0b 0p requeues 0
---snip---

Changing the limit to 9999 fixes the issue.

tc qdisc change dev br0 handle 60: pfifo limit 99999

The offending rule is being created by /tmp/qos, but I'm not sure where the 1p limit is being specified.

# download 2:60: LAN-to-LAN
$TCADL parent 2:2 classid 2:60 htb rate 10240000kbit ceil 10240000kbit burst 10000 cburst 10000 prio 6
$TQADL parent 2:60 handle 60: pfifo
$TFADL parent 2: prio 6 u32 match mark 6 7 flowid 2:60

My guess it's some sort of default? The strange part is that the corresponding rule for upload has basically the same structure, but upload speeds don't suffer from the issue. Hopefully with this information @RMerlin can add a more permanent fix.

 

[dave14305]

Changing the limit to 9999 fixes the issue.

What if you just delete the pfifo qdisc? Is it fine?

tc qdisc del dev br0 parent 2:60

but I'm not sure where the 1p limit is being specified.

It comes from the txqueuelen for br0 in ifconfig. Zero isn’t good, so probably increased to 1 for safety.

 

[dawt]

What if you just delete the pfifo qdisc? Is it fine?

tc qdisc del dev br0 parent 2:60

Speeds are still slow, same as before.

It looks packets are still being dropped.

qdisc htb 2: dev br0 root refcnt 2 r2q 10 default 40 direct_packets_stat 0 ver 3.17
Sent 24633783 bytes 18823 pkt (dropped 2009, overlimits 0 requeues 0)
backlog 0b 0p requeues 0

 

[dawt]

I was inspired by a fix from another thread https://www.snbforums.com/threads/r...-dl-limit-values-are-broken.78303/post-756258 and came up with this to automatically apply the fix I found.

#!/bin/sh

if [ "$1" = "init" ]; then
        sed 's/TQADL parent 2:60 handle 60: pfifo/TQADL parent 2:60 handle 60: pfifo limit 99/' -i /tmp/qos
fi