From: Dave Taht <dave.taht@gmail.com>
To: bloat <bloat@lists.bufferbloat.net>, rbt@broughturner.com
Subject: [Bloat] bloat, 3G networks and switch behavior
Date: Tue, 8 Nov 2011 10:20:45 +0100 [thread overview]
Message-ID: <CAA93jw6wiRHHEkRtwc3zjHRYvm-hf9TY8uz_xjRxQsyYCreCvg@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2112 bytes --]
just stumbled across this old piece which links to some of the original
discussions around what has become called bufferbloat since, and also had
some links to papers I hadn't read.
http://blogs.broughturner.com/2009/10/is-att-wireless-data-congestion-selfinflicted.html
I'm curious as to who is monitoring 3G performance and latency to the
extent mentioned in this piece. Would love trendlines going back a couple
years....
this three parter was also pretty good:
http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/09/29/application-analysis-using-tcp-retransmissions-part-1.aspx
The conclusion shows what happens when you start overrunning buffers in a
high speed switch.
http://www.netcordia.com/community/blogs/terrys_blog/archive/2011/11/02/rethinking-interface-error-reports.aspx
Money quote on that:
"So I went back to the network assessment tools that I used and found that
the interfaces that were reported by my tools all had much higher
percentage errors, but had very low data rates. The high-throughput
interfaces that I found in the CLI output had error percentages that kept
them from appearing in the top few pages of interfaces with high error
percentages. While it is important to identify the high-percentage error
interfaces (which also had low traffic volumes), it was the high volume
interfaces that were impacting the applications that communicated across
the network backbone.
The interfaces that I was investigating had very high traffic volume, had
hundreds of thousands of errors, and were key interfaces in the
infrastructure. Now I had a clear understanding of my misconception in
looking for interface errors. I had always thought that I should look for
high percent errors. But here were key infrastructure interfaces that were
exhibiting high errors, but because of the total volume transiting the
interfcaes, their percentage was low, relative to other, low-volume
interfaces. How should I handle this case?"
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
[-- Attachment #2: Type: text/html, Size: 2648 bytes --]
reply other threads:[~2011-11-08 9:20 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
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=CAA93jw6wiRHHEkRtwc3zjHRYvm-hf9TY8uz_xjRxQsyYCreCvg@mail.gmail.com \
--to=dave.taht@gmail.com \
--cc=bloat@lists.bufferbloat.net \
--cc=rbt@broughturner.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