What's new

[Asus RT-AC66U] - QOS - Download speeds throttled by upload bandwidth setting

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

NAT acceleration (CTF) is turned off. No problem when running VPN on Linux workstations as opposed to router. Somehow related to interaction of routers QOS and OpenVPN code.
From the amount of posts I've seen about VPN issues, it might be more to do with qos, it seems to be throttling based on your upload speed, since the upload pipe is very small it seems that adaptive qos is meant for a higher upload pipe rather than a smaller one, hmm, I suspect it's to do with the packet scheduler used by adaptive qos, a while back I sent an email to asus about using fq_codel or cake-fq_codel, for adaptive qos, purely for better responsiveness, and packet handling. I had a thought that if enough people asked asus for it they would be more likely to implement it and the required kernel and sdk to have support for it, could help with the VPN issue and people with low bandwidth connections.
 
From the amount of posts I've seen about VPN issues, it might be more to do with qos, it seems to be throttling based on your upload speed, since the upload pipe is very small it seems that adaptive qos is meant for a higher upload pipe rather than a smaller one

If I set my adaptive QOS upload bandwidth to 40 Mbps (same as my ISP download bandwidth) my downstream VPN speeds go up to near 40 Mbps even though my true ISP upload bandwidth is only about 5 Mbps. But falsely inflating the upstream QOS bandwidth setting breaks QOS of course because no upload bandwidth is kept in reserve.

Yeah, fq_codel would be nice. Merlin tried to implement it in traditional QOS, but I couldn't tell any difference with it turned on and upstream bufferbloat was still bad which is a problem when using VOIP during times of WAN bandwidth saturation (my only need for QOS to begin with).

As much as I love Merlin's firmware, I'm starting to wonder about IPFire or OpenSense on a box fast enough to handle all my VPN traffic. But that's another topic...
 
In that case the issue is qos, it's limited by your upload, which is something that's needs to be fixed makes me wonder what else other than VPN is affected.
 
Here's a Summary of testing Traditional and Adaptive QOS with and without router OpenVPN client.
RT-AC56U running 380.66_6
Router OpenVPN client connected to Torguard
5Mbps upstream/40Mbps downstream VDSL2 PPPoE WAN connection

Adaptive QOS (Manual Bandwidth) without VPN:
-Full WAN speeds up and downstream reduced by manual bandwith settings as expected
-Obi200 VOIP traffic categorized as gaming
-DSL Reports Bufferbloat "C" with no matter where throughput ceilings set (80-95%)
-QOS uses eth0 for upstream traffic shaping and br0 for downstream traffic shaping

Adaptive QOS (Manual Bandwidth) combined with router OpenVPN client:
-Upstream speeds are correct for manual bandwidth setting
-Downstream speeds are limited to upstream manual bandwidth setting
-tc class show dev eth0 and bro shows correct upstream and downstream ceilings based on manual bandwidth settings
- With OpenVPN client active, QOS only uses Eth0 for both upstream and downstream traffic which
explains why downstream speeds are limited to upstream manual bandwidth setting.
-VPN traffic, both upstream and downstream, are mis-categorized and flow through the upstream "web" category

Traditional QOS both without and with router OpenVPN client:
-Net control traffic flows through "highest" category as expected.
-All additional traffic flows through "Low" category. "Lowest", "Medium" and "High" prioritizations have no effect
-Full/normal upstream and downstream speed based on upstream downstream ceilings (80-95%) as expected
-Bufferbloat "A" for all queing disciplines

Understand that adaptive QOS is closed source and probably nothing can be done about the problems.

Previously, the traditional QOS traffic mis-categorization could be fixed by removing some iptables rules, but those rules dont seem to exist anymore so that workaround no longer fixes the problem. I will try to dig further on traditional QOS in hopes of getting traffic categorization working again. Have never looked at the rules or code before so any pointers would be welcome.

BTW, the OpenVPN client, when not running QOS, works perfectly for me including DNS and selective routing.
 
it might be closed source but asus should be able to retfiy it, in the next gpl
 
This is still an issue? I'm seeing this behavior on GT-AX6000 Merlin build 388.2_2_rog - About to use Nord software instead.
 
Yeah, having this problem with RT-AX56U, Merlin 388.2_2 and NordVPN. Took me ages to figure out the cause. For me, I have the issue with QoS on or off, adaptive, traditional, or bandwidth limit. Nothing makes any difference. Download limited to 60Mbps when it should be 500Mbps. Highly annoying. Is there literally no fix? Seems like madness.
 
Nothing makes any difference. Download limited to 60Mbps when it should be 500Mbps. Highly annoying. Is there literally no fix? Seems like madness.

Yea, yea, I'm getting there, lol. Madness. I'm not running any VPN for anything at the moment because yea, classification just goes kaput. And I'm currently running FlexQoS requiring lots of trial and error to setup.
 

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top