General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Pete Heist <pete@heistp.net>
To: Dave Taht <dave.taht@gmail.com>
Cc: bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] debloats/day metric?
Date: Mon, 27 Aug 2018 09:44:26 +0200	[thread overview]
Message-ID: <760F79E7-EA45-46B9-AA0F-7300D0242E44@heistp.net> (raw)
In-Reply-To: <CAA93jw5TPRmrpATbxBkMEiUpNvLQmC2EE1xPVVBC-=T=5v867A@mail.gmail.com>

Not sure how to answer exactly, but I’m interested in some way to measure bloat more directly both instantaneously and over time. My current plan for instantaneous measurement is to modify irtt to send request pairs, one given strict priority at the bottleneck and one best effort, then measure the difference between the two (for both RTT and OWD).

Assuming this yields useful data, maybe there is a long-term stat that could be derived from it that indicates how much bloat there is for a given link, or how well it has been mitigated.

For interest, here are abbreviated cake stats from 12 hours at the camp (~40Mbit p2p WiFi), so double those for an approximate daily stat:

Egress:
                  Tin 0
  pkts         12327019
  bytes      3838819739
  way_inds       903650
  way_miss       261326
  drops             929
  marks               8

Ingress:
                  Tin 0
  pkts         28783116
  bytes     36517120801
  way_inds      2031504
  way_miss       250153
  drops           12648
  marks              24

> On Aug 25, 2018, at 6:57 PM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> I'm always casting about for some simple metric, some simple phrase,
> that we can use to describe what we're about. Lately - without
> formally defining it mathematically as yet - I've been talking about
> "badwidth" - what you get from your typical ISP - and "goodwidth",
> what debloating does - which originally sprang from me typo-ing
> "bandwidth".
> 
> More recently I tried combatting the perception that packet
> drops/marks are "bad", by renaming them to "debloats/day".
> 
> Codel kicks in rarely, but I'm pretty sure every time it does it saves
> on a bit of emotional upset and jitter for the user. For example I get
> about 3000 drops/ecn marks a day one inbound 100mbit/20mbit campus
> link (about 12,000 on the wifi links), and outbound a mere ~100 or so.
> 
> But: Every one of those comforts me 'cause I feel like I'm saving a
> ~500ms latency excursion for all the users of this (640ms badwidth
> down/280ms up) comcast link.
> 
> I am kind of curious as to y'all's regular "debloats/day"?


  reply	other threads:[~2018-08-27  7:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-25 16:57 Dave Taht
2018-08-27  7:44 ` Pete Heist [this message]
2018-08-27  8:02   ` Jonathan Morton
2018-08-27  9:32     ` Pete Heist

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=760F79E7-EA45-46B9-AA0F-7300D0242E44@heistp.net \
    --to=pete@heistp.net \
    --cc=bloat@lists.bufferbloat.net \
    --cc=dave.taht@gmail.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