From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa0-x232.google.com (mail-oa0-x232.google.com [IPv6:2607:f8b0:4003:c02::232]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id C58D7201253 for ; Mon, 3 Feb 2014 07:57:46 -0800 (PST) Received: by mail-oa0-f50.google.com with SMTP id n16so8291968oag.37 for ; Mon, 03 Feb 2014 07:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=xGpld1SGhMccuW1s6vQsYFSwyXGHUnooz2vMkQOz90I=; b=ACb+wLbDkoXqaCh003AKgy/sUltCxP/Xc3nfVdKOrQJybb0Cs3pUT7AjoXUZY5Eimo rQDvJalrHZrgSeoBkzAbpOkrmC6m4A2DBRdAP7ytPx8BqFcAc6YBUt7tgzDqQ5UGnJBw SfrGAAvOPPxBtohl+tD6MTdH01lONswoMDLgiXUQ26iFF2cQ2ugmrrr9u1oeL+TxwLeD pwVkA9TZB70CcNRQeBhHQkaZ/r8n9jwVadp20NHdcQTMUgf+XOSEqRP5HlfYwCt2V5Fe dZBL8ivKfO0dGy2LoGGDBVU2W0BdrUI37rSjnhsZwW28tROFKng6GfkxZ+QKX/+ifmNP mZFw== MIME-Version: 1.0 X-Received: by 10.182.247.68 with SMTP id yc4mr1117115obc.67.1391443065542; Mon, 03 Feb 2014 07:57:45 -0800 (PST) Sender: gettysjim@gmail.com Received: by 10.76.84.162 with HTTP; Mon, 3 Feb 2014 07:57:45 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Feb 2014 10:57:45 -0500 X-Google-Sender-Auth: rrLhFK-4MsSeVH0YmSWyt9Mcdfw Message-ID: From: Jim Gettys To: Nicolas KUHN Content-Type: multipart/alternative; boundary=089e015384d6a6169e04f1829525 Cc: bloat-ietf@lists.bufferbloat.net, "aqm@ietf.org" Subject: Re: [Bloat-ietf] [aqm] [FQ_CoDel] "Official" version X-BeenThere: bloat-ietf@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: IETF specific bufferbloat discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2014 15:57:47 -0000 --089e015384d6a6169e04f1829525 Content-Type: text/plain; charset=ISO-8859-1 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 > --089e015384d6a6169e04f1829525 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 3, 2014 at 9:30 AM, Nicolas KUHN <nicolas.k= uhn@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. =A0For casual e= xperiments, a current Linux distro will have it available at the invocation= of the "tc" command. =A0But...

You s= hould generally be testing the latest Linux release (not that I think there= has been much change in fq_codel, as demonstrated in:=A0https://git.kernel.org/cgit= /linux/kernel/git/torvalds/linux.git/log/?id=3Drefs%2Ftags%2Fv3.14-rc1&= qt=3Dgrep&q=3Dfq_codel

For serious bench marking gett= ing results from an old system can make your results easily invalid since t= here has been a large number of improvements in Linux for bufferbloat every= where over the last three years, and the queue discipline is only part of t= he equation. =A0For example, many ethernet drivers in SOC's found in ho= me routers may still lack even BQL support.

You should be testing the fq_c= odel 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 b= etter results to be worth merging upstream into kernel.org. =A0Pie finally entered ker= nel.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 resu= lts 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.=A0

Fundamentally, you need to rea= lize 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 ev= en the hardware itself can do "interesting" things to you. =A0And= a bunch of changes have taken place in the Linux TCP stack to remove unnee= ded buffering since around Linux 3.2. =A0At one point I think the list was = up to a dozen or more significant improvements =A0in the Linux networking s= tack, independent of fq_codel.

We've come to learn that W= iFi in particular needs a serious rewrite, and before venturing far, you= 9;d be wise to get in touch with us further. =A0ATM, the ath9k driver is le= ast problematic, but even there, aggregation causes large amounts of buffer= ing (32 packets!).

Dave Taht and I tried to outli= ne what you should be thinking about when bench marking in:

h= ttp://www.bufferbloat.net/projects/codel/wiki/Best_practices_for_benchmarki= ng_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 =A0though 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 / sour= ce code of FQ_CoDel ?
(linux and/or NS2 if possible)

www.kernel.org for the source.

You can us= e git to see the exact revision history of the code.

I forget off hand where to find the simulation code... =A0There is a link s= omewhere in the bufferbloat/codel wiki

http://www.bufferbloat.= net/projects/codel/wiki/Wiki

H= elp from people to get the wiki up to date gratefully appreciated!

Jim
<= div class=3D"gmail_default">

=

Thanks a lot,

Kind regards,

Nicolas

_______________________________________________
aqm mailing list
aqm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/aqm

--089e015384d6a6169e04f1829525--