QoS: only bandwidth limiter has effect

[vrapp]

OK, makes sense. So I tried this:

1. turned QoS off; initiated two downloads of the same file from the same server (my work machine), one by ftp, another by http. After a short while, they were downloading with the same average speed 300KB/s, approximately half of download bandwidth limit.

2. Turned on QoS, set it to Traditional. In user-defined priorities, under Download Bandwidth, specified "Low" with maximum bandwidth limit=20%. In user-defined QoS rules removed all rules except web surf, destination port=80, no"Transfered", priority=low.

With this in place, http download fits the rule, thus has to become low priority and obtain maximum 20% bandwidth. FTP download is unrestricted, so it should take 80%. Right?

I tried the same two downloads, and they soon stabilized at the same 300KB/s.

 

[Nullity]

OK, makes sense. So I tried this:

1. turned QoS off; initiated two downloads of the same file from the same server (my work machine), one by ftp, another by http. After a short while, they were downloading with the same average speed 300KB/s, approximately half of download bandwidth limit.

2. Turned on QoS, set it to Traditional. In user-defined priorities, under Download Bandwidth, specified "Low" with maximum bandwidth limit=20%. In user-defined QoS rules removed all rules except web surf, destination port=80, no"Transfered", priority=low.

View attachment 6550

View attachment 6552

With this in place, http download fits the rule, thus has to become low priority and obtain maximum 20% bandwidth. FTP download is unrestricted, so it should take 80%. Right?

I tried the same two downloads, and they soon stabilized at the same 300KB/s.

Sure seems like the QoS is broken, or at least using confusing terminology. Which version of AsusWRT are you running?
Why would it say "maximum" if it does not actually mean maximum... ?



Are you sure that you set QoS connection bitrate to below your real-world download bitrate? That is an absolute requirement.

PS - If you want to see how this QoS/traffic-shaping scenerio should function, see this pfSense forum post where I tested a similar scenerio: https://forum.pfsense.org/index.php?topic=90512.msg505122#msg505122
Pay attention to the "qTEST1" and "qTEST2" queues. They share all available bandwidth proportionally (1Kbit vs 6Kbit, so 1:6), which is exactly how your download test should have behaved (except it would be 80% vs 20%).

 

[vrapp]

> Which version of AsusWRT are you running?

Merlin's latest firmware. But before that I also tried Asus native one, the latest, with the same results (followed by the trouble to get back to Merlin, because of the new compliance efforts)

> Are you sure that you set QoS connection bitrate to below your real-world download bitrate? That is an absolute requirement.

Yes, positive.

Of course, I did read toastman's tutorial etc etc. But, as I understand, Asus effort in creating "adaptive" mode is to make QoS user-friendly, so the general user is not required to read toastman's article, and is not required even to lower the bandwidth. Once he has indicated what's important to him by shuffling nice colorful sliders, the rest is on Asus - same as he does not care about fine tuning fuel injection in his car, and does not have to read tutorials in order to expect good fuel economy. There's no reason it should be much different here, that's what the computers are for.

The QoS page even has radio button "automatic"; if not, recommends to set the bandwidth based on speedtest, and further has default=0: "Get the bandwidth information from ISP or go to Speedtest to check bandwidth; The default is 0, which means unlimited bandwidth"

Presumably, whatever clever fine-tuning is necessary, is supposed to occur under the hood. After all, if the method requires to set the bandwidth to 0.85 of the real, it's probably no big deal for the page to calculate that product once the user entered the real bandwidth from speedtest.

 

[Nullity]

> Which version of AsusWRT are you running?

Merlin's latest firmware. But before that I also tried Asus native one, the latest, with the same results (followed by the trouble to get back to Merlin, because of the new compliance efforts)

> Are you sure that you set QoS connection bitrate to below your real-world download bitrate? That is an absolute requirement.

Yes, positive.

Of course, I did read toastman's tutorial etc etc. But, as I understand, Asus effort in creating "adaptive" mode is to make QoS user-friendly, so the general user is not required to read toastman's article, and is not required even to lower the bandwidth. Once he has indicated what's important to him by shuffling nice colorful sliders, the rest is on Asus - same as he does not care about fine tuning fuel injection in his car, and does not have to read tutorials in order to expect good fuel economy. There's no reason it should be much different here, that's what the computers are for.

The QoS page even has radio button "automatic"; if not, recommends to set the bandwidth based on speedtest, and further has default=0: "Get the bandwidth information from ISP or go to Speedtest to check bandwidth; The default is 0, which means unlimited bandwidth"

Presumably, whatever clever fine-tuning is necessary, is supposed to occur under the hood. After all, if the method requires to set the bandwidth to 0.85 of the real, it's probably no big deal for the page to calculate that product once the user entered the real bandwidth from speedtest.

Sure, QoS should be much easier to setup, but it isn't... I understand your reasoning why it should be easier, but that does not change the fact that QoS tech is not yet as sophisticated as you would want.

The primary improvement that the Asus Adaptive QoS offers (as I understand it) is that it makes the classification of traffic easier, nothing more.


The only router firmware I know of that automagically adjusts the connection's QoS-configured bitrate is Gargoyle. I dunno how well it actually works.

 

[vrapp]

> QoS tech is not yet as sophisticated as you would want.

My whole point is that perhaps it's in fact very clever and very sophisticated, only it does not wok at all - and maybe because of some very trivial oversight. In my own programs I occasionally may comment out big block of code in order to narrow down some tricky problem, and once the problem is found, I forget to uncomment, and release it to the users (the company, not public). Sure, QC is supposed to catch something like that, but we don't know how good QC is in Asus. If adaptive QoS had some effect, but not as good as one might hope, it would be one thing; but the compete absence of any effect whatsoever hints in the direction of some trivial oversight. And from others' feedback, it looks like it's happening in some models, but not in others.

 

[sfx2000]

Sure seems like the QoS is broken, or at least using confusing terminology. Which version of AsusWRT are you running?

Remember - in QoS, think about committed bandwidth and priority - so a fairly unloaded system, even the lowest priority will likely get decent performance - as the higher priority Queues are either empty, or lightly loaded.

It's when things get congested and and loaded up, that the QoS really comes into play, and there, it's fairly effective.

 

[Nullity]

> QoS tech is not yet as sophisticated as you would want.

My whole point is that perhaps it's in fact very clever and very sophisticated, only it does not wok at all - and maybe because of some very trivial oversight. In my own programs I occasionally may comment out big block of code in order to narrow down some tricky problem, and once the problem is found, I forget to uncomment, and release it to the users (the company, not public). Sure, QC is supposed to catch something like that, but we don't know how good QC is in Asus. If adaptive QoS had some effect, but not as good as one might hope, it would be one thing; but the compete absence of any effect whatsoever hints in the direction of some trivial oversight. And from others' feedback, it looks like it's happening in some models, but not in others.

AFAIK, AsusWRT completely relies on Linux's traffic-shaping capabilities by issuing "tc" & "iptables" commands, so you could run something like "tc qdisc" via SSH to list the traffic-shaping queues and their configuration.


If you could run your test again but instead upload 2 files, it would help to narrow down where the problem may be. It is possible that only the download is broken.

 

[Nullity]

Remember - in QoS, think about committed bandwidth and priority - so a fairly unloaded system, even the lowest priority will likely get decent performance - as the higher priority Queues are either empty, or lightly loaded.

It's when things get congested and and loaded up, that the QoS really comes into play, and there, it's fairly effective.

Yeah. QoS only becomes useful as the network buffers/queues begin to fill.

vrapp's test fully saturated his download bitrate, and QoS made no difference.

 

[sfx2000]

vrapp's test fully saturated his download bitrate, and QoS made no difference.

I'm not so sure about that - testing QoS can be very challenging to say the least - what would probably help improve the test is put many clients on, doing the web traffic, and then start the download session via FTP, and the web traffic shouldn't be impacted.

Need to throw a lot of traffic at the classifiers and scheduler for QoS to really shine...

 

[sfx2000]

AFAIK, AsusWRT completely relies on Linux's traffic-shaping capabilities by issuing "tc" & "iptables" commands, so you could run something like "tc qdisc" via SSH to list the traffic-shaping queues and their configuration.

It's not quite so simple - AsusWRT also includes BWDPI and CTF as configurable options, and they both impact the conntrack state stable - and as closed source black boxes, there are times where the behavior might not be the same as what one would expect with just netfilter in the kernel (iptables is part of netfilter).

And that's where going into netfilter directly, if ctf and bwdpi are enabled, can actually have a negative impact, as they assume they're driving the bus. Or just disable them (and their benefits), and drive the bus directly, which for some, like having more direct control, might be a preferred approach.

One of the reasons why I shifted platforms to something that I have a bit more control of, but that's out of scope for this discussion.

As for AsusWRT, as long as the Max Bandwidth is defined (max*85 percent is what I hear is good), the default adaptive QoS settings actually work pretty well, even with ctf being true, from what I hear... but that means giving up some control by leaving iptables alone... but that's with understanding that the traffic and application flows from WAN to LAN, and LAN to LAN are complicated by these two black boxes.

I think some would appreciate better documentation on what those two magical black boxes do, as they're not very well documented now, and as such, it complicates understanding of what is already a tough item for many to grasp, as QoS is a non-obvious thing it seems.

 

[Nullity]

I'm not so sure about that - testing QoS can be very challenging to say the least - what would probably help improve the test is put many clients on, doing the web traffic, and then start the download session via FTP, and the web traffic shouldn't be impacted.

Need to throw a lot of traffic at the classifiers and scheduler for QoS to really shine...

I'd increase the number of clients/streams/flows later, and keep initial tests as simple as possible. For now, the only requirement is a minimum total ingress bitrate and two downloads with different bandwidth allocations.

 

[sfx2000]

I'd increase the number of clients/streams/flows later, and keep initial tests as simple as possible. For now, the only requirement is a minimum total ingress bitrate and two downloads with different bandwidth allocations.

Two application flows is pretty trivial for even the simplest classifier/scheduler...

 

[sfx2000]

And for those that are PDF adverse, or don't want to read thru a lot of stuff - here's another nutshell explanation of QoS from an alternate source...

So to really evaluate QoS in an objective manner, one has to saturate the classifier with many connections, and the scheduler with many different application flows..

 

[sfx2000]

AsusWRT, with the bolted on BWDPI and CTF - it does an ok job, considering that many of their devices are RAM limited with regards to the number of clients.

Remember - with NAT, we have to maintain state for each client, and application flow/connection, and that's where Asus approach is one approach compared to what Linux can do alone with netfilter

This perhaps is why their recent devices bumped up from 256MB of RAM to 512MB, along with turning up the CPU clock (classifier/scheduler) and the Memory speed (tracking state tables).

It really was to improve the customer experience. The WiFi stuff, in some ways, is extra credit, as most AC clients are 2*2:2 SU at best, but we still see improvement in performance (if not stability).

The challenge is bug-mashing - and there's one board member (@kvic ) that's been digging into that... he's not banging on Asus specifically, but he's doing it because he cares...

 

[Nullity]

Two application flows is pretty trivial for even the simplest classifier/scheduler...

and if a QoS implementation cannot even properly shape just 2 flows... there is a problem.

There's no need to add complexity to vrapp's tests if even the simplest test fails. Hopefully we can keep this thread as simple as possible.

 

[sfx2000]

and if a QoS implementation cannot even properly shape just 2 flows... there is a problem.

Amen - and there @vrapp testing seem to prove that point, eh?

His testing shows that it works in that context, even in a subjective perspective.

 

[sfx2000]

there is a problem.

And perhaps that's the complexity of QoS - it's opposite of what most folks would view it.

I don't pretend to fully grok it - schedulers and classifiers are the subject of many PhD papers...

And that underlies the challenges that even MU-MIMO has... and MU is very sensitive to this, and that needs coordination with the Router's SoC, not just the WiFi chip on the AP..

 

[Haggster]

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.

I've checked this now and set my download cap to 76mbit/s, which is 80% of my 95.x-mbit/s real-world maximum speed. I've checked the bufferbloat several times with both settings: The difference in latency is around 1-2ms, 3ms at most, meaning that I gain 1-3ms better latency when sacrificing 19mbit/s of my total bandwidth limit.

Is the DSLReports speed/bufferbloat test accurate? In that case I'd rather leave my cap set to a few kbit/s below my real-life maximum speed. If the difference in latency was, say, 10ms or more, I would consider sacrificing 20% of my bandwidth, but with such a tiny difference, I just don't see this as a good trade-off.

 

[Nullity]

I've checked this now and set my download cap to 76mbit/s, which is 80% of my 95.x-mbit/s real-world maximum speed. I've checked the bufferbloat several times with both settings: The difference in latency is around 1-2ms, 3ms at most, meaning that I gain 1-3ms better latency when sacrificing 19mbit/s of my total bandwidth limit.

Is the DSLReports speed/bufferbloat test accurate? In that case I'd rather leave my cap set to a few kbit/s below my real-life maximum speed. If the difference in latency was, say, 10ms or more, I would consider sacrificing 20% of my bandwidth, but with such a tiny difference, I just don't see this as a good trade-off.

Are you talking about download or upload.

Though, be aware your ISP (download) or your modem (upload) may not be suffering from bufferbloat. DOCSIS 3.1 (IIRC) even includes an AQM like CoDel in the standard itself, which I assume many cable internet customers will have soonish if not already.

 

[sfx2000]

Is the DSLReports speed/bufferbloat test accurate? In that case I'd rather leave my cap set to a few kbit/s below my real-life maximum speed. If the difference in latency was, say, 10ms or more, I would consider sacrificing 20% of my bandwidth, but with such a tiny difference, I just don't see this as a good trade-off.

It's overrated - once above 100Mbit/Sec connections, Bufferbloat is a non-issue...

https://fasterdata.es.net/network-tuning/buffer-bloat/