[Starlink] Optimized for Speedtest?

[Starlink] Optimized for Speedtest?

[Daniel AJ Sokolov]

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.

How do they do that, technically?

Is that a result of Bufferbloat? Is that a a specific code in the modem 
to cheat, like some car manufacturers cheated on emissions tests? 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?

Thank you
Daniel

Re: [Starlink] Optimized for Speedtest?

[Nathan Owens]

[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]

I don’t think that’s technically correct - the system schedules user slots
on a 15s interval:

"SpaceX also provides customers with their own phased-array terminal to be
deployed at their service location to connect directly to the satellite’s
Ku- band RF beam. assigned to the user’s service area. Because the Starlink
satellites are constantly moving, the network plans these connections
on 15 second
intervals, continuously re-generating and publishing a schedule of
connections to the satellite fleet and handing off connections between
satellites."
“The ability to control hand-offs in software with millisecond precision
allows SpaceX to turn the constant motion of the constellation into a key
advantage for the Starlink network. These micro-adjustments enhance
Starlink’s reliability and enables more efficient management of capacity in
real time.”

My assumption is the connection switching is make-after-break, meaning
there will be some delay in switching satellites, which seems to cause a
brief increase in loss and buffering.


On Tue, Mar 15, 2022 at 3: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.
>
> How do they do that, technically?
>
> Is that a result of Bufferbloat? Is that a a specific code in the modem
> to cheat, like some car manufacturers cheated on emissions tests? 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?
>
> Thank you
> Daniel
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>

[-- Attachment #2: Type: text/html, Size: 3269 bytes --]

Re: [Starlink] Optimized for Speedtest?

[Dave Taht]

[-- Attachment #1: Type: text/plain, Size: 2937 bytes --]

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

[-- Attachment #2: rrul_be_-_dlangs-dishy.png --]
[-- Type: image/png, Size: 216268 bytes --]

[-- Attachment #3: 60ghzradio.png --]
[-- Type: image/png, Size: 120553 bytes --]

[-- Attachment #4: tcp_nup_-_nathan-dishy.png --]
[-- Type: image/png, Size: 151795 bytes --]

Re: [Starlink] Optimized for Speedtest?

[Nathan Owens]

[-- Attachment #1.1: Type: text/plain, Size: 3485 bytes --]

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
>

[-- Attachment #1.2: Type: text/html, Size: 4815 bytes --]

[-- Attachment #2: 808769AB-30BF-4297-BCB2-2302D4448399.png --]
[-- Type: image/png, Size: 451758 bytes --]

Re: [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@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



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

Re: [Starlink] Optimized for Speedtest?

[Dave Taht]

[-- Attachment #1.1: Type: text/plain, Size: 4268 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 5997 bytes --]

[-- Attachment #2: 808769AB-30BF-4297-BCB2-2302D4448399.png --]
[-- Type: image/png, Size: 451758 bytes --]

Re: [Starlink] Optimized for Speedtest?

[Dave Taht]

[-- Attachment #1.1: Type: text/plain, Size: 4760 bytes --]

I am not sure if dan luu has also twigged that bufferbloat was a root cause
of his web problems, here: https://danluu.com/web-bloat/

On Tue, Mar 15, 2022 at 5:51 PM Dave Taht <dave.taht@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@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
>


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

[-- Attachment #1.2: Type: text/html, Size: 6891 bytes --]

[-- Attachment #2: 808769AB-30BF-4297-BCB2-2302D4448399.png --]
[-- Type: image/png, Size: 451758 bytes --]

Re: [Starlink] Optimized for Speedtest?

[Nathan Owens]

[-- Attachment #1.1: Type: text/plain, Size: 4653 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 6749 bytes --]

[-- Attachment #2: 808769AB-30BF-4297-BCB2-2302D4448399.png --]
[-- Type: image/png, Size: 451758 bytes --]

Re: [Starlink] Optimized for Speedtest?

[David Lang]

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

I have noticed very different speeds at different times (I can't know for sure 
who is up an using it, but middle of the night speeds tend to be much better 
than late evening speeds so I'm guessing it correlates to usage)

David Lang

Re: [Starlink] Optimized for Speedtest?

[Dave Taht]

One of the many unknowns is about how starlink schedules uplink and
downlink "rates" (e.g to some extent the density of encodings). Is it
one or more beam with multiple destinatons on the down? Or ?

Toke went deep into how wifi ATF works here:
https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html

Another big question is how they handle encryption(s), again, how wifi
works from my notebook is here:
https://blog.cerowrt.org/post/crypto_fq_bug/ (with just how hard it
was to get right! I still have 87 blog entries from that era to write
up!)

I can think of a half dozen different ways they could be modulating
the beams to encapsulate all the data! Wifi had crypto baked in late
(see above) and i would have started with good crypto first in their
case, but "my" solution would have much higher power requirements
(spitting own all data, received by all, decrypted by the receivers
that could find their segments) than what I think they are actually
doing, but without two dishys on the same cell, closely linked in time
via gps pps, and refine analog an digital measurements, can't wager a
guess at the moment.

On Tue, Mar 15, 2022 at 5:48 PM Dave Taht <dave.taht@gmail.com> wrote:
>
> 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@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
>
>
>
> --
> 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

Re: [Starlink] Optimized for Speedtest?

[Dave Taht]

(for the record my d and e keys are not working well right now)

On Tue, Mar 15, 2022 at 10:48 PM Dave Taht <dave.taht@gmail.com> wrote:
>
> One of the many unknowns is about how starlink schedules uplink and
> downlink "rates" (e.g to some extent the density of encodings). Is it
> one or more beam with multiple destinatons on the down? Or ?
>
> Toke went deep into how wifi ATF works here:
> https://blog.tohojo.dk/2016/06/fixing-the-wifi-performance-anomaly-on-ath9k.html
>
> Another big question is how they handle encryption(s), again, how wifi
> works from my notebook is here:
> https://blog.cerowrt.org/post/crypto_fq_bug/ (with just how hard it
> was to get right! I still have 87 blog entries from that era to write
> up!)
>
> I can think of a half dozen different ways they could be modulating
> the beams to encapsulate all the data! Wifi had crypto baked in late
> (see above) and i would have started with good crypto first in their
> case, but "my" solution would have much higher power requirements
> (spitting own all data, received by all, decrypted by the receivers
> that could find their segments) than what I think they are actually
> doing, but without two dishys on the same cell, closely linked in time
> via gps pps, and refine analog an digital measurements, can't wager a
> guess at the moment.
>
> On Tue, Mar 15, 2022 at 5:48 PM Dave Taht <dave.taht@gmail.com> wrote:
> >
> > 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@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
> >
> >
> >
> > --
> > 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



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

Re: [Starlink] Optimized for Speedtest?

[Nathan Owens]

[-- Attachment #1.1: Type: text/plain, Size: 10178 bytes --]

If you just UDP iperf the crap out of it, the bandwidth available is pretty
good:

[ ID] Interval           Transfer     Bitrate         Jitter    Lost/Total
Datagrams
[  5]   0.00-1.00   sec  25.7 MBytes   216 Mbits/sec  0.026 ms  10078/28719
(35%)
[  5]   1.00-2.00   sec  36.0 MBytes   302 Mbits/sec  0.031 ms  4178/30262
(14%)
[  5]   2.00-3.00   sec  39.0 MBytes   327 Mbits/sec  0.053 ms  1961/30231
(6.5%)
[  5]   3.00-4.00   sec  38.9 MBytes   326 Mbits/sec  0.059 ms  1787/29937
(6%)
[  5]   4.00-5.00   sec  39.1 MBytes   328 Mbits/sec  0.026 ms  2166/30447
(7.1%)
[  5]   5.00-6.00   sec  34.4 MBytes   289 Mbits/sec  0.030 ms  5274/30180
(17%)
[  5]   6.00-7.00   sec  34.9 MBytes   293 Mbits/sec  0.066 ms  4982/30286
(16%)
[  5]   7.00-8.00   sec  37.6 MBytes   316 Mbits/sec  0.136 ms  2915/30158
(9.7%)
[  5]   8.00-9.00   sec  39.0 MBytes   327 Mbits/sec  0.040 ms  2004/30250
(6.6%)
[  5]   9.00-10.00  sec  39.0 MBytes   327 Mbits/sec  0.055 ms  1977/30240
(6.5%)
[  5]  10.00-11.00  sec  38.2 MBytes   320 Mbits/sec  0.029 ms  2539/30203
(8.4%)
[  5]  11.00-12.00  sec  35.7 MBytes   299 Mbits/sec  0.070 ms  4349/30177
(14%)
[  5]  12.00-13.00  sec  32.9 MBytes   276 Mbits/sec  0.028 ms  6336/30169
(21%)
[  5]  13.00-14.00  sec  36.1 MBytes   303 Mbits/sec  0.027 ms  4110/30271
(14%)
[  5]  14.00-15.00  sec  22.2 MBytes   186 Mbits/sec  0.033 ms  14245/30298
(47%)
[  5]  15.00-16.00  sec  27.1 MBytes   227 Mbits/sec  0.066 ms  10529/30164
(35%)
[  5]  16.00-17.00  sec  33.4 MBytes   280 Mbits/sec  0.057 ms  5989/30184
(20%)
[  5]  17.00-18.00  sec  33.7 MBytes   283 Mbits/sec  0.046 ms  5804/30220
(19%)
[  5]  18.00-19.00  sec  24.7 MBytes   207 Mbits/sec  0.032 ms  12323/30198
(41%)
[  5]  19.00-20.00  sec  30.6 MBytes   257 Mbits/sec  0.044 ms  8129/30292
(27%)
[  5]  20.00-21.00  sec  27.9 MBytes   234 Mbits/sec  0.030 ms  9905/30140
(33%)
[  5]  21.00-22.00  sec  19.5 MBytes   164 Mbits/sec  0.059 ms  16089/30220
(53%)
[  5]  22.00-23.00  sec  19.4 MBytes   163 Mbits/sec  0.069 ms  16147/30211
(53%)
[  5]  23.00-24.00  sec  20.5 MBytes   172 Mbits/sec  0.035 ms  15355/30234
(51%)
[  5]  24.00-25.00  sec  25.6 MBytes   215 Mbits/sec  0.030 ms  11634/30187
(39%)
[  5]  25.00-26.00  sec  34.1 MBytes   286 Mbits/sec  0.061 ms  5681/30346
(19%)
[  5]  26.00-27.00  sec  29.4 MBytes   247 Mbits/sec  0.037 ms  8787/30081
(29%)
[  5]  27.00-28.00  sec  23.3 MBytes   196 Mbits/sec  0.056 ms  13361/30257
(44%)
[  5]  28.00-29.00  sec  31.0 MBytes   260 Mbits/sec  0.028 ms  7750/30206
(26%)
[  5]  29.00-30.00  sec  20.4 MBytes   171 Mbits/sec  0.033 ms  15422/30186
(51%)
[  5]  30.00-31.00  sec  30.9 MBytes   259 Mbits/sec  0.039 ms  7761/30110
(26%)
[  5]  31.00-32.00  sec  31.4 MBytes   263 Mbits/sec  0.055 ms  7641/30357
(25%)
[  5]  32.00-33.00  sec  31.9 MBytes   268 Mbits/sec  0.062 ms  7069/30180
(23%)
[  5]  33.00-34.00  sec  29.8 MBytes   250 Mbits/sec  0.028 ms  8630/30206
(29%)
[  5]  34.00-35.00  sec  32.7 MBytes   274 Mbits/sec  0.056 ms  6638/30283
(22%)
[  5]  35.00-36.00  sec  29.5 MBytes   247 Mbits/sec  0.066 ms  8800/30129
(29%)
[  5]  36.00-37.00  sec  25.9 MBytes   217 Mbits/sec  0.038 ms  11501/30247
(38%)
[  5]  37.00-38.00  sec  26.2 MBytes   220 Mbits/sec  0.050 ms  10978/29969
(37%)
[  5]  38.00-39.00  sec  28.0 MBytes   235 Mbits/sec  0.038 ms  10208/30490
(33%)
[  5]  39.00-40.00  sec  25.2 MBytes   211 Mbits/sec  0.109 ms  11942/30171
(40%)
[  5]  40.00-41.00  sec  24.7 MBytes   208 Mbits/sec  0.022 ms  12360/30279
(41%)
[  5]  41.00-42.00  sec  24.1 MBytes   202 Mbits/sec  0.041 ms  12587/30040
(42%)
[  5]  42.00-43.00  sec  26.0 MBytes   218 Mbits/sec  0.032 ms  11635/30444
(38%)
[  5]  43.00-44.00  sec  26.0 MBytes   218 Mbits/sec  0.063 ms  11318/30153
(38%)
[  5]  44.00-45.00  sec  23.3 MBytes   196 Mbits/sec  0.028 ms  13279/30183
(44%)
[  5]  45.00-46.00  sec  34.8 MBytes   292 Mbits/sec  0.046 ms  5008/30227
(17%)
[  5]  46.00-47.00  sec  35.2 MBytes   295 Mbits/sec  0.041 ms  4838/30334
(16%)
[  5]  47.00-48.00  sec  29.1 MBytes   244 Mbits/sec  0.068 ms  9052/30147
(30%)
[  5]  48.00-49.00  sec  26.0 MBytes   218 Mbits/sec  0.040 ms  11421/30222
(38%)
[  5]  49.00-50.00  sec  25.4 MBytes   213 Mbits/sec  0.049 ms  11798/30207
(39%)
[  5]  50.00-51.00  sec  27.3 MBytes   229 Mbits/sec  0.057 ms  10412/30217
(34%)
[  5]  51.00-52.00  sec  24.9 MBytes   209 Mbits/sec  0.030 ms  12179/30233
(40%)
[  5]  52.00-53.00  sec  26.5 MBytes   222 Mbits/sec  0.045 ms  11067/30259
(37%)
[  5]  53.00-54.00  sec  26.5 MBytes   223 Mbits/sec  0.025 ms  10985/30200
(36%)
[  5]  54.00-55.00  sec  25.3 MBytes   212 Mbits/sec  0.099 ms  11861/30192
(39%)
[  5]  55.00-56.00  sec  29.7 MBytes   249 Mbits/sec  0.034 ms  8714/30235
(29%)
[  5]  56.00-57.00  sec  36.1 MBytes   303 Mbits/sec  0.053 ms  4051/30224
(13%)
[  5]  57.00-58.00  sec  29.8 MBytes   250 Mbits/sec  0.048 ms  8622/30187
(29%)
[  5]  58.00-59.00  sec  31.6 MBytes   265 Mbits/sec  0.029 ms  7481/30353
(25%)
[  5]  59.00-60.00  sec  14.2 MBytes   119 Mbits/sec  0.040 ms  19884/30175
(66%)
[  5]  60.00-61.00  sec  33.3 MBytes   279 Mbits/sec  0.034 ms  6223/30336
(21%)
[  5]  61.00-62.00  sec  32.7 MBytes   274 Mbits/sec  0.034 ms  6490/30157
(22%)
[  5]  62.00-63.00  sec  33.3 MBytes   279 Mbits/sec  0.034 ms  6099/30217
(20%)
[  5]  63.00-64.00  sec  31.4 MBytes   264 Mbits/sec  0.024 ms  7409/30162
(25%)
[  5]  64.00-65.00  sec  34.3 MBytes   288 Mbits/sec  0.031 ms  5504/30328
(18%)
[  5]  65.00-66.00  sec  34.4 MBytes   288 Mbits/sec  0.077 ms  5316/30216
(18%)
[  5]  66.00-67.00  sec  34.2 MBytes   287 Mbits/sec  0.042 ms  5424/30167
(18%)
[  5]  67.00-68.00  sec  29.4 MBytes   247 Mbits/sec  0.034 ms  8900/30223
(29%)
[  5]  68.00-69.00  sec  33.4 MBytes   280 Mbits/sec  0.050 ms  6052/30203
(20%)
[  5]  69.00-70.00  sec  34.4 MBytes   289 Mbits/sec  0.031 ms  5312/30259
(18%)
[  5]  70.00-71.00  sec  34.4 MBytes   288 Mbits/sec  0.049 ms  5308/30198
(18%)
[  5]  71.00-72.00  sec  30.8 MBytes   259 Mbits/sec  0.031 ms  7835/30169
(26%)
[  5]  72.00-73.00  sec  33.9 MBytes   284 Mbits/sec  0.063 ms  5730/30254
(19%)
[  5]  73.00-74.00  sec  33.4 MBytes   280 Mbits/sec  0.045 ms  6012/30226
(20%)
[  5]  74.00-75.00  sec  20.0 MBytes   168 Mbits/sec  0.039 ms  15586/30062
(52%)
[  5]  75.00-75.51  sec  10.2 MBytes   166 Mbits/sec  0.057 ms  8141/15495
(53%)

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

[-- Attachment #1.2: Type: text/html, Size: 12319 bytes --]

[-- Attachment #2: 808769AB-30BF-4297-BCB2-2302D4448399.png --]
[-- Type: image/png, Size: 451758 bytes --]

Re: [Starlink] Optimized for Speedtest?

[Nathan Owens]

[-- Attachment #1.1: Type: text/plain, Size: 3809 bytes --]

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

[-- Attachment #1.2: Type: text/html, Size: 5377 bytes --]

[-- Attachment #2: 808769AB-30BF-4297-BCB2-2302D4448399.png --]
[-- Type: image/png, Size: 451758 bytes --]

[-- Attachment #3: Screen Shot 2022-03-16 at 6.47.44 AM.png --]
[-- Type: image/png, Size: 1314068 bytes --]