From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1FB2B3B29E for ; Mon, 26 Sep 2022 16:24:45 -0400 (EDT) Received: by mail-ej1-x634.google.com with SMTP id z13so16563072ejp.6 for ; Mon, 26 Sep 2022 13:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=perens.com; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=CLWZ3zw0oOyyXGajrjrNdMYeqyGM6dqlJeA7tLxNWDM=; b=NsoTB6jZR8w4yldjJgVV7ngTLnal4GVYt9upvKmPovHssh1Hy4wNqZgxlEr47dp3qh 2ODxTXzaZVgHbyFjIwMwQRSy7HCW6kcdymwycN0j2Wzvu5aCFRkNLcwFvWjbSLII5V9V 2uFMgVoZbA1wTes+eFJbh5Jjtll1eQ+lOUiQE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=CLWZ3zw0oOyyXGajrjrNdMYeqyGM6dqlJeA7tLxNWDM=; b=33F5tTkuqFSBM7GfmtzWwAw5HNbVLk/LpK+5adcaUemBhglQTcZtPoxrFvS3ItB8Fy T3HZNNIVZoRwJfzF00ibj0vjaHkezvuirQ64uZrEYyKz5qhWkqpxElV9M1/T4dDDCzqi 3e9injZ1xDcgYuu1GkN0rxKzSGDeam1CmffqcbeFcm7se/wSLOMT9cNtwnSGRDu4csuy 04eqrb3h4U99kx8xS/UpI2VWVGM4P9Gb/FY6fNfomqPxVEMeBMFQW+ycMP57k9byYXiQ Z6yrvWOPFgtnxpSpMa2K6m4/5txJD0i9Umhc71u3s1k7bmX1Jb199b3TAl9ZKnNxM2cy K9pw== X-Gm-Message-State: ACrzQf0BpdVrroj3n+Ho/Lh2fB+WTk3WrvEiLT9ASiHrSHA91HOa8gqs ms36uiZc/cFk86Wz/6fseOPbW/OQK/nbaCiaWoIBKMTl+s5UWA== X-Google-Smtp-Source: AMsMyM7t1TxWyRLrNQwHzon0dBGFnrPH/QJmTxioOfT9JnGSe8mbyflhc15UZyFj8fJwxDwjVfa64zpzXubSjKZVuJY= X-Received: by 2002:a17:906:4fca:b0:782:2484:6d72 with SMTP id i10-20020a1709064fca00b0078224846d72mr20531901ejw.150.1664223883884; Mon, 26 Sep 2022 13:24:43 -0700 (PDT) MIME-Version: 1.0 References: <060F7695-D48E-413C-9501-54ECC651ABEB@cable.comcast.com> <07C46DD5-7359-410E-8820-82B319944618@alum.mit.edu> <00fb11bb-74cc-6512-a890-6a4a6efcaa4f@candelatech.com> In-Reply-To: <00fb11bb-74cc-6512-a890-6a4a6efcaa4f@candelatech.com> From: Bruce Perens Date: Mon, 26 Sep 2022 13:24:33 -0700 Message-ID: To: Ben Greear Cc: Dave Taht via Starlink Content-Type: multipart/alternative; boundary="0000000000006d1eaf05e99a51ee" Subject: Re: [Starlink] It's still the starlink latency... X-BeenThere: starlink@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Starlink has bufferbloat. Bad." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Sep 2022 20:24:45 -0000 --0000000000006d1eaf05e99a51ee Content-Type: text/plain; charset="UTF-8" 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. --0000000000006d1eaf05e99a51ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Sep 26, 2022 at 1:14 PM Ben Greea= r via Starlink <starli= nk@lists.bufferbloat.net> wrote:
=20 =20 =20
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=C2=A0that call to inaction :-) = . I can certainly see the problem on my Starlink connection, and can classi= fy the degradation of=C2=A0 performance under load that should not be there= . It's insufficient for a low latency video call, which I think is an e= asy definition of a lowest-common-denominator for anything involving vehicl= e control.

And if you want to propose some solution, then define the metrics of that solution.=C2=A0 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.=C2=A0 And/or, what mitigati= on
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 co= uld put together numbers.
=C2=A0
I know that Dave & crew have made some improvements to the wifi stack, but it is far from
solved even today.=C2=A0 Maybe effort is better done on wifi where developers that are not @spacex
can actually make changes and test results.

This does seem t= o be a call to inaction, doesn't it? Dave and Co. have been working on = WiFi for quite some time and have good papers.=C2=A0
--0000000000006d1eaf05e99a51ee--