QoS: only bandwidth limiter has effect

[vrapp]

I was wondering why the multitude of QoS modes on my AC68 does not seem to have any noticeable effect, and why whenever someone's phone begins synchronization with the cloud, it brings everyone else's browsing to the knees.

Here's what I did:

On iphone I initiated continuous download using the app "Network Multimeter" . The multimeter showed pretty stable sustained download speed close to the maximum.
On the laptop. I ran ping 8.8.8.8 -t and observed the ping
Then on the router I tried different modes of QoS - adaptive, traditional, and bandwidth limiter.

Result:
In all modes except bandwidth limiter, the ping fluctuated between 150 and 300ms. Changing from one mode to another did not have any effect. Giving the iphone low priority in traditional one did not have any effect. Giving web surfing low priority in adaptive mode did not have any effect. Neither did changing the discipline. With these two modes, no change in parameters had any effect at all.

With bandwidth limiter, setting the download limit for iphone 4.7Mb/s (with the maximum unlimited speed being 5.5), immediately dropped the ping on the laptop from 200-300ms to 20-30ms, practically the same as if the iphone was idle. I then tried the upload on iphone, and saw the same result. Increasing the limit from 4.7 by 0.1 had very visible effect on the ping, i.e. it increased accordingly. It was clear that this mode does work - unlike the others.

I should note that with traditional mode, one of the things I did was I assigned the iphone the lowest priority, and specifying maximum bandwidth limit for the lowest priority as 80% - which, as I understand, should have been equivalent to specifying lower limit in Bandwidth Limiter mode (even lower than 4.7). But it had no effect.

So, given the drastic improvement brought by the bandwidth limiter, I wonder if it's possible that something simply does not work at all in traditional and adaptive mode, so all the efforts to specify their parameters, including recent implementation of disciplines, are simply moot.

 

[jrmwvu04]

Just wanted to add that I had the same results and thoughts. I assumed that perhaps I configured it wrong or just simply didn't understand it, both of which are still quite possibly true. But since setting up the bandwidth limiter achieved what I wanted, I didn't look into it any further.

 

[bodean]

I was wondering why the multitude of QoS modes on my AC68 does not seem to have any noticeable effect, and why whenever someone's phone begins synchronization with the cloud, it brings everyone else's browsing to the knees.

Here's what I did:

On iphone I initiated continuous download using the app "Network Multimeter" . The multimeter showed pretty stable sustained download speed close to the maximum.
On the laptop. I ran ping 8.8.8.8 -t and observed the ping
Then on the router I tried different modes of QoS - adaptive, traditional, and bandwidth limiter.

Result:
In all modes except bandwidth limiter, the ping fluctuated between 150 and 300ms. Changing from one mode to another did not have any effect. Giving the iphone low priority in traditional one did not have any effect. Giving web surfing low priority in adaptive mode did not have any effect. Neither did changing the discipline. With these two modes, no change in parameters had any effect at all.

With bandwidth limiter, setting the download limit for iphone 4.7Mb/s (with the maximum unlimited speed being 5.5), immediately dropped the ping on the laptop from 200-300ms to 20-30ms, practically the same as if the iphone was idle. I then tried the upload on iphone, and saw the same result. Increasing the limit from 4.7 by 0.1 had very visible effect on the ping, i.e. it increased accordingly. It was clear that this mode does work - unlike the others.

I should note that with traditional mode, one of the things I did was I assigned the iphone the lowest priority, and specifying maximum bandwidth limit for the lowest priority as 80% - which, as I understand, should have been equivalent to specifying lower limit in Bandwidth Limiter mode (even lower than 4.7). But it had no effect.

So, given the drastic improvement brought by the bandwidth limiter, I wonder if it's possible that something simply does not work at all in traditional and adaptive mode, so all the efforts to specify their parameters, including recent implementation of disciplines, are simply moot.

What FW are you running?

 

[vrapp]

What FW are you running?

380.59

 

[el pescador]

bandwidth limiter works for me.
i pick selected devices...usually laptop to test and the ps4.

checking dspreports its fine....mainly on sfq....codel and fq_codel arent quite as good.

Merlin has stated this though

 

[Haggster]

Hi, I was curious and have just tried exactly what you described:

- a constant ping from my phone to 8.8.8.8 (which is between 48 and 57 ms)
- then I maxed out my connection (download and upload) via speedtest from my laptop, connected via 5GHz wifi

I was not able to see any fluctuation in ping times on my phone.

I'm using Adaptive QoS with 94down, 18up as my limits and my connection is rated 100down/20up.

Even though you are using an AC68 and I'm using an AC87, the implementation (i.e. the code) of the QoS should be indentical, so that's strange. I'm also using 380.59.

 

[vrapp]

- a constant ping from my phone to 8.8.8.8 (which is between 48 and 57 ms)
- then I maxed out my connection (download and upload) via speedtest from my laptop, connected via 5GHz wifi

I was not able to see any fluctuation in ping times on my phone.

Very interesting. Let's make sure that this is indeed caused by QoS rather than by some other factor.

1. If you disable QoS at all, does the ping on the phone change when you max out the connection on the laptop?
2. Does it change if you change the parameters of QoS, for example, if you increase the priority of the download, or if you specify higher bandwidth limits than you really have?

 

[Haggster]

First of all sorry for the weeks long delay in my reply... haven't seen the notification until now and recently I don't log on here that often.

Very interesting. Let's make sure that this is indeed caused by QoS rather than by some other factor.

1. If you disable QoS at all, does the ping on the phone change when you max out the connection on the laptop?
2. Does it change if you change the parameters of QoS, for example, if you increase the priority of the download, or if you specify higher bandwidth limits than you really have?

1. the ping from the phone times out in those cases, i.e. not all of the pings arrive when I try that
2. yes, the current bandwidth limit that I've set is the optimal one. I even get worse results if I "reserve" too much bandwidth by e.g. capping it at 80% of what my line is capable off - doing this is a common advice when setting up QoS but it's an advice I'd rather not follow, after all my testing. The best results are achieved though capping it *just* *below* what the line is capable of in real-life, which is measured through various speed-tests at different times. By "just below" I mean something like 1mbit/s below.

 

[Nullity]

Disregard this post and see my post below.

It seems to be a common complaint that Traditional & Adaptive QoS have either no rate-limiting capabilities or an undependable implementation of rate-limiting and instead only really allows prioritization (or de-prioritization) of traffic. Meaning you cannot assign a bitrate ceiling to traffic, you can only assign different priorities.

The Bandwidth Limiter seems to have explicitly added the "bitrate ceiling" (rate-limiting) capability.


It's kinda disappointing, but the inconsistency of AsusWRT's QoS/traffic-shaping ultimately caused me to use another device/OS as my router. QoS is already hard enough to learn & properly configure when everything is working properly...

 

[Haggster]

It seems to be a common complaint that Traditional & Adaptive QoS have either no rate-limiting capabilities or an undependable implementation of rate-limiting and instead only really allows prioritization (or de-prioritization) of traffic. Meaning you cannot assign a bitrate ceiling to traffic, you can only assign different priorities.

The Bandwidth Limiter seems to have explicitly added the "bitrate ceiling" (rate-limiting) capability.


It's kinda disappointing, but the inconsistency of AsusWRT's QoS/traffic-shaping ultimately caused me to use another device/OS as my router. QoS is already hard enough to learn & properly configure when everything is working properly...

...but it's working for me

so, in order to avoid any confusion: You are saying that Adaptive QoS does not cap the bandwidth at the rate which the user sets as the maximum? I.e. that if you have a 100mbits/s line and you set "maximum download" to 80mbps/s, that it will use 100mbit/s anyway? (same with the upload)

I can assign a bitrate ceiling to my traffic, downstream and upstream, in Adaptive QoS - and it works. Every single time.

That being said, I do remember that in one firmware version from last year, the settings were ignored when choosing the custom prioritization option instead of one of the default "steaming"/"gaming"/"web" settings. But at that time I just went for one of the latter and with the next firmware version the problem was gone as well.

It seems one cannot really say that this is broken or that it works - it really seems to depend on the specific device. I only have an RT-AC87 and never had any other router, so I assume that it's broken on other models but not on this one. Then again... people sometimes report the weirdest problems which they can seemingly reproduce every single time even after a clean re-flash, while others can try as hard as they want to reproduce this without being successful.

 

[Nullity]

...but it's working for me

so, in order to avoid any confusion: You are saying that Adaptive QoS does not cap the bandwidth at the rate which the user sets as the maximum? I.e. that if you have a 100mbits/s line and you set "maximum download" to 80mbps/s, that it will use 100mbit/s anyway? (same with the upload)

I can assign a bitrate ceiling to my traffic, downstream and upstream, in Adaptive QoS - and it works. Every single time.

That being said, I do remember that in one firmware version from last year, the settings were ignored when choosing the custom prioritization option instead of one of the default "steaming"/"gaming"/"web" settings. But at that time I just went for one of the latter and with the next firmware version the problem was gone as well.

It seems one cannot really say that this is broken or that it works - it really seems to depend on the specific device. I only have an RT-AC87 and never had any other router, so I assume that it's broken on other models but not on this one. Then again... people sometimes report the weirdest problems which they can seemingly reproduce every single time even after a clean re-flash, while others can try as hard as they want to reproduce this without being successful.

Yeah... my post does not seem to answer anything. I should have read OP's post more carefully. Let me try again. Also, let's assume AsusWRT's QoS is functioning properly, just to simplify.



AsusWRT's Traditional & Adaptive QoS cannot rate-limit individual types of traffic, only the interface/connection. This means that any type of traffic can fully saturate whatever connection bitrate you configured in the QoS settings. Bufferbloat occurs whenever a connection is saturated (assuming the device uses no AQM like CoDel/fq_codel or RED). All traffic suffers when the connection is saturated.

The Bandwidth Limiter introduces the capability to rate-limit individual traffic, meaning you can rate-limit DropBox to 4Mbit so that DropBox can never fully saturate your 8Mbit connection. DropBox can saturate it's particular queue, but it will not fully saturate the connection, which means all other traffic will not be experiencing bufferbloat.

That is why OP gets a better ping when using Bandwidth Limiters.

 

[RMerlin]

I haven't tested it recently because TQOS is broken on most routers, but back when I tested it, the way it was working was that a low priority client would use your full bandwidth UNLESS you had a higher priority connection. I was able to test this by running an FTP session as the same time as an HTTP download, and setting FTP to a low priority. The FTP would use my full bandwidth, but once the HTTP download start, it would drop to the very low value I had it set for.

This is how it should work. QOS is not a bandwidth limiter - that's why there's a separate configuration for that now. QOS is meant to ensure that low priority traffic don't interfere with high priority traffic. With that in mind, there's nothing wrong in low priority traffic running at full speed if nothing else needs that bandwidth at the moment.

 

[Haggster]

alright, that makes sense now. I haven't been able to test this, but I'd love to verify that it works. You'd need to start a skype session, while setting VoIP to the lowest priority within QoS and then start a speed-test that maxes out your connection while "file transfers", "other" and "web traffic" are set to the highest priority in QoS.

Then check if skype is dopping frames or stutters while the speed-test is running. Then do it the other way around with assigning the highest prio to VoIP (...)

But well... I guess the most important factor is to achieve that bufferbloat in general is being kept to a minimum while the connection is fully utilized. That way it will benefit all use-cases or types of traffic. And luckily that can be done via using the overall-bandwidth capping.

 

[Nullity]

alright, that makes sense now. I haven't been able to test this, but I'd love to verify that it works. You'd need to start a skype session, while setting VoIP to the lowest priority within QoS and then start a speed-test that maxes out your connection while "file transfers", "other" and "web traffic" are set to the highest priority in QoS.

Then check if skype is dopping frames or stutters while the speed-test is running. Then do it the other way around with assigning the highest prio to VoIP (...)

But well... I guess the most important factor is to achieve that bufferbloat in general is being kept to a minimum while the connection is fully utilized. That way it will benefit all use-cases or types of traffic. And luckily that can be done via using the overall-bandwidth capping.

Are we talking about saturating upload, download, or perhaps both simultaneously?

Upload can kinda have successful QoS (from a latency perspective) during upload saturation, but download is different because of the much larger delays between your router requesting that a remote client slow their transmission (by dropping packets which triggers TCP's congestion avoidance) and the point that you begin receiving a slowed transfer rate.

The most common way to avoid latency problems on download (CoDel does not work here since buffering is actually happening upstream) is to pre-emptively rate-limit all download traffic so that there is enough headroom to allow for new traffic without hitting your max download bitrate (buffering delay begins to increase exponentially at ~80% link-saturation).
This is what toastman advises. See his great QoS Introduction post here for more information.

Depending on your needs, you may get good results by limiting the download bitrate to 95%, or if your network is very busy, perhaps with torrents, you may need to limit to 60% or lower. toastman runs QoS for hundreds of clients (in multiple appartment complexs he runs, IIRC) and uses something like 50% because people are constantly attempting to abuse the not-so-fast internet.

 

[vrapp]

The observation was that it looks like Adaptive QoS and Traditional QoS don't have any effect at all, and only Bandwidth Limiter does. I.e. any combination of traffic between several clients sees the same drop of responsiveness on each whether adaptive or traditional Qos is enabled or not, or what are the parameters of each, when another client initiates download.

That is contrary to Asus claim found at http://www.asus.com/support/FAQ/1010935/: "After applying the QoS rules (...) your web surfing would not be influenced by P2P"

and http://www.asus.com/support/FAQ/1010933/: "The Quality of Service (QoS) ensures the network's speed performance. The default rule sets online gaming and Web Surfing as the highest priority and are not influenced by P2P applications (peer-to-peer applications such as BitTorrent)."

Assuming that latency to the game server is good enough indicator of whether it's affected or not, with QoS enabled, the ping to the server should not be changing when another workstation (or even the same one) initiates a download.

Accordingly, Asus article saying that "If you want to prioritize specific network applications and network devices, select your preferred priority from the User-defined QoS rules.", means that if I prioritize network device A, it should be unaffected by a download started at device B.

All that is actually happening with bandwidth limiter, but two other modes have no effect at all.

 

[Nullity]

The observation was that it looks like Adaptive QoS and Traditional QoS don't have any effect at all, and only Bandwidth Limiter does. I.e. any combination of traffic between several clients sees the same drop of responsiveness on each whether adaptive or traditional Qos is enabled or not, or what are the parameters of each, when another client initiates download.

That is contrary to Asus claim found at http://www.asus.com/support/FAQ/1010935/: "After applying the QoS rules (...) your web surfing would not be influenced by P2P"

and http://www.asus.com/support/FAQ/1010933/: "The Quality of Service (QoS) ensures the network's speed performance. The default rule sets online gaming and Web Surfing as the highest priority and are not influenced by P2P applications (peer-to-peer applications such as BitTorrent)."

Assuming that latency to the game server is good enough indicator of whether it's affected or not, with QoS enabled, the ping to the server should not be changing when another workstation (or even the same one) initiates a download.

Accordingly, Asus article saying that "If you want to prioritize specific network applications and network devices, select your preferred priority from the User-defined QoS rules.", means that if I prioritize network device A, it should be unaffected by a download started at device B.

All that is actually happening with bandwidth limiter, but two other modes have no effect at all.

Adaptive & Traditional QoS do work, just not as you expect. Nothing is broken, it's just that the underlying tech has limitations when implemented so simplistically. If the GUI had more advanced features, it would very likely just cause more head-aches & confusion.

Proper configuration of QoS is not a simple task... but things like fq_codel & cake are making it easier.

 

[vrapp]

Adaptive & Traditional QoS do work, just not as you expect.

Can you elaborate how they work? so far I saw no scenario where turning them on or changing their parameters made web surfing unaffected by download (promised by Asus), or in fact changed anything at all. Can you show such scenario?

 

[Nullity]

Can you elaborate how they work? so far I saw no scenario where turning them on or changing their parameters made web surfing unaffected by download (promised by Asus), or in fact changed anything at all. Can you show such scenario?

RMerlin's scenerio is accurate.

Download traffic takes a while to react, so bandwidth (as averaged over a longer time-span) is reasonably easy to allocate & control (example: 20% for FTP and 80% for HTTP). The problem is latency. You cannot use 100% of your download bandwidth and expect new traffic to experience no latency increase.

If you want to know more, read toastman's QoS Tutorial that I linked above.

 

[vrapp]

You cannot use 100% of your download bandwidth and expect new traffic to experience no latency increase.

There's no question that the latency does increase somewhat, but there's very big distance from that to having no effect at all. Once again: can you show scenario where adaptive or traditional have any effect whatsoever, however small? You said they do work. How can we see it?

 

[Nullity]

There's no question that the latency does increase somewhat, but there's very big distance from that to having no effect at all. Once again: can you show scenario where adaptive or traditional have any effect whatsoever, however small? You said they do work. How can we see it?

I already referenced RMerlin's scenerio and I included a quick example, but I will try to flesh it out. For this example, we are referring to download (ingress) traffic only and we assume the remote sites we are downloading from are capable of transmitting at the bitrate we request.


Set FTP downloads to 20% and set HTTP downloads to 80%. Now begin to download a file from an FTP source while also downloading another file from an HTTP source so that both are downloading simultaneously. It should take a second or two to normalize, but eventually your FTP download should be using 20% of your bandwidth and the HTTP download should be using 80% of your bandwidth.

This is exactly what should happen. If you are needing latency guarantees on your download traffic, you need to use Bandwidth Limiters (or learn to manipulate the "tc" CLI command yourself) to create excess bandwidth headroom.