[Starlink] Optimized for Speedtest?

[Nathan Owens]

I imagine that latency came from having to switch satellites, and re-steer
the beam, making it mostly imperceptible seems pretty good so far. I’m sure
it will improve with time.

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

> 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/55d10299/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/55d10299/attachment-0001.png>