General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: David Collier-Brown <davec-b@rogers.com>
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] an observation from the field
Date: Tue, 28 Aug 2018 19:53:07 -0400	[thread overview]
Message-ID: <2385fcbb-d460-ce57-e4e3-e3cbb94ebc3d@rogers.com> (raw)
In-Reply-To: <CAA93jw5ZYTJJSjggzL+gtnw2DbeAenwJ+ozF4K=c_KN8fUmDsw@mail.gmail.com>

On 2018-08-28 1:07 p.m., Dave Taht wrote:
> In looking over the increasingly vast sqm-related deployment, there's
> a persistent data point that pops up regarding inbound shaping at high
> rates.
>
> We give users a choice - run out of cpu at those rates or do inbound
> sqm at a rate their cpu can afford.  A remarkable percentage are
> willing to give up tons of bandwidth in order to avoid latency
> excursions (oft measured, even in these higher speed 200+Mbit
> deployments, in the 100s of ms) -

Humans experience delays directly, and so perceive systems with high 
latency as "slow". The proverbial "man on the Clapham omnibus" therefor 
responds to high-latency systems with disgust.

A trained scientist, however, runs the risk of choosing something that 
requires complicated measurement schemes, and might well choose to 
optimize for throughput, as that sounds like a desirable measure, one 
matching their intuitions of what "fast" means.

Alas, in this case the scientist's intuition is far poorer than the 
random person's direct experience.

> At least some users want low delay always. It's just the theorists
> that want high utilization right at the edge of capacity. Users are
> forgiving about running out of cpu - disgruntled, but forgiving.
>
> Certainly I'm back at the point of recommending tbf+fq_codel for
> inbound shaping at higher rates - and looking at restoring the high
> speed version of cake - and I keep thinking a better policer is
> feasible.
>
My advice to engineers? First, go for things you can both experience and 
measure, and only then things you have to measure.

--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


  parent reply	other threads:[~2018-08-28 23:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-28 17:07 Dave Taht
2018-08-28 18:22 ` Jonathan Foulkes
2018-08-28 23:53 ` David Collier-Brown [this message]
2018-08-29  0:16   ` Jonathan Morton
2018-08-29  8:20     ` Jonas Mårtensson
2018-08-29 15:37       ` Dave Taht

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=2385fcbb-d460-ce57-e4e3-e3cbb94ebc3d@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