From: Dave Taht <dave.taht@gmail.com>
To: cerowrt-devel@lists.bufferbloat.net,
bloat-devel <bloat-devel@lists.bufferbloat.net>,
codel@lists.bufferbloat.net
Subject: 3.6.2 multiple codel testing (and odd behavior with tos = 0x20 on iwl?)
Date: Sat, 13 Oct 2012 14:14:08 -0700 [thread overview]
Message-ID: <CAA93jw6DD7yWia-FZZTUVezbcdFzTJu-ggd6fokeFcYUeudWJA@mail.gmail.com> (raw)
I have just put up my intended-for-some-major-testing 3.6.2 based
kernels for x86_64 ubuntu 12.4 here:
http://snapon.lab.bufferbloat.net/~cero1/deb/
There's only two out of tree patches left in it - one to preserve the
"dropped" statistic in fq_codel, the other to add the current ns2
model of codel in for direct comparison to the current linux codel.
The hope is, of course, to find the "one true codel", not to preserve
these different variants.
Those patches are at:
http://snapon.lab.bufferbloat.net/~cero1/deb/patches-3.6.2/
And a patched iproute2 tree to enable these experiments is on my github.
(again, the intent is not to preserve this codebase but to be able to
scientifically test against the same kernels the mildly different
algorithms)
I'm aware that there have been string of gro/ecn bugs fixed in the
3.7/net-next tree. But: most (all) of my testing is generally with
that feature turned off via ethtool, but that problem might bite
others.
If that or additional patches should be backported to 3.6.x before
firing up some test runs, please let me know/send patches soonest.
The hardware I've got for this upcoming test is broadcom tg3 and intel
e1000e based. I have precisely zero experience with the tg3, it
appears it has hardware multiple queues, which might be interesting if
I knew how to configure it...
...
it is my hope to move cerowrt as well to 3.6.x sometime in the next 6 weeks.
...
Also: I was looking over this as perhaps a blocker to fiddling with
Linux 3.6.2 for this...
https://bugzilla.kernel.org/show_bug.cgi?id=48601 (3.6.2 has eric
dumazet's routing bug fix in it now)
And given some reports Ive had of late about cerowrt on #bufferbloat,
perhaps we do have some issue with dealing with this tos marking/queue
on wifi, either in the iwl driver or in the kernel. I've certainly
seen some weirdness from the iwl in general. Fixing the iwl is not
exactly in my remit at present...
--
Dave Täht
Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html
reply other threads:[~2012-10-13 21:14 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=CAA93jw6DD7yWia-FZZTUVezbcdFzTJu-ggd6fokeFcYUeudWJA@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=bloat-devel@lists.bufferbloat.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
--cc=codel@lists.bufferbloat.net \
/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