[Starlink] It's still the starlink latency...
Bruce Perens
bruce at perens.com
Mon Sep 26 16:24:33 EDT 2022
On Mon, Sep 26, 2022 at 1:14 PM Ben Greear via Starlink <
starlink at lists.bufferbloat.net> wrote:
> I think that engineers telling other engineers (military) that something
> isn't
> sufficient is making a lot of assumptions that should not be made.
>
I don't think we need quite that call to inaction :-) . I can certainly see
the problem on my Starlink connection, and can classify the degradation of
performance under load that should not be there. It's insufficient for a
low latency video call, which I think is an easy definition of a
lowest-common-denominator for anything involving vehicle control.
And if you want to propose some solution, then define the metrics of that
> solution. First,
> what is max latency/jitter/whatever that the application can handle and
> still be useful?
> Why exactly is your ham thing failing, and what latency/jitter would
> resolve it. And/or, what mitigation
> in your software/procedures would solve it.
>
My ham application is equivalent to a low-latency voice-only WebRTC call.
There are diagnostics for them, and for the video call mentioned above. I
would hope that Taht could put together numbers.
> I know that Dave & crew have made some improvements to the wifi stack, but
> it is far from
> solved even today. Maybe effort is better done on wifi where developers
> that are not @spacex
> can actually make changes and test results.
>
This does seem to be a call to inaction, doesn't it? Dave and Co. have been
working on WiFi for quite some time and have good papers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20220926/8fb6f1e4/attachment.html>
More information about the Starlink
mailing list