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"?
next prev parent 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