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

[Ben Greear <greearb@candelatech.com>]

On 9/26/22 1:24 PM, Bruce Perens wrote:
> On Mon, Sep 26, 2022 at 1:14 PM Ben Greear via Starlink <starlink@lists.bufferbloat.net <mailto: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.

A call for other people to fix problems is not doing a great deal of action.  At my house here in USA,
starlink is better than anything else available (Other option being 3Mbps/768 DSL, and maybe some sketchy
fixed-wireless if I put up a tower).  I can and do make zoom/whatever calls on starlink.  It isn't always great, probably
mostly due to some trees I don't want to cut, but it is also functional enough.

The military and anyone else with a real need is going to be able to make use of things that are better
than what is currently available.  Let *them* tell spacex what they really need, it may be completely
different from what you think they need.  Having 'Scientists' make proclamations about assumptions
strikes me as detrimental to everyone involved.

As for vehicle control, NASA can control vehicles on Mars, and you can fly a drone
by near instant line of sight feedback.  There is a long continuum of required latency between those, with
more latency/jitter requiring more intelligent local control and/or more room for errors.

> 
>     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.

Like how low latency do you actually need?  And are you trying to do this low-latency thing at same time you
are doing download/upload tests, or are you just doing minimal traffic and seeing excessive latency/jitter?

> 
>     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.

It is a call to action for engineers make progress where they can actually affect the
technology stack, not just complain that spacex should fix things itself.

Papers or not, wifi still can use plenty of work, relatively low cost of goods to build and test a network (though high
barrier for actually learning the code well enough to make useful progress...but not much to be done about that).

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com