[Starlink] Optimized for Speedtest?

[Dave Taht]

For the historical record, we finally found ways to compensate for the
wildly variable bandwidth wifi can have in 2014, and mainlined into
linux in 2016.

https://blog.cerowrt.org/post/real_results/

Example of ath10k wifi before/after here:

https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002/

starlink, on the uplink anyway, seemed straightforward to fix, in
comparison to wifi.


On Tue, Mar 15, 2022 at 5:39 PM Dave Taht <dave.taht at gmail.com> wrote:
>
> On Tue, Mar 15, 2022 at 5:09 PM Daniel AJ Sokolov <daniel at 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 at 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



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