Adaptive QOS and higher buffer bloat - AC1900P

  • ATTENTION! As of November 1, 2020, you are not able to reply to threads 6 months after the thread is opened if there are more than 500 posts in the thread.
    Threads will not be locked, so posts may still be edited by their authors.
    Just start a new thread on the topic to post if you get an error message when trying to reply to a thread.

hifiwifi

Regular Contributor
Been playing with the Adaptive QoS feature on my newish AC1900P, which wasn't available on my old N66U. With adaptive QoS on, I'm seeing upload buffer bloat from 800->1000ms. When I use the manual settings in "traditional QoS" mode, it stays 20-100ms (in the "green" using dslreports speedtest). I assume the adaptive QoS does some sort of packet analyzing which might slow some things down, but that seems pretty dramatic. FWIW, I have a 768K upstream connection. I had been using .55 as the upstream limiter on the N66U. Also, when I plug those values in manually with adaptive QoS on, I still get the high buffer bloat; it's only when I go back to "traditional QoS" that it goes away. Is this a big deal?
 

CooCooCaChoo

Senior Member
Probably adaptive QoS kicking downloads in the nuts. Which is a good thing because you don't want downloads/file transfers to hog all the bandwidth or have priority over other things like gaming, voip, web browsing, etc.
 

RussellInCincinnati

Senior Member
Been playing with the Adaptive QoS feature on my newish AC1900P, which wasn't available on my old N66U. With adaptive QoS on, I'm seeing upload buffer bloat from 800->1000ms. When I use the manual settings in "traditional QoS" mode, it stays 20-100ms (in the "green" using dslreports speedtest). I assume the adaptive QoS does some sort of packet analyzing which might slow some things down, but that seems pretty dramatic. FWIW, I have a 768K upstream connection. I had been using .55 as the upstream limiter on the N66U. Also, when I plug those values in manually with adaptive QoS on, I still get the high buffer bloat; it's only when I go back to "traditional QoS" that it goes away. Is this a big deal?
RMerlin has noted (and it maches my own experience) that traditional QOS is more likely to work perfectly than adaptive QOS to pretty much eliminate bufferbloat without cutting significantly into peak transfer speeds.
 

hifiwifi

Regular Contributor
Thanks for replies. I should have searched a little harder. New to the "adaptive" thing and wanted to know if that was normal.
 

hifiwifi

Regular Contributor
Follow up....If I have already set the MTU value at the router level using ping tests for fragmentation, do I stlll need to enable 'WAN packet overhead" in the QoS settings?
 

Brent S. Smithline

New Around Here
This page http://www.dslreports.com is pure garbage, I really do not understand why people blindly trust lies and if you want to test your BufferBloat, install PingPlotter 5 and buy the Pro version and install this script FreshJR Adaptive QOS, this is the best script that exists for QoS.
Thanks have used PingPlotter since it first came out to help resolve issues on a given route. This is a great tool. Will have to take a look at the FreshJR Adaptive QoS script. The thing is I am getting old so looking at this from a KISS point of view. DSLreports may not be the best way if you are trying to solve an issue on a given route, however until I find a better on-line site to run a BufferBloat test I am going to use that as a benchmark. Just wish everyone would get on board with RFC 8289 and the other work that has added to this RFC and we would not even be talking about this. Same old thing follow the money.... RFC 8289 is free...
 

RMerlin

Asuswrt-Merlin dev
Thanks have used PingPlotter since it first came out to help resolve issues on a given route. This is a great tool. Will have to take a look at the FreshJR Adaptive QoS script. The thing is I am getting old so looking at this from a KISS point of view. DSLreports may not be the best way if you are trying to solve an issue on a given route, however until I find a better on-line site to run a BufferBloat test I am going to use that as a benchmark. Just wish everyone would get on board with RFC 8289 and the other work that has added to this RFC and we would not even be talking about this. Same old thing follow the money.... RFC 8289 is free...
Biggest hurdle is that the majority of home routers are based on old Linux kernel, which lack codel or fq_codel support. Asuswrt-Merlin and Tomato are rare exceptions, since somebody managed to backport fq_codel to the 2.6.36 kernel, however it's not working 100%, as that would require driver support from the network interfaces as well.
 

FreshJR

Very Senior Member
This page http://www.dslreports.com is pure lie
install PingPlotter 5
Dslreports is not a lie, it get identified as "Web Surfing"
PingPlotter is most likely identified as "Net Control"

The reason results differ is because PingPlotters "Net Control" packets will always have a higher priority than Speedtest's "Web Surfing // File Downloads" packets.

With dslreports, both its bulk download & ping packets are in the same "priority level" so it gives a better representation of actual scheduler performance.

"PingPlotter" will always have "aritficially" boosted results.

It matches what user @CooCooCaChoo was trying to explain.

Probably adaptive QoS kicking downloads in the nuts. Which is a good thing because you don't want downloads/file transfers to hog all the bandwidth or have priority over other things like gaming, voip, web browsing, etc.
----

Personally, adaptive works fine for me, but on some router / particular configurations have reported poor performance for unknown reasons.
 
Last edited:

Similar threads

Sign Up For SNBForums Daily Digest

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