[Starlink] for those new to the starlink list

[Starlink] for those new to the starlink list

[Dave Taht]

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

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
(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

[-- Attachment #2: starlink-3ms-irtt-20min (2).png --]
[-- Type: image/png, Size: 2013513 bytes --]

Re: [Starlink] for those new to the starlink list

[Dave Taht]

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