On 9/26/22 1:24 PM, Bruce Perens wrote:
On Mon, Sep 26, 2022 at 1:14 PM Ben Greear via Starlink <[email protected]
<mailto:[email protected]>> 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 <[email protected]>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
Starlink mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/starlink
