From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [148.163.129.52]) (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 C27DE3B29E for ; Mon, 26 Sep 2022 16:47:36 -0400 (EDT) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us1.ppe-hosted.com (unknown [10.7.67.131]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id BA2CE1C0085; Mon, 26 Sep 2022 20:47:34 +0000 (UTC) Received: from mail3.candelatech.com (mail2.candelatech.com [208.74.158.173]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTP id 7C6BA980066; Mon, 26 Sep 2022 20:47:34 +0000 (UTC) Received: from [192.168.100.195] (50-251-239-81-static.hfc.comcastbusiness.net [50.251.239.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail3.candelatech.com (Postfix) with ESMTPSA id 19C5A13C2B0; Mon, 26 Sep 2022 13:47:34 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail3.candelatech.com 19C5A13C2B0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=candelatech.com; s=default; t=1664225254; bh=EqlWMdHlvA6pQdYwHC7RSjnpR3RXcpsD5OeQd6Yv9tw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=qKi7rQuoF2DtcdWg5lHzL4FLS9xgz5Zj5Q1xJztWOFQ+S2K3oatVBB37x7XBbwQLD NLuA+MRCwOZvAwbDUCAWEHdrQsFtZFQEFPQfOmLV32qN4fr1uW55ERfkiYwGPvGZ4y Tq354WzDxqWBfS2kOtsa9uXmmgMKHRtvlI/nacTA= To: Bruce Perens Cc: Dave Taht via Starlink References: <060F7695-D48E-413C-9501-54ECC651ABEB@cable.comcast.com> <07C46DD5-7359-410E-8820-82B319944618@alum.mit.edu> <00fb11bb-74cc-6512-a890-6a4a6efcaa4f@candelatech.com> From: Ben Greear Organization: Candela Technologies Message-ID: <4cc8ce11-ccf2-6bc7-0cc6-977981fa0399@candelatech.com> Date: Mon, 26 Sep 2022 13:47:33 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-MDID: 1664225255-ZVF4DXONBhi5 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:47:36 -0000 On 9/26/22 1:24 PM, Bruce Perens wrote: > On Mon, Sep 26, 2022 at 1:14 PM Ben Greear via Starlink > 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 Candela Technologies Inc http://www.candelatech.com