[Bloat] Flow queuing performance (was: Re: [tsvwg] New Version Notification for draft-baker-tsvwg-aqm-recommendation-00.txt)

[Jim Gettys <jg@freedesktop.org>]

[-- Attachment #1: Type: text/plain, Size: 2182 bytes --]

To begin with, I tend to use the term 'flow queuing' to distinguish what
we're doing with classic "fair queuing", which is overbound in most
people's minds, and some of what we do is "unfair" by some metrics.

Secondly, an extremely important factoid about why we got so excited about
fq_codel (which is really DRR, in term derived from SFQ, combined with
CoDel along with detecting thin vs. thick flows) is its performance:

If my memory serves me correctly, Eric Dumazet has bench marked fq_codel,
when running on a modern x86 processor with modern NIC's only takes a few
percent of one x86 core at a 10gE rate.  And we get higher total bandwidth
over the link as a result.  Eric, please correct me if I'm wrong, but you
did say I could quote you!

Similarly, Dave Taht reports when using fq_codel on CeroWrt (a 600mhz MIPS
commodity home router), while the cost of running the fq_codel algorithm is
visible in the performance traces, it's well down the list of what
functions in Linux are taking the CPU time on that architecture, with huge
latency benefits.

As a result, at the last Linux Plumber's Conference in August, there was
general consensus that we could replace PFIFO_FAST as the default qdisc in
Linux, awaiting just our confidence that fq_codel (or something very
similar) was mature enough for such a step.

These two results demonstrated that on current general purpose
architectures, an algorithm such as fq_codel is really do-able for the edge
of the Internet.

That is not the same statement as saying you can turn on existing
implementations of various other fair queuing algorithms in existing big
routers or not; just that on general purpose processors we know we can do
with these algorithms immediately.

I think we all need to reset our expectations from the 1990's where we took
away the impression that SFQ/DRR etc were too expensive for deployment:
today's general purpose systems are very different than those we had in
that era, now often dominated by cache misses more than anything else.
 Everything we think we know about performance needs to be revisited in the
light of modern architectures.
             Best regards,
                    - JIm

[-- Attachment #2: Type: text/html, Size: 2377 bytes --]