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