[Battlemesh] anyone here on the starlink beta? How's the bloat? other features?

[Benjamin Henrion]

le sam. 2 janv. 2021 à 18:40, Dave Taht <dave.taht at gmail.com> a écrit :

> I figure that getting the starlink terminal working at all
> was a greater challenge than tackling the bufferbloat issue. I've long
> worried of
> course, that the mac layer on this thing was going to be very weird,
> and since they were working with qca they'd end up burying everything
> in the network offload processors, even though at present speeds the
> cpu they are using is *loafing*, I'm not as optimistic as jon morton is as
> to
> how easy the port of cake or fq_codel would be to their hardware as it
> is variable bandwidth and thus needs bql-like backpressure.
>
> Since there doesn't seem to be a gpl drop yet I don't know a lot more,
> however there was a teardown of the hw and jim's posting and a start
> at testing on reddit - the dslreports test was flawed in that ping did
> not work at all....
>
>
> https://www.reddit.com/r/Starlink/comments/k0dwon/starlink_and_bufferbloat_testing/
>
> rate limiting with sqm works beautifully:
>
>
> https://www.reddit.com/r/Starlink/comments/jxkef9/ahat_is_your_starlinks_bufferbloat_score/
>
> and the starlink teardown was good:
>
> https://www.reddit.com/r/hardware/comments/kchxl8/starlink_teardown_and_analysis/
>
> So I  think that this hardware actually has fq_codel AND hw rate limiting
> in it... and openwrt... But pure either algo is not the right thing
> for a starlink up or downlink
> which is variable rate.
>

How do you know it runs OpenWRT?

Sharing Starlink via mesh looks like an interesting option.

Enjoy sailing,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://ml.ninux.org/pipermail/battlemesh/attachments/20210102/2648d9ab/attachment.html>