On Wed, Jun 8, 2022 at 8:29 AM Warren Ponder 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