What's new

ASUS rt-88u - Adaptive QoS not doing it's job (for Gaming)

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

tsur1

Occasional Visitor
Hello,

I've tested the router yesterday and was really underwhelmed by the adaptive QOS feature. (tries newest stock and merlin's FW, router was reset and configured from scratch after each switch)

Coming from a Linksys WRT1900ac, when gaming is still got ping spikes when windows was downloading some updates, or when uploading something to youtube.
Isn't the adaptive QOS there in order to prioritize gaming packets and throttle all other activities??

I'm really pissed off cause this router was advertised as "The router for gamers" :/

Should I just forget adaptive QoS and set up traditional QoS?
 
Hello,

I've tested the router yesterday and was really underwhelmed by the adaptive QOS feature. (tries newest stock and merlin's FW, router was reset and configured from scratch after each switch)

Coming from a Linksys WRT1900ac, when gaming is still got ping spikes when windows was downloading some updates, or when uploading something to youtube.
Isn't the adaptive QOS there in order to prioritize gaming packets and throttle all other activities??

I'm really pissed off cause this router was advertised as "The router for gamers" :/

Should I just forget adaptive QoS and set up traditional QoS?


Did you give your gaming device(s) the highest priority. Or did you just set Adaptive QOS to gaming mode and have equal priority for all devices?
 
Coming from a Linksys WRT1900ac, when gaming is still got ping spikes when windows was downloading some updates, or when uploading something to youtube.

The only issue with WRT1900ac's QoS is that it wasn't very, for lack of a better word, flexible - which is probably for the best there - it didn't manage many devices, but for those managed devices, it did a decent job...
 
Did you give your gaming device(s) the highest priority. Or did you just set Adaptive QOS to gaming mode and have equal priority for all devices?

That actually won't help. First the router gives priority by traffic class and then devices within that traffic class get bandwidth starting from highest to lowest priority.

So to elaborate a device set on with lowest priority watching YouTube will still have priority over a device set to highest priority playing a game if streaming is above gaming.

Now what is most likely is happening for you is that your game is not identified as gaming traffic and is getting last priority as per defaults (been there done that ). This makes adaptive qos perform worse than no qos.

There are ssh commands you can issue to change priority of unidentified traffic as Asus restricts that functionality out of the box.

If you run Merlins custom fireware I coded up a script to apply the modifications automatically, but if you run stock and don't mind issuing the commands manually on reboot or changing router settings, I don't see why it wouldn't work.

Check out my thread for all the info I have gathered if you would like to modify adaptive QOS yourself.

https://www.snbforums.com/threads/s...-category-unidentified-traffic-priority.36836

Maybe asus in the future will include the same functionality outta the box if it gets enough attention. Testing division really seems to drop the ball.

Not only can you change unidentified class priority, you can also designate minimum guaranteed bandwidth per class which is the best feature ever.
 
Last edited:
That actually won't help. First the router gives priority by traffic class and then devices within that traffic class get bandwidth starting from highest to lowest priority.

So to elaborate a device set on with lowest priority watching YouTube will still have priority over a device set to highest priority playing a game if streaming is above gaming.

Now what is most likely is happening for you is that your game is not identified as gaming traffic and is getting last priority as per defaults (been there done that ). This makes adaptive qos perform worse than no qos.

There are ssh commands you can issue to change priority of unidentified traffic as Asus restricts that functionality out of the box.

If you run Merlins custom fireware I coded up a script to apply the modifications automatically, but if you run stock and don't mind issuing the commands manually on reboot or changing router settings, I don't see why it wouldn't work.

Check out my thread for all the info I have gathered if you would like to modify adaptive QOS yourself.

https://www.snbforums.com/threads/s...-category-unidentified-traffic-priority.36836

Maybe asus in the future will include the same functionality outta the box if it gets enough attention. Testing division really seems to drop the ball.

Not only can you change unidentified class priority, you can also designate minimum guaranteed bandwidth per class which is the best feature ever.
I sent the junk router back to amazon.
The game I'm playing is Overwatch...
Asus seem to have dropped the ball if adaptive Qos can't identity gaming packets over other stuff...
Back to my WRT1900ac does exact the same thing as the Asus for 50% of the price (with much better Wifi).
Why can't anyone just make a router that gets everything right???
How hard is it to implement a working Qos feature??
 
How hard is it to implement a working Qos feature??

Very. Especially the "automatic" aspect of it. There are projects like codel/cake that try to simplify configuration and generic tech like "fair queueing" that are universally useful but ultimately a good QoS/traffic-shaping configuration requires the user to have a reasonable understanding of how TCP and other related aspects of networking work together (like MTU-sized packet's worst-case latency for a given bitrate).

Slight rant: I mean, QoS, for most users, is a strange request. Like asking that your car to also be efficient while hitting the redline. Users want to be able to use 100% of their connection while seeing no side-effects. The best QoS is simply to never use more than 50% of your connection, which is what internet backbones tend to do. Intelligent queueing is unneeded if there's practically no buffering/queueing.


If you are interested in a good introduction tutorial to QoS/traffic-shaping then this link is the best I've found: www.linksysinfo.org/index.php?threads/qos-tutorial.68795/
 
How hard is it to implement a working Qos feature??

Technically, it's impossible to do for a home router manufacturer, as QoS has to be implemented at BOTH ends of the bottleneck (which is your modem connection), not just one. So, QoS would need to also be implemented at your ISP, since they're the ones controlling what gets sent to you. Your home router has very little to say in that, all it can fully control is what gets uploaded.
 
Technically, it's impossible to do for a home router manufacturer, as QoS has to be implemented at BOTH ends of the bottleneck (which is your modem connection), not just one. So, QoS would need to also be implemented at your ISP, since they're the ones controlling what gets sent to you. Your home router has very little to say in that, all it can fully control is what gets uploaded.

And I concur - Quality of Service has a specific meaning in the architecture/standards oriented folks - what OP is asking for is actually not QoS, but effective Traffic Shaping - which is a quantifiable level of service to a specific client and/or service...

The SOHO vendors did the community a big wrong by calling Traffic Shaping as QoS, as they're related, but not the same thing...
 
Something weird I noticed when using either the Asus Dynamic Qos or the Sqm cake script on my WRT1900ac, both of them improve bufferbloating (as tested on dslreports(dot)com)
but they also cause the pppoE connection to disconnect (after a random period of time [30sec - 10minutes]) and the disconnects can be reproduced consistently when i have two "time sensitive" applications running" (for example Gaming on one PC and Live Streaming on another PC).

When i use the stock FW (on my Linksys WRT1900ac) without advanced Qos however i get bufferbloat but no disconnects.

So anything i try to make my gaming ping more stable fails :(

The only thing i could try to replace is my modem.
 
Something weird I noticed when using either the Asus Dynamic Qos or the Sqm cake script on my WRT1900ac, both of them improve bufferbloating (as tested on dslreports(dot)com)
but they also cause the pppoE connection to disconnect (after a random period of time [30sec - 10minutes]) and the disconnects can be reproduced consistently when i have two "time sensitive" applications running" (for example Gaming on one PC and Live Streaming on another PC).

Two different router's with different QoS implementations both caused PPPoE disconnects? That seems very unlikely.

Something else is likely responsible for your PPPoE problems.

Did you find anything useful in your logs?
 
Two different router's with different QoS implementations both caused PPPoE disconnects? That seems very unlikely.

Something else is likely responsible for your PPPoE problems.

Did you find anything useful in your logs?
These are the logs for the WRT1900ac using SQM if you could look over them I would be very grateful!

Edit: The site didn't let me insert the logs (something with security issue) so i've uploaded them to GitHub.

https://gist.github.com/anonymous/a477a38ccd080d53bc7e84e3c63253c5
 
The router is deliberately bouncing the pppoe link because it hasn't got a reply from its echo request's.

Mon Mar 13 12:36:10 2017 daemon.info pppd[3918]: No response to 5 echo-requests
Mon Mar 13 12:36:10 2017 daemon.notice pppd[3918]: Serial link appears to be disconnected.
Mon Mar 13 12:36:10 2017 daemon.info pppd[3918]: Connect time 34.6 minutes.


Whether that means there is genuine problem with the link, or just that your ISP has decided not to respond, I don't know.

Edit: I see you have posted the same question on the LEDE Project Forum and gotten the same reply.
 
Last edited:
The router is deliberately bouncing the pppoe link because it hasn't got a reply from its echo request's.

Mon Mar 13 12:36:10 2017 daemon.info pppd[3918]: No response to 5 echo-requests
Mon Mar 13 12:36:10 2017 daemon.notice pppd[3918]: Serial link appears to be disconnected.
Mon Mar 13 12:36:10 2017 daemon.info pppd[3918]: Connect time 34.6 minutes.


Whether that means there is genuine problem with the link, or just that your ISP has decided not to respond, I don't know.
Will increasing the amount of echo-request maybe help in order for him to not drop the connection?
Of course this is a bandage solution for a bigger ISP or Modem related problem...
Could this be the reason why in the stock FW I do not get pppoe drops?
 
Sorry, I don't use PPPoE so I have no idea. From what I've read you could try changing the lcp-echo-failure and lcp-echo-interval values, if you can find where they are stored. Also check in the GUI's WAN configuration for things like "Idle Disconnect Time".
 
Sorry, I don't use PPPoE so I have no idea. From what I've read you could try changing the lcp-echo-failure and lcp-echo-interval values, if you can find where they are stored. Also check in the GUI's WAN configuration for things like "Idle Disconnect Time".
thanks i'll give it a try.
 
After sniffing around the internet there seems to be a bug with LuCi interface these are the default settings for the echo failure threshold (notice they are set to 0)

+LCP echo failure threshold - set to 0 which ignores failures (default)
+LCP echo interval - set to 5 (default)

however somehow the pppoe config ignores the value 0 and just uses the value 5 instead, this is what causes the pppoe disconnects...
Apparently setting the echo failure threshold to a large number (like 500) should resolve the issue.

This happens when you are on shirtty copper wiring (like me) that is prone to interference.

Do you guys have any idea what the default LCP echo failure threshold is set in Merlin's FW and the stock ASUS FW for the RT-88U?
Maybe they were set low as well causing the connection to drop?
I cannot check this because i sent the Asus back to Amazon....
 
I use a different firmware from Merlin's so this is just a guess...

But looking at this post and this source code it suggests that those two options are configurable under "Internet Detection". Also, it looks like they're stored in NVRAM at wan_ppp_echo_interval and wan_ppp_echo_failure.

I don't know what the default values are though. :(


Edit: Thinking a bit more about your original problem, i.e. disconnects with QOS enabled. I'm wondering whether it's because ICMP Echo's are generally regarded as low priority traffic that can be dropped in favour of other types of traffic. Maybe your QOS setup was giving so much priority to your gaming TCP/UDP traffic that it dropped too many Echo packets. Just a guess.
 
Last edited:
I use a different firmware from Merlin's so this is just a guess...

But looking at this post and this source code it suggests that those two options are configurable under "Internet Detection". Also, it looks like they're stored in NVRAM at wan_ppp_echo_interval and wan_ppp_echo_failure.

I don't know what the default values are though. :(


Edit: Thinking a bit more about your original problem, i.e. disconnects with QOS enabled. I'm wondering whether it's because ICMP Echo's are generally regarded as low priority traffic that can be dropped in favour of other types of traffic. Maybe your QOS setup was giving so much priority to your gaming TCP/UDP traffic that it dropped too many Echo packets. Just a guess.

PPP/LCP echo are different than ICMP echo though. The PPP daemon should never(?) drop PPP echo packets and I am unaware of an integrated QoS implementation that simultaneously & actively controls the PPP daemon along with TCP/IP's QoS.

Maybe though?
 
PPP/LCP echo are different than ICMP echo though. The PPP daemon should never(?) drop PPP echo packets and I am unaware of an integrated QoS implementation that simultaneously & actively controls the PPP daemon along with TCP/IP's QoS.

Maybe though?
Yes, you're right of course. It's not ICMP at all, it's just another LCP frame:
# If this option is given, pppd will send an LCP echo-request frame to
# the peer every n seconds. Under Linux, the echo-request is sent when
# no packets have been received from the peer for n seconds. Normally
# the peer should respond to the echo-request by sending an echo-reply.
# This option can be used with the lcp-echo-failure option to detect
# that the peer is no longer connected.
#lcp-echo-interval <n>

# If this option is given, pppd will presume the peer to be dead if n
# LCP echo-requests are sent without receiving a valid LCP echo-reply.
# If this happens, pppd will terminate the connection. Use of this
# option requires a non-zero value for the lcp-echo-interval parameter.
# This option can be used to enable pppd to terminate after the physical
# connection has been broken (e.g., the modem has hung up) in
# situations where no hardware modem control lines are available.
#lcp-echo-failure <n>
http://www.tldp.org/HOWTO/PPP-HOWTO/options.html
 

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