From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.183]) (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 BF7C63B29E for ; Mon, 26 Sep 2022 16:14:41 -0400 (EDT) X-Virus-Scanned: Proofpoint Essentials engine Received: from mx1-us1.ppe-hosted.com (unknown [10.110.51.17]) by mx1-us1.ppe-hosted.com (PPE Hosted ESMTP Server) with ESMTPS id 938991A007B for ; Mon, 26 Sep 2022 20:14:39 +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 535BB680089 for ; Mon, 26 Sep 2022 20:14:39 +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 C433E13C2B0 for ; Mon, 26 Sep 2022 13:14:38 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 mail3.candelatech.com C433E13C2B0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=candelatech.com; s=default; t=1664223278; bh=P3Ifflsbepm/9RO74J/vUOGh1nqcAHKIR8uWWyMpsQY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=OpzXaiJ07Mr9J6J4YLOEj2zKXCYl31VkkHmHWU7SnVmbClLxR+zCTdcl2gARzRovg KUbnjkM9fKmvuwFcPHc6jogwMz3ZLziGCo1FrurlxvTCpmLRYUeGNHdL8hKpZ3rlzW 07g83SCNygbAYroKWyoiCC55YJ2O8c6D76gVzQw0= To: starlink@lists.bufferbloat.net References: <060F7695-D48E-413C-9501-54ECC651ABEB@cable.comcast.com> <07C46DD5-7359-410E-8820-82B319944618@alum.mit.edu> From: Ben Greear Organization: Candela Technologies Message-ID: <00fb11bb-74cc-6512-a890-6a4a6efcaa4f@candelatech.com> Date: Mon, 26 Sep 2022 13:14:38 -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: multipart/alternative; boundary="------------3122BF0B15CE08B69A288C5C" Content-Language: en-US X-MDID: 1664223280-Vi6GH_IXeT86 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:14:41 -0000 This is a multi-part message in MIME format. --------------3122BF0B15CE08B69A288C5C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I think that engineers telling other engineers (military) that something isn't sufficient is making a lot of assumptions that should not be made. 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. 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. Thanks, Ben On 9/26/22 1:04 PM, Bruce Perens via Starlink wrote: > Please help to explain. Here's a draft to start with: > > *Starlink Performance Not Sufficient for Military Applications, Say Scientists* > > The problem is not availability: Starlink works where nothing but another satellite network would. It's not bandwidth, although others have questions about > sustaining bandwidth as the customer base grows. It's /latency/ and /jitter. A/s load increases, latency, the time it takes for a packet to get through, > increases more than it should. The scientists who have fought /bufferbloat, /a major cause of latency on the internet, know why. SpaceX needs to upgrade their > system to use the scientist's Open Source modifications to Linux to fight bufferbloat, and thus reduce latency. This is mostly just using a newer version, but > there are some tunable parameters. Jitter is a /change/ in the speed of getting a packet through the network during a connection, which is inevitable in > satellite networks, but will be improved by making use of the bufferbloat-fighting software, and probably with the addition of more satellites. > > /We've done all of the work, SpaceX just needs to adopt it by upgrading their software, /said scientist Dave Taht. Jim Gettys, Taht's collaborator and creator > of the X Window System, chimed in: > Open Source luminary Bruce Perens said: /sometimes Starlink's latency and jitter make it inadequate to remote-control my ham radio station. But the military > is experimenting with remote-control of vehicles on the battlefield and other applications that can be demonstrated, but won't happen at *scale* without > adoption of bufferbloat-fighting strategies./ > > On Mon, Sep 26, 2022 at 12:59 PM Eugene Chang > wrote: > > The key issue is most people don’t understand why latency matters. They don’t see it or feel it’s impact. > > First, we have to help people see the symptoms of latency and how it impacts something they care about. > - gamers care but most people may think it is frivolous. > - musicians care but that is mostly for a hobby. > - business should care because of productivity but they don’t know how to “see” the impact. > > Second, there needs to be a “OMG, I have been seeing the action of latency all this time and never knew it! I was being shafted.” Once you have this > awakening, you can get all the press you want for free. > > Most of the time when business apps are developed, “we” hide the impact of poor performance (aka latency) or they hide from the discussion because the > developers don’t have a way to fix the latency. Maybe businesses don’t care because any employees affected are just considered poor performers. (In bad > economic times, the poor performers are just laid off.) For employees, if they happen to be at a location with bad latency, they don’t know that latency > is hurting them. Unfair but most people don’t know the issue is latency. > > Talking and explaining why latency is bad is not as effective as showing why latency is bad. Showing has to be with something that has a person impact. > > Gene > ----------------------------------- > Eugene Chang > eugene.chang@alum.mit.edu > +1-781-799-0233(in Honolulu) > > > > > >> On Sep 26, 2022, at 6:32 AM, Bruce Perens via Starlink > wrote: >> >> If you want to get attention, you can get it for free. I can place articles with various press if there is something interesting to say. Did this all >> through the evangelism of Open Source. All we need to do is write, sign, and publish a statement. What they actually write is less relevant if they >> publish a link to our statement. >> >> Right now I am concerned that the Starlink latency and jitter is going to be a problem even for remote controlling my ham station. The US Military is >> interested in doing much more, which they have demonstrated, but I don't see happening /at scale /without some technical work on the network. Being able >> to say this isn't ready for the government's application would be an attention-getter. >> >>     Thanks >> >>     Bruce >> >> On Mon, Sep 26, 2022 at 9:21 AM Dave Taht via Starlink > wrote: >> >> These days, if you want attention, you gotta buy it. A 50k half page >> ad in the wapo or NYT riffing off of It's the latency, Stupid!", >> signed by the kinds of luminaries we got for the fcc wifi fight, would >> go a long way towards shifting the tide. >> >> On Mon, Sep 26, 2022 at 8:29 AM Dave Taht > wrote: >> > >> > On Mon, Sep 26, 2022 at 8:20 AM Livingood, Jason >> > > wrote: >> > > >> > > The awareness & understanding of latency & impact on QoE is nearly unknown among reporters. IMO maybe there should be some kind of background >> briefings for reporters - maybe like a simple YouTube video explainer that is short & high level & visual? Otherwise reporters will just continue to >> focus on what they know... >> > >> > That's a great idea. I have visions of crashing the washington >> > correspondents dinner, but perhaps >> > there is some set of gatherings journalists regularly attend? >> > >> > > >> > > On 9/21/22, 14:35, "Starlink on behalf of Dave Taht via Starlink" > on behalf of starlink@lists.bufferbloat.net > wrote: >> > > >> > >     I still find it remarkable that reporters are still missing the >> > >     meaning of the huge latencies for starlink, under load. >> > > >> > > >> > >> > >> > -- >> > FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ >> >> > Dave Täht CEO, TekLibre, LLC >> >> >> >> -- >> FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ >> >> Dave Täht CEO, TekLibre, LLC >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink >> >> >> >> >> -- >> Bruce Perens K6BP >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink >> > > > > -- > Bruce Perens K6BP > > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink -- Ben Greear Candela Technologies Inc http://www.candelatech.com --------------3122BF0B15CE08B69A288C5C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
I think that engineers telling other engineers (military) that something isn't
sufficient is making a lot of assumptions that should not be made.

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.

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.

Thanks,
Ben


On 9/26/22 1:04 PM, Bruce Perens via Starlink wrote:
Please help to explain. Here's a draft to start with:

Starlink Performance Not Sufficient for Military Applications, Say Scientists

The problem is not availability: Starlink works where nothing but another satellite network would. It's not bandwidth, although others have questions about sustaining bandwidth as the customer base grows. It's latency and jitter. As load increases, latency, the time it takes for a packet to get through, increases more than it should. The scientists who have fought bufferbloat, a major cause of latency on the internet, know why. SpaceX needs to upgrade their system to use the scientist's Open Source modifications to Linux to fight bufferbloat, and thus reduce latency. This is mostly just using a newer version, but there are some tunable parameters. Jitter is a change in the speed of getting a packet through the network during a connection, which is inevitable in satellite networks, but will be improved by making use of the bufferbloat-fighting software, and probably with the addition of more satellites.

We've done all of the work, SpaceX just needs to adopt it by upgrading their software, said scientist Dave Taht. Jim Gettys, Taht's collaborator and creator of the X Window System, chimed in: <fill in here please>
Open Source luminary Bruce Perens said: sometimes Starlink's latency and jitter make it inadequate to remote-control my ham radio station. But the military is experimenting with remote-control of vehicles on the battlefield and other applications that can be demonstrated, but won't happen at scale without adoption of bufferbloat-fighting strategies.

On Mon, Sep 26, 2022 at 12:59 PM Eugene Chang <eugene.chang@alum.mit.edu> wrote:
The key issue is most people don’t understand why latency matters. They don’t see it or feel it’s impact. 

First, we have to help people see the symptoms of latency and how it impacts something they care about.
- gamers care but most people may think it is frivolous.
- musicians care but that is mostly for a hobby.
- business should care because of productivity but they don’t know how to “see” the impact.

Second, there needs to be a “OMG, I have been seeing the action of latency all this time and never knew it! I was being shafted.” Once you have this awakening, you can get all the press you want for free.

Most of the time when business apps are developed, “we” hide the impact of poor performance (aka latency) or they hide from the discussion because the developers don’t have a way to fix the latency. Maybe businesses don’t care because any employees affected are just considered poor performers. (In bad economic times, the poor performers are just laid off.) For employees, if they happen to be at a location with bad latency, they don’t know that latency is hurting them. Unfair but most people don’t know the issue is latency. 

Talking and explaining why latency is bad is not as effective as showing why latency is bad. Showing has to be with something that has a person impact. 

Gene
-----------------------------------
Eugene Chang
+1-781-799-0233 (in Honolulu)





On Sep 26, 2022, at 6:32 AM, Bruce Perens via Starlink <starlink@lists.bufferbloat.net> wrote:

If you want to get attention, you can get it for free. I can place articles with various press if there is something interesting to say. Did this all through the evangelism of Open Source. All we need to do is write, sign, and publish a statement. What they actually write is less relevant if they publish a link to our statement.

Right now I am concerned that the Starlink latency and jitter is going to be a problem even for remote controlling my ham station. The US Military is interested in doing much more, which they have demonstrated, but I don't see happening at scale without some technical work on the network. Being able to say this isn't ready for the government's application would be an attention-getter.

    Thanks

    Bruce

On Mon, Sep 26, 2022 at 9:21 AM Dave Taht via Starlink <starlink@lists.bufferbloat.net> wrote:
These days, if you want attention, you gotta buy it. A 50k half page
ad in the wapo or NYT riffing off of It's the latency, Stupid!",
signed by the kinds of luminaries we got for the fcc wifi fight, would
go a long way towards shifting the tide.

On Mon, Sep 26, 2022 at 8:29 AM Dave Taht <dave.taht@gmail.com> wrote:
>
> On Mon, Sep 26, 2022 at 8:20 AM Livingood, Jason
> <Jason_Livingood@comcast.com> wrote:
> >
> > The awareness & understanding of latency & impact on QoE is nearly unknown among reporters. IMO maybe there should be some kind of background briefings for reporters - maybe like a simple YouTube video explainer that is short & high level & visual? Otherwise reporters will just continue to focus on what they know...
>
> That's a great idea. I have visions of crashing the washington
> correspondents dinner, but perhaps
> there is some set of gatherings journalists regularly attend?
>
> >
> > On 9/21/22, 14:35, "Starlink on behalf of Dave Taht via Starlink" <starlink-bounces@lists.bufferbloat.net on behalf of starlink@lists.bufferbloat.net> wrote:
> >
> >     I still find it remarkable that reporters are still missing the
> >     meaning of the huge latencies for starlink, under load.
> >
> >
>
>
> --
> FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
> Dave Täht CEO, TekLibre, LLC



--
FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/
Dave Täht CEO, TekLibre, LLC
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink


--
Bruce Perens K6BP
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink



--
Bruce Perens K6BP

_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink



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