Re: [Starlink] Optimized for Speedtest?

[Nathan Owens <nathan@nathan.io>]

[-- Attachment #1.1: Type: text/plain, Size: 3485 bytes --]

Here’s what it looks like for a sustained download:
https://i.redd.it/odo31ofu4t971.png
This was from a while ago, most of those latency spikes have been dampened.

On Tue, Mar 15, 2022 at 3:39 PM Dave Taht <dave.taht@gmail.com> wrote:

> On Tue, Mar 15, 2022 at 5:09 PM Daniel AJ Sokolov <daniel@falco.ca> wrote:
> >
> > Hello,
> >
> >  From this list I have learned that Starlink is optimized to shine in
> > tests with speedtest.net and similar sites, but that transmission rates
> > drop quickly after about 15 seconds.
>
> That is not strictly true. The trend is a low rate for the initial
> 15s, then a boost, then variable. It happens that speedtest reports
> the *last* result in the typically 20s it runs,
> so by that light is starlink is "optimized for speedtest". Much of the
> internet is "optimized for speedtest", tons of services basically blow
> up classic tcp congestion controls at T+21s.
>
> Attached are two example flent test runs, a rrul test from one project
> member's dishy, and a tcp_nup test from anothers.
>
> For reference also attached is how a present day WISP 60Ghz radio
> functions, one which has FQ and AQM, with consistent bandwidth, and
> only ~5ms latency swings. Ideally the latency on starlink would not go
> over 10ms their baseline ~40ms latency, under these loads.
>
> Comparing the later two tests you can see the inversions between
> bandwidth and latency that come from the fixed length fifos starlink
> uses at any of the roughly 3
> speed settings we currently see.
>
> PS - most web pages cannot use more than 25MBit in the 3s they typically
> take.
>
> > How do they do that, technically?
>
> Allocate bandwidth? Unknown. Ever 15s seems silly. Not modifying queue
> length and/not using a smarter queuing algo like fq_codel or cake when
> they do change the bandwidth allocation is the simple flaw in their
> design I keep hoping they'll fix.
>
> >
> > Is that a result of Bufferbloat?
>
> Yes. The rrul test is often illustrative of the problem on how slowly
> the internet operates during an upload clogging up the queue, or vice
> versa. Most ISPs do some sort of ack filtering or prioritization to
> make uploads interfere less with downloads, or use AQM, fq or a
> combination of both.
>
> > Is that a a specific code in the modem
> > to cheat, like some car manufacturers cheated on emissions tests?
>
> I hope not. No, they do have limited capacity, do have to change sats,
> do need to allocate bandwidth sanely. AND buffering.
>
> > Is
> > that something done in the satellites who shift capacity from other
> > users to those users who initiate downloads? Is that done on the
> backhaul?
>
> Wish we knew. In my ideal world they would supply a statistic that a
> sch_cake could take and vary the rate/buffering based on that on the
> home router, or just do it more right
> in the dishy and head ends with cake + BQL.
>
> >
> > Thank you
> > Daniel
> > _______________________________________________
> > Starlink mailing list
> > Starlink@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/starlink
>
>
>
> --
> I tried to build a better future, a few times:
> https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org
>
> Dave Täht CEO, TekLibre, LLC
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #1.2: Type: text/html, Size: 4815 bytes --]

[-- Attachment #2: 808769AB-30BF-4297-BCB2-2302D4448399.png --]
[-- Type: image/png, Size: 451758 bytes --]