[Bloat] debloat-testing tree rebased, some patches dropped

[Bloat] debloat-testing tree rebased, some patches dropped

[John W. Linville]

FYI...

I have rebased the wireless-testing tree on 2.6.39-rc1.  As previously
stated, I plan to track the -rc and final releases, rebasing on
each -rc1.  The rebase is a little ugly/painful, but it is a good
way to avoid building-up too much cruft in a tree that isn't going
to be pulled by Linus anyway.

I dropped the patches that were already present in 2.6.39-rc1, along
with the ones that had gotten reverted in debloat-testing already.
I also dropped Nathaniel's iwlwifi patches, as the iwlwifi/iwlegacy
split made preserving them a little awkward.  Maybe Nathaniel can
post revisions?

Anyway, that doesn't leave much -- a couple of ugly patches from Dave
and me, neither likely to make it upstream.  They are looking a bit
lonely in there...surely someone has some experimental stuff that
craves an audience of testers?

Let me know if there are problems!

John
-- 
John W. Linville		Someday the world will need a hero, and you
linville@tuxdriver.com			might be all we have.  Be ready.

Re: [Bloat] debloat-testing tree rebased, some patches dropped

[Dave Taht]

On Wed, Mar 30, 2011 at 3:11 PM, John W. Linville
<linville@tuxdriver.com> wrote:
> FYI...
>
> I have rebased the wireless-testing tree on 2.6.39-rc1.  As previously
> stated, I plan to track the -rc and final releases, rebasing on
> each -rc1.  The rebase is a little ugly/painful, but it is a good
> way to avoid building-up too much cruft in a tree that isn't going
> to be pulled by Linus anyway.
>
> I dropped the patches that were already present in 2.6.39-rc1, along
> with the ones that had gotten reverted in debloat-testing already.
> I also dropped Nathaniel's iwlwifi patches, as the iwlwifi/iwlegacy
> split made preserving them a little awkward.  Maybe Nathaniel can
> post revisions?
>
> Anyway, that doesn't leave much -- a couple of ugly patches from Dave
> and me, neither likely to make it upstream.  They are looking a bit
> lonely in there...surely someone has some experimental stuff that
> craves an audience of testers?

I'd like to point out that the really good patches (the ECN fix, SFB,
CHOKe) landed upstream so fast that a stay in debloat-testing was
almost not necessary.

Highest on my personal lists of "would likes":

1) I would certainly like to see the AQMs above thoroughly tested with
some new shaper scripts now that they are in the rc1 kernel!

(did those patches get backported into openwrt?)

As for moving further with debloat-testing:

JG will be back from Europe April 3rd-ish.

I'm traveling up the East Coast starting sunday, making stops at
gatech, washington, DC, Philly, Boston, and Illinois, before getting
to California in late April.

So I'm trying to assemble a build system (for multiple distros) that
works before hacking on kernels any more, personally. It's far better
to light up the new server (huchra) for 13 minutes than making my
laptop glow for 2 hours... but it's not quite there yet. Friday, I
hope? With a little help??

Technically I'm trying to get a grip on the "day in the life of a TCP
stream", to see where latencies are introduced across the stack.

Patches I'd love to see:

IWL patch

More work on instrumenting eBDP, Wireless, Ath9k, A USB wireless stick...

Support for per-device TCP algorithms.

TCP-FIT, anyone?

I was under the impression there were several other packet schedulers
in the works

and there was some iptables connection tracking work that seemed interesting


>
> Let me know if there are problems!
>
> John
> --
> John W. Linville                Someday the world will need a hero, and you
> linville@tuxdriver.com                  might be all we have.  Be ready.
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://the-edge.blogspot.com

Re: [Bloat] debloat-testing tree rebased, some patches dropped

[Eric Dumazet]

Le mercredi 30 mars 2011 à 16:06 -0400, Dave Taht a écrit :

> I was under the impression there were several other packet schedulers
> in the works
> 

Yep, QFQ missed linux-2.6.39 merge window.

It is ready and should land in linux-2.6.40

Re: [Bloat] debloat-testing tree rebased, some patches dropped

[Jonathan Morton]

On 30 Mar, 2011, at 11:06 pm, Dave Taht wrote:

> TCP-FIT, anyone?

Well, I know enough about it to be able to implement it, but are we allowed to?

I also measured some asymmetry between two of my machines, which led me to the Sun GEM driver.  The GEM is technically a GigE NIC, but in the machine I'm testing (a PowerBook G3) it has a 100base-TX PHY attached.  Regardless, the GEM driver in Linux sets the ring buffer to 128 entries for both RX and TX.  There is an obvious setting for 32 entries for TX.

The other machine has a VIA Rhine NIC, and the driver for that implies that the ring buffer has 16 entries but deliberately limits it to having only 10 entries in use.  The Responsiveness figures are much higher when all the traffic comes from the Rhine, compared to when any traffic comes from the GEM.

 - Jonathan