Adaptive QoS - Questions

[Nullity]

So in a previous post you stated that Adaptive QoS isn't as good as another one, from your viewpoint what makes the newer version of QoS and the integration of Adaptive QoS as being subpar to the older version?

If anyone else wants to chime in on this as well that is fine.

That is not quite what I said but OK.

QoS is built upon the ability to predictably prioritize some traffic above another type. Do you really want the QoS "adapting" and making decisions you did not specifically define? Hell no, that would be unpredictable which is not acceptable to services that require certain throughput/latency guarantees.

So, standard QoS works just fine. Adaptive QoS is just marketing BS for those unwilling to properly configure QoS.

 

[RMerlin]

So, standard QoS works just fine. Adaptive QoS is just marketing BS for those unable to properly configure QoS.

Adaptive QoS is far more than just marketing BS. When the RT-AC87U was released, I remember mentionning on these forums that IMHO, the biggest feature the RT-AC87U brought was not its 4x4 or future MU-MIMO support, but everything related to Trend Micro's DPI engine, including Adaptive QoS.

Standard QoS is only able to classify traffic based on IP, MAC, port and amount of transferred data, and it requires you to disable NAT acceleration, which means those older MIPS-based routers are limited to about 150 Mbps.

Adaptive QoS uses DPI to classify traffic, meaning it can actually examine the type of traffic, but also the specific destination. That allows it to do a far more accurate classification than legacy port/IPbased classification. In addition to that, it can work with NAT acceleration enabled, which means you can reach well beyond 650 Mbps with Adaptive QoS enabled (that was the result I got when I benchmarked an RT-AC56U using it back when Asus first added it).

If you want to see how precise Trend Micro's DPI engine can get, turn on Apps Analysis on the Adaptive Bandwidth page, and expand the list of protocols detected on one of your computers. It's able, for example, to distinguish Youtube traffic out of the rest of the web traffic, meaning it can easily priorize your Youtube streaming.

Adaptive QoS is closer to L7-based QoS as used by some on Tomato, only with far, far more accurate rulesets than those outdated L7 filters, and requiring very little configuration.

So if only for its ability to work with CTF enabled, Adaptive QoS is superior to the old method by far and large.

 

[charlie2alpha]

Well, it's still not perfect. It fails to classify properly Skype traffic (ends up as "generic") and often fails with bitorrent too, although less often than some months ago. Despite this, since I switched to a VDSL2 line now I use it instead of the traditional one.

 

[Nullity]

Adaptive QoS is far more than just marketing BS. When the RT-AC87U was released, I remember mentionning on these forums that IMHO, the biggest feature the RT-AC87U brought was not its 4x4 or future MU-MIMO support, but everything related to Trend Micro's DPI engine, including Adaptive QoS.

Standard QoS is only able to classify traffic based on IP, MAC, port and amount of transferred data, and it requires you to disable NAT acceleration, which means those older MIPS-based routers are limited to about 150 Mbps.

Adaptive QoS uses DPI to classify traffic, meaning it can actually examine the type of traffic, but also the specific destination. That allows it to do a far more accurate classification than legacy port/IPbased classification. In addition to that, it can work with NAT acceleration enabled, which means you can reach well beyond 650 Mbps with Adaptive QoS enabled (that was the result I got when I benchmarked an RT-AC56U using it back when Asus first added it).

If you want to see how precise Trend Micro's DPI engine can get, turn on Apps Analysis on the Adaptive Bandwidth page, and expand the list of protocols detected on one of your computers. It's able, for example, to distinguish Youtube traffic out of the rest of the web traffic, meaning it can easily priorize your Youtube streaming.

Adaptive QoS is closer to L7-based QoS as used by some on Tomato, only with far, far more accurate rulesets than those outdated L7 filters, and requiring very little configuration.

So if only for its ability to work with CTF enabled, Adaptive QoS is superior to the old method by far and large.

Thanks for the info. Your posts are always welcomed.

AFAIK, the "adaptive QoS" closed-source and therefore unpredictable. My statement was overly biased against the casual user, which the Adaptive QoS is obviously meant for. I will admit I took the wrong perspective there. Adaptive QoS should most likely be encouraged to the majority.



My personal opinion though, is that too many assume QoS is a cure-all. That is why I push standard QoS, in a somewhat "all or nothing" mentality. To use QoS, you need to know what you want and the expected results. Adaptive QoS encourages people to think of QoS as an arbitrary solution, which it is definitely not.

 

[charlie2alpha]

The "Adaptive QoS" is indeed closed source and based on a third party's data but since it uses DPI it does not rely on known ports, originating IP address etc to classify traffic. That's its strength, like @RMerlin said.

Now, if you have a completely controlled network environment with no unknowns in the mix, perhaps the traditional QoS can be more effective, for example I run a torrent client on a specific box, so I can effectively classify that traffic much better than the DPI based QoS is able too. The majority of users of these SOHO routers don't have this kind of environments though so of course a more automated solution is more appropriate.

It's all about tradeoffs and different usage scenarios.

 

[kvic]

I hardly saturated my WAN bandwidth unless doing speedtest (or the recent vogue of buffer bloat test). So I never have any sort of QoS until very recently. I chose to turn on traditional QoS to trick the buffer bloat test and get a high score. lol.

For the traditional QoS, you also don't have to go with a fancy list of rules. Simply define a few highest priority rules e.g. for VoIP. That's it. It's KISS and light on resource. I always prefer my router to run a few more interesting and useful apps..

Merlin mentioned the merits of adaptive QoS. Here is my devil's voice.

Adaptive QoS consists of two parts. The kernel module and user space programs. By design, this won't be as efficient as traditional QoS from the perspective of resource use and run time efficiency. The first time I tried adaptive QoS, I saw tonnes of processes on top. That gave me an impression of very unprofessional implementation. Maybe that's the time I'm biased not to use anything DPI related. More recently I understood why so many processes. It's the lack of native pthread support on ASUSWRT (more info of how we discovered this in this thread).

Traditional QoS can be made to work with HW NAT if there is a will in Asus to do it. But I could understand why Asus chose the path of TrendMicro. Once properly optimised, that's the future for both average and power users. Especially when home network gets more complicated with Internet of Things.

 

[charlie2alpha]

LOL, I didn't even had to look at the other thread to realize immediately that the ancient uClibc causes the lack of pthread support. And for sure, Asus and any other vendor are using the SDK supplied from Broadcom. For some reason this reminds me how Mediatek treats their phone manufacturers, same exact tactics used there, closed source code and possibility of customization since that would brake the closed source components.

But anyway, we're going offtopic now. Adaptive QoS obviously requires more resources hence it's available only on newer ARM models. It requires more CPU power and RAM capacity both.

 

[kvic]

The uClibc version used on ARM is actually not ancient. Out of convenience most likely, native pthread support is not enabled. Also Broadcom supplied source codes of the toolchain to Asus (and Netgear), so they can enable pthread support. Can't you read between lines I'm advocating Asus to turn on native pthread on ARM?

 

[charlie2alpha]

The uClibc version used on ARM is actually not ancient. Out of convenience most likely, native pthread support is not enabled. Also Broadcom supplied source codes of the toolchain to Asus (and Netgear), so they can enable pthread support. Can't you read between lines I'm advocating Asus to turn on native pthread on ARM?

Hmm, perhaps they could enable it but I am not sure about the closed source code. In any case, you probably know as well as I not to hold our breaths over that happening.

 

[Haggster]

What would interest me is if anybody has ever benchmarked the TrendMicro Adaptive QoS against QCM's StreamBoost QoS. It's a very interesting technology, especially since it seems to be hardware-backed and it's actually collecting statistics on the individual user's usage before applying automatically adjusted QoS rules based on this. And StreamBoost is actually a bit older than TrendMicro's Adaptive QoS.

Anybody here who's got experience with both?

 

[Nullity]

What would interest me is if anybody has ever benchmarked the TrendMicro Adaptive QoS against QCM's StreamBoost QoS. It's a very interesting technology, especially since it seems to be hardware-backed and it's actually collecting statistics on the individual user's usage before applying automatically adjusted QoS rules based on this. And StreamBoost is actually a bit older than TrendMicro's Adaptive QoS.

Anybody here who's got experience with both?

StreamBoost incorporates a well-established, open-source AQM. CoDel makes sure that network buffers stay small, which lessens the need for QoS since network latency is improved for all traffic.

I dunno much about Adaptive QoS. Maybe they created something better than CoDel or HFSC but decided to stay humble and not publicize it...

Edit: Formatting

 

[charlie2alpha]

Well, with a minimal amount of digging you can see that the Adaptive QoS relies on the HTB packet scheduler, a simple "tc class show dev eth0" is enough. The actual DPI engine just marks the packets instead of custom iptables rules.

 

[kvic]

Well, with a minimal amount of digging you can see that the Adaptive QoS relies on the HTB packet scheduler, a simple "tc class show dev eth0" is enough. The actual DPI engine just marks the packets instead of custom iptables rules.

Apparently the meat is in the DPI engine doing the packet inspection and marking. Network scheduler is likely no need to be re-invented. What explains the user space processes for?

 

[kvic]

Hmm, perhaps they could enable it but I am not sure about the closed source code. In any case, you probably know as well as I not to hold our breaths over that happening.

A simple re-compilation of uClibc shall be sufficient. Applications already written with pthread APIs will benefit automatically without re-compilation. I would hedge most apps except those from pre-history years are written with pthread APIs. No reason for Asus not to enable native pthread once they realise their oversight..

 

[Mears148]

I would love to hear more about the Streamboost vs. Adaptive QoS comparison too but looking up info on the internet comes up lacking. In fact I have a Streamboost DLink DGL-5500 that I replaced with a ASUS RT-AC3100 and can honestly say that my streaming has suffered since the "upgrade". In my testing however, I have yet to witness Adaptive QoS even doing its job of throttling my slow 3Mbps/768Kbps Verizon DSL connection at home over the RT-AC3100. Due to this, I have not had success comparing the two at all. Streamboost is the most underutilized traffic shaping technology IMHO, and I really can't understand why. There is really only one advertised router that is supported by Qualcomm and it is the DLink DGL-5500 that I have, and that is ancient in computer time. Anyone else have insight on the Streamboost vs Adaptive QoS case? Has anyone gotten Adaptive QoS to throttle their down and upload speeds correctly on the new RT-AC3100/RT-AC88U? Thanks.

 

[Nullity]

Streamboost is known to employ CoDel, which is pretty cool.
Even DOCSIS 3.1 adds PIE, an AQM which decreases bufferbloat.
Asus' Adaptive QoS is mostly unknown.


Really, none of these bring any new technology. They simply take already established algorithms and mish-mash them together with some unknown proprietary BS.

HFSC together with (fq-)codel are about as good as you can get. AsusWRT-merlin defaults to (E)SFQ, iirc, but it includes HFSC.


Any traffic-shaping setup should be able to rate-limit. It is strange that so many report that AsusWRT will exceed the bitrate maximums people configure, as that means the most fundamental part of QoS/traffic-shaping is broken.

 

[got_milk]

HFSC together with (fq-)codel are about as good as you can get. AsusWRT-merlin defaults to (E)SFQ, iirc, but it includes HFSC..

Just curious why HFSC is better than HTB? IIRC, most fq-codel articles I've seen have recommended HTB over HFSC.

 

[Nullity]

Just curious why HFSC is better than HTB? IIRC, most fq-codel articles I've seen have recommended HTB over HFSC.

In practice, HTB (or CBQ) is probably just fine, but HFSC is a "fair queueing" algorithm with the best, mathematically provable guarantees on latency/bandwidth, and it allows you to do an interesting, but mostly misused and misunderstood thing referred to as "decoupling bandwidth and delay".

That last capability seems to only be really useful in commercial or enterprise, but I thought I would include it since HFSC was the first to introduce the feature.