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

--

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