First Post!

[Dave Täht]

I've assembled a list of the bloated device drivers on just the gear I
have and can test against. It's at:

http://www.bufferbloat.net/projects/bloat/wiki/Bloated_Driver_List

I'd like to see people poking into the drivers they have available
either via source code analysis or via empirical means, and adding to
this list.

I was astonished at how easy it was to take a first pass at the
bufferbloat problem in the Linux source tree. All you have to do is look
for TX_RING or TX_QUEUE in the device's header files, and the parameters
in place leap out at you.

Any number bigger than one is suspect, and my working definition of
"truly bloated" is currently 32, based on the analysis performed in this
paper:

http://www.cs.clemson.edu/~jmarty/papers/PID1154937.pdf

So I'm trying to tackle the low hanging fruit by aiming at the drivers I
have, and can test, and trying the safest looking minimum value, and
trying to come up with better-than-adhoc testing tools to confirm the
results.

I took a first pass at two of the drivers in my stack and was really
pleased with the results. VOIP became feasible with the ath9k - still
not ideal as I ended up moving the bottleneck to the ethernet side and
the card in my laptop!

One hard thing about bufferbloat is as soon as you reduce it somewhere
on the path, it crops up elsewhere.

In helping getting bufferbloat.net up I've been distracted from this
work. I'm looking forward to others poking into the problem(s), and
coming up with a good way of getting patches out the door. 

Many of these patches are going to be *trivial*. Others, like coming up
with a good wireless qdisc, or adding more knobs to twist, or statistics
to gather - are going to require work! At the moment I'm open to ideas
as to how to get more patches out there, tested and accepted, and am
reluctant to go around forking trees.

While it is VERY important to improve latency, I strongly suspect that
patches reducing the dma tx ring to its ideal (1) will hurt peak
throughput. 

Finding reasonable compromises between latency and throughput would be
good.

What sorts of devices and OSes are y'all working on? It's extremely
important to be trying to work across all OSes and devices.

As for me... I primarily work on x86/64, arm, and mips based Linux
based systems the days, openwrt on the embedded side, ubuntu/redhat on
the server/side. I'm pretty google-able, but I note that for most of my
life I've been under gnarly NDAs and haven't been able to work in public
like this.

This is the first time, ever, I've got a "first post" on a mailing list
or web site, not that it matters to me. In keeping with first post
tradition, I was thinking of keeping this email entirely content-free,
but couldn't do that.


-- 
Dave Taht
http://nex-6.taht.net