On Mon, Sep 26, 2022 at 1:14 PM Ben Greear via Starlink < [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. 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.
_______________________________________________ Starlink mailing list [email protected] https://lists.bufferbloat.net/listinfo/starlink
