[Starlink] Optimized for Speedtest?

[Dave Taht]

yes, they did seem to reduce the excessive buffering and load swings  on
the download to saner sizes back in august or so. 250ms of added latency is
about 5-10x more than they need tho, and hurts all interactive applications
like gaming or videoconferencing. Anything more than 250ms tends to start
"breaking the internet", as many of our protocols start timing out then and
send more packets, which eventually ends in congestion collapse....


On Tue, Mar 15, 2022 at 5: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
>>
>

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20220315/619d3f61/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/20220315/619d3f61/attachment-0001.png>