How to choose between Cake and Adaptive\Flex QoS

[Kingp1n]

I can only speak from my own experience.

I tried both CAKE & FlexQoS with my current speeds of 100/10mbps thru Comcast. What I noticed what works best for me in my environment, I prefer Flex over Cake.

When I used Cake (built-in one), I would lag (just slightly) when gaming.

When I use Flex, I never lag at all even when streaming, browsing, wireless gaming etc....so it's the reason why I prefer Flex. At least for me, it's one of the many (plenty of awesome add-on scripts out there) best add-on scripts with Asuswrt-Merlin firmware. Just look at my signature and you can clearly see everything I'm running! Best of luck!!!

 

[coxhaus]

In this day and age, I right size my link and use QOS for download hogs and not give my funds to an ISP that is already rich. One could purchase a router or two a year using your method or take the family out a few times.

Morris

You don't understand QoS. It is for upload not download. You have no idea what you are saying.

Your ISP has a way they send traffic and you can't change it. All you can try to do is smooth it by using buffers. You cannot control it. Buffers only work so far until it times out or your buffers fill.

 

[BreakingDad]

Less than 250mbps connection = cake
250-500 = flex
500+ = nothing

 

[Morris]

You don't understand QoS. It is for upload not download. You have no idea what you are saying.

Your ISP has a way they send traffic and you can't change it. All you can try to do is smooth it by using buffers. You cannot control it. Buffers only work so far until it times out or your buffers fill.

It's about TCP in both directions. The transmitter will not send if it dose not receive an ACK. When a QOS application either throws away an ACK, then the transmitter has to wait for it's timer to expire and then send the same packet. The QOS application can also delay ACKs to control flow and this works in any direction.

Morris

 

[coxhaus]

QoS is mostly used with UDP but TCP works. You are not changing what the ISP is sending. If you are at max pipe bandwidth and not sending ACKs the ISP is just going to retransmit over and over after the timer expires until they get a good ACK. You are wasting bandwidth in my mind for trying to control download. Upload works fine as you can control when you transmit files but on the download the ISP has their own method.
You are better off shutting down the connection on your end to save bandwidth.

 

[Morris]

QoS is mostly used with UDP but TCP works. You are not changing what the ISP is sending. If you are at max pipe bandwidth and not sending ACKs the ISP is just going to retransmit over and over after the timer expires until they get a good ACK. You are wasting bandwidth in my mind for trying to control download. Upload works fine as you can control when you transmit files but on the download the ISP has their own method.
You are better off shutting down the connection on your end to save bandwidth.bandwidth

What?
There are no ACKs in UDP. The application is responsible for integrity. To flow control a UDP stream QOS must drop packets.

 

[coxhaus]

Nowhere did I say UDP requires ACKs. I said QoS is used for UDP mostly. I said you were wasting bandwidth with what you were doing.

I know the difference between UDP and TCP.

 

[Morris]

Nowhere did I say UDP requires ACKs. I said QoS is used for UDP mostly. I said you were wasting bandwidth with what you were doing.

I know the difference between UDP and TCP.

QOS is for TCP and UDP.

One gives up a tiny amount of bandwidth with cake qos in exchange for reliable streaming and simplicity

 

[coxhaus]

It is much better if you just accept the fact, you cannot control the traffic flow from your ISP.

 

[Morris]

It is much better if you just accept the fact, you cannot control the traffic flow from your ISP.

I believe you can not control the flow from your ISP. Others do it all the time. Your lack of understanding of TCP, UDP and IP has been clearly demonstrated in this thread. You can go on with your false beliefs or do some reading and educate your self.

Morris

 

[coxhaus]

Go ahead and live in your make-believe world....it is all OK

 

[Wade Coxon]

Go ahead and live in your make-believe world....it is all OK

How do you explain then, the ability for QoS running in the Asus router, being able to eliminate bufferbloat when the WAN link is saturated with download data?

It is very easy to demonstrate that with QoS disabled, ping latency is increased by several tens of millisenconds vs an unloaded link. By enabling QoS and sacrificing around 10% of the total link capacity, the increase in latency drops to a negligable 2 to 5ms.

It is quite straightforward to control inbound/download TCP streams coming from the ISP using delayed ACKs. Dealing with bulk inbound UDP is less effective.

 

[Tech9]

being able to eliminate bufferbloat when the WAN link is saturated with download data?

The WAN link isn't saturated the way QoS is most often set with manual up/down values. You can achieve very similar results with simple traditional QoS on upload and bandwidth limiter to ~90% on download. It's not that obvious on home routers, because traditional QoS is often broken in Asuswrt and the hardware is rather slow (NAT acceleration tricks not applicable), but I can hit A+ bufferbloat scores with simpler methods on x86 hardware. So, the most important part is good ISP, second is avoiding line saturation conditions, third is fast packet processing hardware.

 

[Wade Coxon]

The WAN link isn't saturated the way QoS is most often set with manual up/down values. You can achieve very similar results with simple traditional QoS on upload and bandwidth limiter to ~90% on download.

That's my point though..... QoS is controlling the download link and is able to limit the download speeds to 90% of the line capacity.

coxhaus seems to be implying that QoS cannot control the download link utilisation, thus rendering QoS ineffective, which is demonstrably false.

 

[Tech9]

QoS is controlling the download link and is able to limit the download speeds to 90% of the line capacity.

Bandwidth limiter does 90% of the job. ISP's already apply QoS on their end. Delaying packets increases latency. I was following the QoS threads around with interest and they look to me like attempts to cut a tree with a swiss knife. Some try sharpening the knife, others different blade. Chainsaw is needed.

 

[dave14305]

In my small world of QoS, download is a lost cause because by the time the router has possession of the download packet, it has already traversed your ISP link whether you delay it, send it or drop it. It’s too late. You can only control what you send, not what you receive.

No one is worried about bufferbloat from the router toward the LAN.

 

[SomeWhereOverTheRainBow]

Cake does a lot more processing (nat, diffserv, wash, etc.) so I would expect it to use more CPU depending how it is configured.

Cake is usually recommended for lower bandwidth connections (less than 350 Mbps) because most consumer routers don’t have the processing power to shape at higher bandwidths. Cake requires HW acceleration to be disabled, so it is more easily constrained by CPU than Adaptive QoS.

But Cake is set-and-forget. So is Adaptive QoS. FlexQoS allows for never-ending tinkering that eats up your life, however.

FlexQoS all the way. I haven't seen a connection below 350 in almost 4 to 5 years.

 

[Wade Coxon]

Bandwidth limiter does 90% of the job. ISP's already apply QoS on their end. Delaying packets increases latency. I was following the QoS threads around with interest and they look to me like attempts to cut a tree with a swiss knife. Some try sharpening the knife, others different blade. Chainsaw is needed.

You'd be surprised I think. ISPs wouldn't apply QoS to individual data streams on their domestic customer links.

Delaying packets is exactly what you *want* to do to high volume flows. You want to slow them down to give the high-priority, latency-sensitive packets a space to "jump the queue".

In my small world of QoS, download is a lost cause because by the time the router has possession of the download packet, it has already traversed your ISP link whether you delay it, send it or drop it. It’s too late. You can only control what you send, not what you receive.

Yes, the already-received packet is a lost cause, but the trick is that you delay the next packet(s) so that the flow's speed is controlled. This is all fundamental to how QoS traffic limits work.

 

[coxhaus]

Yes, Dave14305 gets it.

 

[ColinTaylor]

Yes, the already-received packet is a lost cause, but the trick is that you delay the next packet(s) so that the flow's speed is controlled. This is all fundamental to how QoS traffic limits work.

Indeed. Consider that this is also similar to how TCP congestion control works. Also, people should not conflate QoS with buffer bloat.

@coxhaus seems to be under the impression that everything hitting your WAN interface is an uncontrolled avalanche of packets and therefore there's nothing you can do to change that. In reality, in a typical home network, relatively small amounts of data are being received at a time in response to a previous outgoing request or acknowledgement.

For example, if I download a 1GB file from the internet the source server doesn't just dump all that data on my WAN interface in one go. It sends the first bit and then waits until I tell it to send the next bit. Of course on a multiple user network trying to regulate all the incoming flows by adapting the outgoing requests/acknowledgements is far from easy. No one is saying it's perfect, but it's better than nothing.

I've spent years working with enterprise packet shapers and even there it's like herding cats, so don't expect miracles from consumer products.