[Bloat] Slashdot!

Thu Mar 29 01:04:21 EDT 2012

On Wed, Mar 28, 2012 at 6:55 PM, Richard Brown <richard.e.brown at dartware.com
> wrote:

> It was good to see bufferbloat mentioned on slashdot...
>
>
> http://linux.slashdot.org/story/12/03/28/1439227/linux-33-making-a-dent-in-bufferbloat
>
> The OP made a fair query: has anyone benchmarked the bql and sfqred that
> are in the Linux 3.3 kernel?
>
>
OP was me, actually. *My* benchmarks are showing good results, but they are
more limited than I wanted them to be at this point. Also... well I'll get
to that in a second.

I had a subtle purpose in pursuing a little pr at this time, as what I
thought would happen was that the "Linux-3.3, now with BQL" 'story' would
get boiled down to 2-3 issues that weren't necessarily correct or primary.

It is normal in dealing with the press that a story needs to have a hook,
conflict and resolution, and only one or two new ideas that need to be
bridged to the unknowing reader. Dumping too much new stuff on a generic
reporter usually leads to bad results. Thankfully cringley genuinely 'gets
it', and can create a hook around anything. He tells a good story.

Within those constraints however is that pesky 'simplify the issue" problem
needed to get the core idea across to new audiences.

In observing the responses to cringley's and slashdot's article, exactly
what I feared has happened in several respects, and hasn't happened in
another.

They are:

0) "Linux-3.3, now with BQL! will solve all your networking problems, curl
your hair, and fix your sex life".

 :whew: headed that one off at the pass. A 'dent in the bloat'. That works
for me.

1) But spurring people into action to do what's doable, seems to be a
problem.

This does reinforce our overall deployment desire is that AQMs need to be
'on by default' as well as 'do no harm'.

And I do need to get back to my own efforts to find useful operating ranges
for what we got that can be on by default as well as 'do no harm'.

2) "Bufferbloat is a router problem only". We're failing here. Bloat is a
potential problem everywhere on the path. In my own environments these days
most of it is actually on my laptop, having fixed it on the routers I'm
fiddling with.

3) "Bufferbloat is only a linux problem." This is kind of a natural
association for a busy reader to make, and thus far we've avoided that
particular distillation of the meme. (the spin that I like is that "linux
is in the forefront of the battle against bufferbloat")

However it does point out the reverse problem, in that we do want people on
other operating systems and vendors to step up, and responses outside the
linux and ietf and academic community have been tepid. I would like very
much for there to be a good contact within all the big oses and vendors,
large and small, known to be paying attention to our efforts, with products
in the pipeline, all with fixes...

4) "Getting the story right in the first place". Still a fail. I have
alerts for new articles on bloat (several other people must have, too) and
nearly every one gets some core detail wrong. Sometimes I worry that the
meme will be subverted... take the recent cisco 'win the war against
buffering' campaign.

http://blogs.cisco.com/consumer/win-the-war-on-buffering/

sigh.

I made a comment. It's still awaiting moderation.

http://huchra.bufferbloat.net/~d/ciscosnark/ciscobloat2.png

I am just going to have to throw one of these routers into the testbed next
week and see what happens.

The responses were the typical spread of Slashdot responses: some funny,
> some clueless, some hostile, some way OT.
>
>
And none of them actually answered the question. This is the real problem,
as BQL provides a substrate for 'doing more low latency stuff on servers,
desktops and similar devices that have fixed sized tx rings'

But in communicating that - and in getting people to actually try it now
that it's more readily available, we're failing at present.

I'd like people within the major linux vendors to be fiddling with things
like sfq as potential *defaults* for desktops and servers, as they do
reduce network latencies still further, and to some extent, make down
stream packet loss less likely.

Our own jg gave a nice (and I thought, civil) response to the comment
> titled, "oversimplified PR noise ignores decade of research" and that
> started out,
>
> 'The bufferbloat "movement" infuriates me because it's light on science
> and heavy on publicity. It reminds me of my dad's story about his buddy who
> tried to make his car go faster by cutting a hole in the firewall
> underneath the gas petal so he could push it down further.'
> http://linux.slashdot.org/comments.pl?sid=2752225&cid=39498867
>
> This sounds about right: bufferbloat is well on its way to being treated
> seriously: first derided, then ignored, then accepted, then discovered...
>
>
I find gandhi comforting as well. Although I would substitute 'deployed'
for discovered, and gandhi was a far, far, far more patient person than I
am.

However in the past we've had several people also respond with hostility to
the PR effort we've given this issue. While our conversion rate among those
we've engaged with patience and data hovers at nearly 100%, and I hope that
that poster jg responded to does recheck his facts, I wish there was a way
to have a simple message that more immediately engaged people, particularly
those outside the computer science field.

People like: governments, managers, VCs and wall street. It really bothers
me that the economist hasn't run a story, although bloat did make a nyt
blog recently.

What I enjoy tremendously about modern media is that the web commentary can
provide additional insight, and analogies, that help map a new idea into
the contexts more minds operate in.

This analogy was hysterical:
https://plus.google.com/u/0/107942175615993706558/posts/YGEFa2iKTfw

Also good was:

"one of the only analogs [to how tcp operates] I can think of might be the
Blackbird stealth plane. Leaks like a sieve on the ground, spitting fuel
all over the place, because at altitude the seals expand so much that
they'd pop if it hadn't been designed to leak on the ground. Using gigantic
packet buffers would be like "fixing" a Blackbird so that it didn't leak on
the runway." - via slashdot

> Best,
>
> Rich
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>

-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20120328/35d8d665/attachment-0003.html>