Re: [Starlink] It's still the starlink latency...

[Bruce Perens <bruce@perens.com>]

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

On Mon, Sep 26, 2022 at 1:14 PM Ben Greear via Starlink <
starlink@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.

[-- Attachment #2: Type: text/html, Size: 2418 bytes --]