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