Re: [Starlink] FQ_Codel

[Dave Taht <dave.taht@gmail.com>]

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

On Wed, Jun 8, 2022 at 8:29 AM Warren Ponder <wponderlpp@gmail.com> wrote:
>
> I have been reading up on everything trying to get up to speed on fq_codel. I have Starlink and a router that implements fq_codel. I know implementations can vary. However, has anyone found any general strategies for CPE side settings that can make any improvement?

My "strategy" has been to somehow convince 'em to burn a weekend with
me on implementing sch_cake on the dishy. With BQL-like backpressure
from the radio, making the dishy reliably do low latency
videoconferencing or gaming is straightforward that way. Even SFQ
would gain them this. Users would stop complaining so much when the
bandwidth was low.

Presently though, the dishy's userspace code seems to treat linux more
like a bootloader - it reads from the radio and outputs to the
ethernet port. They haven't done a GPL drop of that, just the router's
- running a 10 year old (version 1), or 6 year old (version 2) hacked
up, ancient, decrepit, vendor supported only version of openwrt
"lede". In the olde days,
a company entering a market like this would coddle developers, give
them hardware and support, not

Worse, on the wifi front, they chose a really scarce mediatek chip for
that router... probably "locking it up"... and nobody in the openwrt
effort (that I'm aware of) has been working on adding in the mainline
support for it needed for any other company.  We're making huge
strides on mediatek in general getting all their other chipsets to
behave like this:

https://blog.cerowrt.org/post/fq-codel-unifi6/

with I hope, us finally fixing the tx power transmit bug that plagued
many of the other mediatek wifi implementations:
https://github.com/openwrt/mt76/issues/633

We've done enough reverse engineering on their devices for me to
conclude that with statistics from the radio - and perhaps some
signalling from the headend, that cake could compensate for
bufferbloat in both directions (backpressure would be better still
there, and on their headends), and there's some json stats that might
be helpful in getting a downstream router to compensate also, but
lacking a starlink node to hack on, I haven't got anywhere.

Mike Puchol has been pulling the stats for his lovely graphing
utilities... but I don't know if they are adaquate enough,
without feeding 'em into cake.

They could be doing so much better than the attached 300+ms of induced
latency on the rrul test. They could be nearly totally flat
latencywise across the board... if they'd give up on 100/20 and being
RDOF compliant, and focus on just providing good low latency service
at lower rates they could increase their subscriber density and nobody
but the speedtest.net devote's would notice.

It's been a frustrating year, not being able to get that weekend of
mutual hacking out of starlink. 400k subscribers that could have taken
advantage of all the innovations we've made in queuing delay in the
last decade if they'd just sink that weekend into applying what they
already almost have in their codebase. And we - in the bufferbloat
effort, would have an exemplary implementation to point to.

Anyway, elsewhere, we've been trying to get starlink users to test
these means of active sensing and configuring cake on your own router.
If you could give either of these scripts a shot?

https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/108848

 Still, I retain hope that someone over there, will end up owning this
problem, and fixing it.

> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink



-- 
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC

[-- Attachment #2: rrul_be_-_2022-05-29_14:17:48.svg --]
[-- Type: image/svg+xml, Size: 155011 bytes --]