From: richard <richard@pacdat.net>
To: "Dave Täht" <d@taht.net>
Cc: esr@thyrsus.com, bloat@lists.bufferbloat.net
Subject: Re: [Bloat] First draft of complete "Bufferbloat And You" enclosed.
Date: Sat, 05 Feb 2011 17:29:37 -0800 [thread overview]
Message-ID: <1296955777.32487.42.camel@amd.pacdat.net> (raw)
In-Reply-To: <8739o2i115.fsf@cruithne.co.teklibre.org>
Hi Dave
I saw the animations but need to ask to use them as there is no CC on
the site there and I have ads on my Digital-Rag site
I'm sorry - not an artist :(
On Sat, 2011-02-05 at 15:12 -0700, Dave Täht wrote:
> richard <richard@pacdat.net> writes:
>
> > I like your vehicle analogy but I think today's network-using public can
> > relate better to a real-world situation in the internet so I've put
> > together my own article on the problem. I'd already started the article
> > last week and finally got to finish it today.
> > http://digital-rag.com/article.php/Buffer-Bloat-Packet-Loss
>
> Wondeful! That's 3 non-jg pieces in a row that "get" it, and explain
> specific bits of it well.
>
> There are three excellent animations of how TCP/IP actually works here:
>
> http://www.kehlet.cx/articles/99.html
>
> Perhaps that would help your piece somewhat.
>
> I keep hoping that someone graphically talented will show up that can do
> animations similar to those above, that clearly illustrate
> bufferbloat. Anyone? Anyone know anyone?
>
> Another analogy that was kicked around yesterday on the #bufferbloat irc
> channel was the plumbing one - where more and more stuff is poured into
> a boiling kettle (a still perhaps) until it overflows, or explodes.
>
> Here's a title of a piece that *I* daren't write:
>
> “Draino for the Intertubes”
>
>
> I've struggled mightily to explain bufferbloat to so many people. For
> example I spent 3 hours talking with an artist that understood protools
> - and thought the internet was all slaved to a master clock.
>
If you believe the telcos, it was (and still should be) as that was the
way things like T1s and T3s and ATM all worked.
> I'm very glad to see y'all helping out. There's still lots left to do,
> not just in communication but in actually getting some work done on both
> the easy and hard engineering problems.
>
I'm not a programmer any more - last major "bare metal" programming I
did was on an IBM 360 in assembler.
Today I'm mostly a sysadmin and systems designer and programmer manager,
but I'm doing a lot of streaming video, which is why I'm interested so
much in the buffer bloat.
> But staying on the communication front:
>
> If a little kid asked you, in a small thin voice,
>
> “Why is the internet slow today?”
>
> How would you explain it?
>
> How'd you explain it to a doctor? A lawyer? Your mom? Your boss?
strangely enough - this has come up with me recently. I think I
passed :)
>
> As it happens I have studio time this weekend, if anyone is into script
> writing I can fake up a few voices. I have two ideas that I might be
> able to fit into 2 minutes each, but kind of have to tear myself away
> from email to work on...
>
> > It could have some more technical terms (latency for example) added to
> > it but I limited it to the concept of window and ACK for now.
> >
>
> This, though dated, is a good reference on latency.
>
> http://rescomp.stanford.edu/~cheshire/rants/Latency.html
>
yes - that's a good one
> A modernized one would be great... There was some good stuff on one of
> the audio lists/web sites that I saw, I'll look for it.
>
I'll think about it.
> Audio guys *get* latency. So do the real time guys. Few others.
>
So do video people - try to explain to a bunch of ageing "eagleholics"
that there is a good reason why the audio and video from two cameras in
the same eagle nest are out of sync by minutes by the time they've gone
through the internet a couple of times and various server systems that
are otherwise supposed to be identical, on the way to being viewed by
them on a web page side by side.
> > It takes the content of a recent ad from a local ISP and talks about
> > what is actually going on "under the hood"
>
> Lots of public confusion to counter. The nice thing is - we have
> mitigations that *work*. What do they have?
>
>
talk to you soon
richard
>
--
Richard C. Pitt Pacific Data Capture
rcpitt@pacdat.net 604-644-9265
http://digital-rag.com www.pacdat.net
PGP Fingerprint: FCEF 167D 151B 64C4 3333 57F0 4F18 AF98 9F59 DD73
next prev parent reply other threads:[~2011-02-06 1:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-05 13:23 Eric Raymond
2011-02-05 13:42 ` Jim Gettys
2011-02-05 15:12 ` Dave Täht
2011-02-05 15:46 ` Dave Täht
2011-02-06 13:37 ` Eric Raymond
2011-02-05 17:56 ` richard
2011-02-05 19:48 ` richard
2011-02-05 22:12 ` Dave Täht
2011-02-06 1:29 ` richard [this message]
2011-02-06 2:35 ` Dave Täht
2011-02-06 2:50 ` richard
2011-02-08 15:17 ` Justin McCann
2011-02-08 18:18 ` Eric Raymond
2011-02-08 18:31 ` richard
2011-02-08 18:50 ` Bill Sommerfeld
2011-02-09 15:50 ` Eric Raymond
2011-02-08 20:10 ` Sean Conner
2011-02-09 4:24 ` Justin McCann
2011-02-10 14:55 ` Jim Gettys
2011-02-10 17:50 ` Dave Täht
2011-02-08 19:43 ` Juliusz Chroboczek
2011-02-08 19:52 ` richard
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
List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1296955777.32487.42.camel@amd.pacdat.net \
--to=richard@pacdat.net \
--cc=bloat@lists.bufferbloat.net \
--cc=d@taht.net \
--cc=esr@thyrsus.com \
/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