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

[Veabers]

The problem that I am seeing is that if I turn QOS on the value set for the "Upload Bandwidth" is being used to throttle the download speeds.

If I set the Upload Bandwidth limit to my download limits I get the correct speeds.

Here is the contents of my /tmp/qos file:
https://gist.github.com/anonymous/e77bd8253acab7ca6dec

I forgot to mention that I am running the 376.49_5 firmware and that I did a complete wipe (turn off router, hold wps button down, turn on router, release wps button after 30 seconds)

 

[Scott Jacobs]

Interesting - I am seeing the same effect using the latest Merlin build 378.55 on an RT-AC87U - it looks to me like the upload bandwidth is being used for both up and down limits - the download limit entry field does not seem to have any impact whatsoever. Curiously with this level I do not have a /tmp/qos file - are these limits assigned to some nvram variable?

 

[gschlact]

Looks like it is still an issue here in mid-2016.
main Upload rate QoS is throttling / slowing downloads. I changed my number so both showed my Download speed, and immediately got the higher bandwidth for the Speedtest.net.
Firmware 380.59 Asus AC68u

gschlact

 

[RMerlin]

Looks like it is still an issue here in mid-2016.
main Upload rate QoS is throttling / slowing downloads. I changed my number so both showed my Download speed, and immediately got the higher bandwidth for the Speedtest.net.
Firmware 380.59 Asus AC68u

gschlact

Don't forget that when downloading, you have to upload ACK packets for every downloaded TCP packet. So limiting the upstream too severely WILL impact the downstream, as you might be preventing sending acknowledgement packets fast enough to keep the downstream flowing at full capacity.

 

[Chrysalis]

Guys obviously you need to make sure your upload speed limits are large enough to handle your ack packets. e.g. one cannot have a 100kbit upload limit on 100mbit download speeds.

 

[neatchee]

I can confirm that this is NOT an issue with throttled ACK.

I'm seeing this on my newly purchased RT-AC88U running Merlin 380.66_4
I was NOT seeing this on my RT-AC66U running the same version 0_o

My UL is set to 11Mbps, DL to 240Mbps. ACK has been given highest priority.
I cannot get inbound throughput faster than 11Mbps with "Traditional QoS"
Adaptive seems to work just fine, though?

This would appear to be an issue with iptables CONNMARK and TC.
Traditional QoS inbound packets are hitting the correct QOSO0 chain rule, but are being classified by TC using the default class for non-match packets (and since the default class is one of the UL classes, it is applying that limit)
Since adaptive does not use iptables CONNMARK, and uses only TC for all shaping, it does not suffer from this issue.

 

[Deleted member 48827]

Since adaptive does not use iptables CONNMARK, and uses only TC for all shaping, it does not suffer from this issue.

But it does happen with adaptive QOS on my RT-AC56U. This has been a nagging problem for a while up through firmware V. 380.66_4

Using Adaptive QOS (Manual bandwidth settings) combined with OpenVPN client setup on RT-AC56U, my OpenVPN downstream throughput is limited to the upstream adaptive QOS bandwidth setting.

Connection is PPPoE VDSL2 5/40 Mbps. I get 5Mbps OpenVPN downstream throughput with adaptive QOS turned on and 36 to 40 Mbps OpenVPN downstream throughput with Adaptive QOS turned off.

I need QOS for VOIP reliability, so have had to leave Router OpenVPN turned off and run VPN client software on each network host instead.

Since this is reported to be happening with the combination of Traditional or Adaptive QOS combined with OpenVPN I wonder where the problem is and if it's fixable?

 

[Vexira]

have you guys with adptive qos tried freshprincejr's script for bandwith allocation.

 

[Deleted member 48827]

have you guys with adptive qos tried freshprincejr's script for bandwith allocation.

I haven't tried it because I'm able to categorize my traffic well enough without it. I hadn't thought about it possibly being a fix for the throughput problem. I think I'll give it a try. Thanks for the suggestion.

 

[Deleted member 48827]

have you guys with adptive qos tried freshprincejr's script for bandwith allocation.

No joy. Tried the script and experimented with the script minimum bandwidth allocations. Unfortunately, both downstream and upstream VPN throughput are are still limited by the Adaptive QOS GUI manual upstream bandwidth setting.

 

[Eric Lieb]

when I enabled adaptive qos my speedtest.net tests got cut in half (set it to gaming but wasnt gaming at the time)...

 

[Vexira]

o

No joy. Tried the script and experimented with the script minimum bandwidth allocations. Unfortunately, both downstream and upstream VPN throughput are are still limited by the Adaptive QOS GUI manual upstream bandwidth setting.

odd i left it on defualt andd its fine for me i suspect its an issue for people with low upload seepds and high download, like when i was on an 8/1 adsl2+ connection, but now im on 100/40 (95/37) ipoe vdsl2
is it possible the qos packet scheduler causing the issue, just a theory, also did you test the script at default stettings, if all else fails looks like it has to be fixed by asus, though i would love to see it fixed.

 

[Deleted member 48827]

odd i left it on defualt andd its fine for me i suspect its an issue for people with low upload seepds and high download, like when i was on an 8/1 adsl2+ connection, but now im on 100/40 (95/37) ipoe vdsl2

What is the downstream throughput of your VPN traffic? With your upstream QOS set to near 37 Mbps, I would imagine your VPN traffic wouldn't do much better than that anyway because of the router cpu load.

If I turn off QOS, I can get close to 40Mbps VPN with my 5/40 connection but the cpu is hitting about 80% on my AC56U.

Still playing with this and trying to understand the script. I'll try the default script again. Looking at the QOS statistics page, my downstream VPN traffic looks to be categorized as upstream and still in the "Default" category. I expected the script to change the VPN traffic to the "Other" category. Maybe I didn't get it set up correctly.

 

[Vexira]

What is the downstream throughput of your VPN traffic? With your upstream QOS set to near 37 Mbps, I would imagine your VPN traffic wouldn't do much better than that anyway because of the router cpu load.

If I turn off QOS, I can get close to 40Mbps VPN with my 5/40 connection but the cpu is hitting about 80% on my AC56U.

Still playing with this and trying to understand the script. I'll try the default script again. Looking at the QOS statistics page, my downstream VPN traffic looks to be categorized as upstream and still in the "Default" category. I expected the script to change the VPN traffic to the "Other" category. Maybe I didn't get it set up correctly.

ive been looking at getting a vpn, but wth all the issue that ive been reading ive been holding off.

 

[Deleted member 48827]

ive been looking at getting a vpn, but wth all the issue that ive been reading ive been holding off.

Ah, OK, that explains why you are not seeing the problem. It's the combination of VPN and QOS that limits the speed to the QOS upstream bandwidth setting.

Adaptive QOS works fine until I turn on the VPN client and run VPN traffic through the router. My workaround has been to leave the router VPN client turned off and run VPN client software on each computer (three of them) which allows the router adaptive QOS to work properly. And that solution works except for the inconvenience of having to reconnect/disconnect VPN on each computer everytime they go in/out of standby.

 

[Vexira]

Ah, OK, that explains why you are not seeing the problem. It's the combination of VPN and QOS that limits the speed to the QOS upstream bandwidth setting.

Adaptive QOS works fine until I turn on the VPN client and run VPN traffic through the router. My workaround has been to leave the router VPN client turned off and run VPN client software on each computer (three of them) which allows the router adaptive QOS to work properly. And that solution works except for the inconvenience of having to reconnect/disconnect VPN on each computer everytime they go in/out of standby.

That to me sounds like a traffic classifaction issue, its not correctly detecting it, some thing that only asus can fix.

 

[Deleted member 48827]

That to me sounds like a traffic classifaction issue, its not correctly detecting it, some thing that only asus can fix.

Thanks. I'm inclined to agree. However, the problem is also being reported with the combination of traditional QOS and VPN (I've confirmed this), and traditional QOS is open-source AFAIK, so maybe the problem is outside of the closed-source adaptive QOS code?

 

[Vexira]

possible an issue in the sdk or kernel, a guess that it could be to do with nat accelration, but my best guess is with the routeres vpn implementation.

 

[Deleted member 48827]

possible an issue in the sdk or kernel, a guess that it could be to do with nat accelration, but my best guess is with the routeres vpn implementation.

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.

 

[Vexira]

The problem that I am seeing is that if I turn QOS on the value set for the "Upload Bandwidth" is being used to throttle the download speeds.

If I set the Upload Bandwidth limit to my download limits I get the correct speeds.

Here is the contents of my /tmp/qos file:
https://gist.github.com/anonymous/e77bd8253acab7ca6dec

I forgot to mention that I am running the 376.49_5 firmware and that I did a complete wipe (turn off router, hold wps button down, turn on router, release wps button after 30 seconds)

Have you tried upgrading to the latest firmware version?