To refine this, fq_codel creates per flow fairness, which doesn't necessarily equate to per host fairness, nor does it mean that any one connection will be guaranteed max performance, just fair (or better), based on whatever flows are active in-queue.
Largely incorrect, and a vast dumbing-down of SQM in general.
fq_codel's purpose is to ensure flow fairness. That's it. Only when combined with a rate limiter such as HTB does it employ the de-bloating results so well attributed to its incarnation. Independent of that, flow fairness is still being applied via 1024 FIFO queues and is still smoothing traffic flow regardless of bandwidth utilization.
As for applicable use cases, "very slow DSL" is very much the prime example, but improvements can be seen just as well across other mediums, be they cable, fiber, etc. Innate latency may be lower on those mediums, minimizing the round-trip effects of de-bloating those links, yes, but as long as the link speed delta across interfaces remains larger than a 5x or so sum (ie. a 1Gb/1Gb/s LAN egressing to a typical 300/20 cable line or a 200/200 fiber line), you'll tend to see quite a improvement with fq_codel plus a rate limiter included. If you are simply lucky enough to just "buy more bandwidth", then that's a great out, but as I've mentioned before, a good mass of end-users globally are not in that situation. In the US, particularly, the national average of download/upload is nowhere near a value that couldn't at least be moderately to significantly helped by fairness-flow queuing, on any WAN medium, irrespective of whether the link is being saturated. fq_codel, in particular, builds its effectiveness on a gradient curve. It's not saturation based.
Perhaps delve into some bufferbloat docs and educate on where the benefits really lie, and how best to apply SQM in use-cases where it's clearly warranted, which, even today, number way beyond "niche".
Last edited:
