What's new

RT-AC68U Traditional QoS UL/DL limit values are broken?

  • 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!

Mr Solis

Occasional Visitor
I've recently dirty flashed 386.5 over 386.4 and noticed my download speed had deteriorated (~102mbps reduced to ~18mbps via Ookla) but the built in WebUI Internet Speed test is giving me expected results (102mbps/19mbps). I have Traditional QoS enabled with CTF disabled and this was previously working as intended but it seems to have broken with 386.5.

Thinking it was an issue with incompatible configurations between firmware revisions, I flashed 386.5_2 over 386.5 and performed a hard reset (reset button and again with WPS button) but am still experiencing the same issues. Everything else is working fine.

I've noticed that my download speed and upload speed are the same since 386.5. The issue seems to be related to the upload limit under Traditional QoS because when I increase its value, my download speeds increase accordingly.

Is anybody else experiencing this issue or is able to shed some light on a solution?

Cheers!

QoS configuration:
1649056982657.png


386.5_2 Traditional QoS enabled:
12985868185.png


386.5_2 QoS disabled:
12985825469.png
 
I’m always a sucker for a QoS mystery. What’s the output of:
Code:
/tmp/qos status
cat /tmp/qos
iptables -t mangle -nvL
ip6tables -t mangle -nvL
 
I couldn’t reproduce this issue on an AC68U running 386.5_2 with 102/19 bandwidth and 19 overhead.

Was this a wired or wireless test? Was the client used one of the MAC addresses in the QoS rules?

I actually hadn't tried the wireless devices as I assumed they'd exhibit the same issue but it seems they don't.

Wired w/ QoS rule: speed issue
Wired w/o QoS rule: speed issue

Wireless w/ QoS rule: no issue
Wireless w/o QoS rule: no issue

So it seems the wired connections are affected when QoS is enabled, regardless of their inclusion in the QoS rules.

CLI output

I should also mention that disabling QoS altogether doesn't exhibit any issues (other than buffer bloat!)
 
I've noticed that my download speed and upload speed are the same since 386.5. The issue seems to be related to the upload limit under Traditional QoS because when I increase its value, my download speeds increase accordingly.
Have you checked to see if the U/L and D/L fields haven't simply been flipped around?

What happens if you set the QoS D/L limit to something like 10Mbps? Does your tested U/L speed correspondingly drop to 10Mbps?
 
Have you checked to see if the U/L and D/L fields haven't simply been flipped around?

What happens if you set the QoS D/L limit to something like 10Mbps? Does your tested U/L speed correspondingly drop to 10Mbps?

I thought I'd test it anyway and it seems it's using the U/L value for both only if the U/L < D/L


i.e.

UL:5 & DL:10 would give me 5mbps for both U/L and D/L.

UL:10 & DL:5 would give me 10mbps U/L and 5mbps D/L


The plot thickens.
 
No, it's correct in the screenshot in post #1, and in the underlying tc configuration.
I didn't mean to suggest that he had entered them incorrectly, rather the firmware was applying them the wrong way around for some reason.

However, given their reply, the plot does indeed thicken.
 
Are you using a VPN? It can mess up with QoS.
 
All the download traffic is definitely being seen by the eth0 qdisc. Since it only affects wired devices, I’m speculating that it’s a vlan1 issue, but my vlan-foo is very very feeble. Wireless interfaces are in the bridge and unaffected. This is why I assume it’s the physical ports in vlan1.

Maybe @ColinTaylor can brainstorm some ideas with us. He knows everything.

A speedtest using 20MB of data in each direction shows 20MB sent on br0 and 40MB sent on eth0 (20 down, 20 up).
 
Downgrading to 386.4 restores normal download behavior. Just need to figure out if it was the GPL or the tQoS changes now. I'll try to transfer the /tmp/qos and iptables mangle rules from 386.4 to 386.5_2 as a test.

1649268697332.png


Edit: using 386.4 /tmp/qos on 386.5_2 also restores expected download throughput. So there is some regression in @KMO changes. More analysis required.
 
Last edited:
Downgrading to 386.4 restores normal download behavior. Just need to figure out if it was the GPL or the tQoS changes now. I'll try to transfer the /tmp/qos and iptables mangle rules from 386.4 to 386.5_2 as a test.

View attachment 40637

Edit: using 386.4 /tmp/qos on 386.5_2 also restores expected download throughput. So there is some regression in @KMO changes. More analysis required.
Unlikely to be tied to a GPL merge itself, most likely either from the changes I merged from kjbracey, or the supplemental changes Asus provided me following me forwarding them these changes for review.

I'll let you look at it, since you are more familiar than me with tc. Plus I got my hands full at the moment as last night's long list of commits to github indicate (that`s also why I haven`t had time to review any of your current PR, sorry).
 
Unlikely to be tied to a GPL merge itself, most likely either from the changes I merged from kjbracey, or the supplemental changes Asus provided me following me forwarding them these changes for review.

I'll let you look at it, since you are more familiar than me with tc. Plus I got my hands full at the moment as last night's long list of commits to github indicate (that`s also why I haven`t had time to review any of your current PR, sorry).
Yes, seems like the Asus change is to blame in the upload tc filter for 802.1q.


Going back to u32 match u32 0 0 flowid 1:60 fixes the download traffic. Haven’t figured out if the rest of the commit is good or bad yet.
 
Between the original fixes from a few years ago from a contributor, KMO's own fixes and Asus's own fixes (all mixed with my own changes to add overhead and fq_codel support), the current state of qos.c might be of a mess. It might need a thorough cleanup, and deciding whether to stick to upstream code, or stick to contributed code - but not both.

I even considered at one point scrapping the whole t.QoS implementation, and re-importing the original QoS code from Toastman, since that one is known to work very well (I have a VoIP customer for whom I run Tomato on an RT-N66U because Asuswrt's QoS simply didn't work). That might introduce other issues however...

A starting point would probably be to look at the code with KMO's original PRs without any of the following Asus or GPL changes, and see if that runs properly as a basepoint. If it does, then consider this as being "forked away from Asus" (like my OpenVPN code) and no longer merge subsequent changes by Asus unless they make clear sense in our context.
 
For @Mr Solis you can try this workaround until a fix is made:

Create this script with nano /jffs/scripts/qos-start
Code:
#!/bin/sh

. /usr/sbin/helper.sh

if [ "$1" = "init" ]; then
        pc_replace " mark 6 0x3f " " u32 0 0 " /tmp/qos
fi
Then run:
Code:
chmod 755 /jffs/scripts/qos-start
service "restart_qos;restart_firewall"
 
What we saw happening was exactly one of the issues Cedric was trying to solve 4 years ago. But Asus reverted his change.

 

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