Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Nick Buraglio <buraglio@forwardingplane.net>
To: Dave Taht <davet@teklibre.net>
Cc: starlink@lists.bufferbloat.net, Matt Mathis <mattmathis@google.com>
Subject: Re: [Starlink] plotting all the data
Date: Thu, 17 Jun 2021 09:24:53 -0500	[thread overview]
Message-ID: <CAGB08_cxray74yuBoOArY8Hrx=ScLC8kXgpKPwq88FGpwe3Brw@mail.gmail.com> (raw)
In-Reply-To: <C17CB66C-5C11-4BFB-BFF6-E645CB74DE93@teklibre.net>

[-- Attachment #1: Type: text/plain, Size: 1946 bytes --]

This is much more common in the high performance computing and networking
space (i.e. perfsonar, TWAMP, and OWAMP). I have also been pushing "gather
and store all the data" for ....since I was an engineer working on the
Teragrid (which is where I first saw Matt's MTU talk around 2002 or 03,
BTW).  =)
High fidelity plots of everything that can be gathered is laborious to
curate but is invaluable for so many reasons. Now we just need a way to
make it happen everywhere for everyone in a way that's easy.

nb


On Thu, Jun 17, 2021 at 8:57 AM Dave Taht <davet@teklibre.net> wrote:

> Capturing and plotting *all* the data is often revealing.
>
> Sometimes plotting the data you are discarding (for what seems like sane
> reasons) is quite revealing.  Saw this on slashdot this morning, it’s
> good...
>
>
> https://www.newyorker.com/magazine/2021/06/21/when-graphs-are-a-matter-of-life-and-death
>
> In the bufferbloat effort I’ve fought time and time again for folk to stop
> throwing out data above the 95 percentile, and at the very least plot
> everything they threw out to find patterns...
>
> dslreports’ graphing tools, for example, throws out a ton of “outliers" …
> and the only reason why there is no data past 4 sec here, is that the test
> doesn’t run long enough.
>
> http://www.dslreports.com/speedtest/results/bufferbloat?up=1
>
> (been trying to get ahold of someone over there to buy their raw data for
> years now. They have the biggest - 8 years worth - collection)
>
> mlabs has a similar data reduction issue that they haven’t got around to
> fixing.
>
> And more recently we encountered a smoothing problem in wireshark that
> made a halt in packet processing look more like a normal tcp cwnd cut….
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 2717 bytes --]

  reply	other threads:[~2021-06-17 14:25 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-17 13:56 Dave Taht
2021-06-17 14:24 ` Nick Buraglio [this message]
2021-06-17 15:28   ` Dave Taht
2021-06-17 15:49   ` Matt Mathis
2021-06-17 20:18     ` George Burdell

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/starlink.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAGB08_cxray74yuBoOArY8Hrx=ScLC8kXgpKPwq88FGpwe3Brw@mail.gmail.com' \
    --to=buraglio@forwardingplane.net \
    --cc=davet@teklibre.net \
    --cc=mattmathis@google.com \
    --cc=starlink@lists.bufferbloat.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