Starlink has bufferbloat. Bad.
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: starlink@lists.bufferbloat.net
Subject: Re: [Starlink] for those new to the starlink list
Date: Thu, 28 Oct 2021 19:07:29 -0700	[thread overview]
Message-ID: <CAA93jw7gMEpumishBa2FjKg0-qd6Qf-r4t1w0dd_KK+-wzSciw@mail.gmail.com> (raw)
In-Reply-To: <CAA93jw7d2e3CwOF9FBUg5mGVrbN4FDrBqsBw6azCR_N3mtikKA@mail.gmail.com>

On Thu, Oct 28, 2021 at 7:00 PM Dave Taht <dave.taht@gmail.com> wrote:
>
> I'd presented the bufferbloat data here to some starlink folk back in june:
>
> https://docs.google.com/document/d/1puRjUVxJ6cCv-rgQ_zn-jWZU9ae0jZbFATLf4PQKblM/edit#
>
> We made the flent data publicly available via rsync here, all sorts of
> details if you want to check it out via flent.
>
> cd yourbaredir
> rsync -av fremont.starlink.taht.net::starlink .
>
> But given they seemed to be stalling out vs a vs manufacturing and as
> I was buried by my apple gig, and low on students, I put it down.
>
> Since then I have a team doing rfc3168, with viasat and starlink sims,
> looking at bbrv2, and doing higher res measurements. On no budget,
> sigh. Recently there's been some progress on dynamically reconfiguring
> sch_cake via a couple sensing methods, but it was my hope then, as
> now, that starlink made fixing the bloat a priority.
>
> with 6 upload streams, sep 4th :
>
>  ./irtt client --dscp=0xfe -i5ms -d30s fremont.starlink.taht.net -q
> --timer=hybrid
> [Connecting] connecting to fremont.starlink.taht.netrtt
> [45.79.113.72:2112] [Connected] connection established
> [45.79.113.72:2112] [WaitForPackets] waiting 1.01s for final packets
>
>                          Min     Mean   Median      Max   Stddev
>                          ---     ----   ------      ---   ------
>                 RTT  47.91ms  95.28ms  94.41ms  337.9ms  20.33ms
>          send delay  22.77ms  60.92ms  56.67ms  309.8ms  19.77ms
>       receive delay     24ms  34.36ms  28.34ms   59.9ms   7.51ms
>
>       IPDV (jitter)   1.88ms   5.09ms   4.98ms  112.3ms      3ms
>           send IPDV   30.5µs   4.96ms   4.93ms  119.4ms   2.99ms
>        receive IPDV      9ns    272µs   45.8µs  17.64ms   1.25ms
>
>      send call time   9.72µs   23.5µs            89.9µs   14.8µs
>         timer error       0s   86.9µs             610µs    114µs
>   server proc. time    620ns   7.39µs            66.7µs   7.06µs
>
> We've been using the high-res (3ms) probing technique to take apart
> some 4g and 5g realities, also, but the starlink one was fascinating.
> You can
> clearly see them adjusting the network every 15ms, all sorts of

15s I meant.

smells like IS-IS.

I really prefer DV protocols....

> (beamforming?) artifacts, the 400ms bufferbloat spike from a speedtest
> mountain about 1/3 of the way through... and I keep hoping we attract
> two people to that sub-project with dishy's in the same cell.
>
> [plots courtesy of nathan]
>
>
> --
> Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw
>
> Dave Täht CEO, TekLibre, LLC



-- 
Fixing Starlink's Latencies: https://www.youtube.com/watch?v=c9gLo6Xrwgw

Dave Täht CEO, TekLibre, LLC

      reply	other threads:[~2021-10-29  2:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-29  2:00 Dave Taht
2021-10-29  2:07 ` Dave Taht [this message]

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=CAA93jw7gMEpumishBa2FjKg0-qd6Qf-r4t1w0dd_KK+-wzSciw@mail.gmail.com \
    --to=dave.taht@gmail.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