[Starlink] Optimized for Speedtest?

[Nathan Owens]

[image: Screen Shot 2022-03-16 at 6.47.44 AM.png]

I repeated this now, no latency spikes or dips to near 0 every 15s are
visible anymore.


On Tue, Mar 15, 2022 at 3:47 PM Nathan Owens <nathan at nathan.io> wrote:

> 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 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
>> _______________________________________________
>> Starlink mailing list
>> Starlink at lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/starlink
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20220316/3fa8df4a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 808769AB-30BF-4297-BCB2-2302D4448399.png
Type: image/png
Size: 451758 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20220316/3fa8df4a/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screen Shot 2022-03-16 at 6.47.44 AM.png
Type: image/png
Size: 1314068 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20220316/3fa8df4a/attachment-0003.png>