From: Jim Gettys <jg@freedesktop.org>
To: Nicolas KUHN <nicolas.kuhn@telecom-bretagne.eu>
Cc: bloat-ietf@lists.bufferbloat.net, "aqm@ietf.org" <aqm@ietf.org>
Subject: Re: [Bloat-ietf] [aqm] [FQ_CoDel] "Official" version
Date: Mon, 3 Feb 2014 10:57:45 -0500 [thread overview]
Message-ID: <CAGhGL2DThPrxM6cr_24VP796gjCO3BV=qp4wGK=D4WPjD-o36Q@mail.gmail.com> (raw)
In-Reply-To: <EBEF5C21-0B25-4D25-98C2-C8F66B8D3B52@telecom-bretagne.eu>
[-- Attachment #1: Type: text/plain, Size: 3459 bytes --]
On Mon, Feb 3, 2014 at 9:30 AM, Nicolas KUHN <
nicolas.kuhn@telecom-bretagne.eu> wrote:
> Dear all,
>
> We would like to test FQ_CoDel and we wonder which version to evaluate.
fq_codel has been in Linux since about Linux 3.5, IIRC. For casual
experiments, a current Linux distro will have it available at the
invocation of the "tc" command. But...
You should generally be testing the latest Linux release (not that I
think there has been much change in fq_codel, as demonstrated in:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/?id=refs%2Ftags%2Fv3.14-rc1&qt=grep&q=fq_codel
For serious bench marking getting results from an old system can make your
results easily invalid since there has been a large number of improvements
in Linux for bufferbloat everywhere over the last three years, and the
queue discipline is only part of the equation. For example, many ethernet
drivers in SOC's found in home routers may still lack even BQL support.
You should be testing the fq_codel queue discipline: while Dave Taht has
played with a number of variants on that theme, nothing to date has shown
itself (by testing) with enough better results to be worth merging upstream
into kernel.org. Pie finally entered kernel.org Linux a month or so ago.
Note that there a large number of "traps" for the unwary in this
benchmarking/testing business, into which multiple groups have come to bad
ends causing questionable results to confuse everyone. For example, the
details of the underlying device driver can matter a lot (actually,
hugely!), and netem has to be used with exquisite care just to name a
couple of the big traps.
Fundamentally, you need to realize that the queue discipline in Linux
(where you can apply aqm) does *not* have control of all of the buffering
in the system; device drivers and even the hardware itself can do
"interesting" things to you. And a bunch of changes have taken place in
the Linux TCP stack to remove unneeded buffering since around Linux 3.2.
At one point I think the list was up to a dozen or more significant
improvements in the Linux networking stack, independent of fq_codel.
We've come to learn that WiFi in particular needs a serious rewrite, and
before venturing far, you'd be wise to get in touch with us further. ATM,
the ath9k driver is least problematic, but even there, aggregation causes
large amounts of buffering (32 packets!).
Dave Taht and I tried to outline what you should be thinking about when
bench marking in:
http://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarking_Codel_and_FQ_Codel
Pretty much all of these issues apply to anything you do, not just fq_codel.
I think that page overs most of the problems though of course, Linux is a
moving target so I'm sure there will be future problems :-(.
> Does anyone know where we could get the "official" version / source code
> of FQ_CoDel ?
> (linux and/or NS2 if possible)
>
www.kernel.org for the source.
You can use git to see the exact revision history of the code.
I forget off hand where to find the simulation code... There is a link
somewhere in the bufferbloat/codel wiki
http://www.bufferbloat.net/projects/codel/wiki/Wiki
Help from people to get the wiki up to date gratefully appreciated!
Jim
> Thanks a lot,
>
> Kind regards,
>
> Nicolas
>
> _______________________________________________
> aqm mailing list
> aqm@ietf.org
> https://www.ietf.org/mailman/listinfo/aqm
>
[-- Attachment #2: Type: text/html, Size: 6710 bytes --]
next prev parent reply other threads:[~2014-02-03 15:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-03 14:30 [Bloat-ietf] " Nicolas KUHN
2014-02-03 15:57 ` Jim Gettys [this message]
2014-02-03 20:52 ` [Bloat-ietf] [aqm] " Dave Taht
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAGhGL2DThPrxM6cr_24VP796gjCO3BV=qp4wGK=D4WPjD-o36Q@mail.gmail.com' \
--to=jg@freedesktop.org \
--cc=aqm@ietf.org \
--cc=bloat-ietf@lists.bufferbloat.net \
--cc=nicolas.kuhn@telecom-bretagne.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox