optimizing for very small bandwidths with fq_codel better?
Dave Taht
dave.taht at gmail.com
Fri May 3 18:15:51 EDT 2013
On Fri, May 3, 2013 at 9:53 AM, Juliusz Chroboczek
<jch at pps.univ-paris-diderot.fr> wrote:
> tc qdisc add dev eth2 handle a root fq_codel flows 16 quantum 300
>
> What's the deal with the small quantum? Less than the MTU?
What this does is optimizes for interactive traffic over bulk.
fq_code, which is DRR based,l has a "new" flow idea in it, packets
that exceed a given quantum, never become new. So a 1500 byte packet
will be passed over 5 times before being delivered, while other flows
smaller than the quantum have a chance of being bumped into the new
flow queue and delivered most rapidly, depending on how "sparse" they
are.
It's a very old trick, going back as far as the venerable
wondershaper. (which did this, but badly, resulting in packet
re-ordering on some kinds of traffic)
I note that what I'm doing here (with the oddball filters) is an
experiment in progress. There are some comments in the tc code as to
where I'd like it to go...
We get very good results from fq_codel with a quantum this size at
4Mbits, but below that bandwidth things are dicy. Prior to this
experiment I'd been using a 3 tier shaper with htb, but that too had
trouble getting below 2Mbits, and relied on classification in order to
push background traffic into the background queue.
This is an attempt to be able to run at the line rate (whatever it is)
(or under a single htb), at 2Mbit or lower (384k, being the lowest).
It may be that we may also need to fiddle with fq_codel's target
and/or interval in order to work well at these rates.
For some detail as to what spurred this, please see the recent cablelabs report:
http://www.cablelabs.com/downloads/pubs/Active_Queue_Management_Algorithms_DOCSIS_3_0.pdf
Once you get above 4Mbit extensive fiddling with fq_codel's defaults
seems increasingly unnecessary.
We've also been fiddling with various forms a "pfq_codel", which tries
to emulate pfifo_fast behavior in similar ways.
>
> -- Juliusz
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
More information about the Bloat-devel
mailing list