From: David Collier-Brown <davec-b@rogers.com>
To: bloat@lists.bufferbloat.net
Subject: [Bloat] Representing normal vs bloated systems in diagrams (was: A long-delayed thought on "three bars")
Date: Sat, 04 May 2013 16:09:07 -0400 [thread overview]
Message-ID: <51856AE3.3070401@rogers.com> (raw)
In-Reply-To: <mailman.7754.1367496260.1742.bloat@lists.bufferbloat.net>
[-- Attachment #1: Type: text/plain, Size: 2607 bytes --]
Quite some time ago, Dave Taht wondered about how one would represent
bloat-induced performance problems in a diagram, and wondered if one
could have something as simple as the "three bars" diagram you see on
cell phones.
I was working on a related problem, and thought about a diagram that
looked like this (a gif, and ascii in case the gif is filtered out by
the list)
In ascii art, it might look like this:
======++++++++++++
- +
- +
- +
- +
In the ascii, the double line is both "good" and "bad" system
performance, and they are the same up to a load of about 8, where the
"bad" line, shown as minus signs, starts to degrade. The"good" line,
shown as plus signs, stays good until a much higher load, and only then
starts diving down...
The "good" line is the performance of the system when it's feeling well,
and is operating within it's limits. Pretty much a straight line,
possibly with some noise bouncing it up and down. Way out to the right
of the figure, it reaches capacity and starts curling downwards. The
"bad" line is the system when it's artificially degraded by bufferbloat,
and performance takes a dive.
This is the usual "hockey stick ("_/") diagram turned on it's head for
clarity. The X axis is load, the Y is performance, and anyone used to
diagrams where "high is good" will see this system is suffering.
I think this is a fair representation, and *visually* attractive, but
I'm actually glossing over the question of units a bit.
A hockey-stick curve is response time versus load. This is something
like expected response time at the top and increasing response time as
you go *downwards*.
Can anyone suggest a less arbitrary metric? The best of all possible
worlds would be a non-dimensional metric, so similar data from both
small and large systems could be compared with one another.... Perhaps
twice normal, three time normal, etc???
Returning to the representation problem, I think the simplest possible
diagram would literally be three bars, with the tallest representing the
expected response time, and the others some significant degradations
from that. Two bars might be the doubling of response time, one the
tripling of it, and so on.
--dave
--
David Collier-Brown, | Always do right. This will gratify
System Programmer and Author | some people and astonish the rest
davecb@spamcop.net | -- Mark Twain
(416) 223-8968
[-- Attachment #2.1: Type: text/html, Size: 4255 bytes --]
[-- Attachment #2.2: Bloat_Degradation_2.gif --]
[-- Type: image/gif, Size: 7508 bytes --]
next parent reply other threads:[~2013-05-05 19:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.7754.1367496260.1742.bloat@lists.bufferbloat.net>
2013-05-04 20:09 ` David Collier-Brown [this message]
2013-05-06 8:06 ` [Bloat] Representing normal vs bloated systems in diagrams Oliver Hohlfeld
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=51856AE3.3070401@rogers.com \
--to=davec-b@rogers.com \
--cc=bloat@lists.bufferbloat.net \
--cc=davecb@spamcop.net \
/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