From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 03F8A3B29E for ; Mon, 26 Sep 2022 17:28:52 -0400 (EDT) Received: by mail-pf1-x42b.google.com with SMTP id a80so7962870pfa.4 for ; Mon, 26 Sep 2022 14:28:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=yoPaiNpeZzD7SVEZb47AchjImk6CYdgKgXWzm+kM4uA=; b=S1I95UIubAnZINsErw5YHT4CwZtRdzaV2U4vuWijVrbjVx1qzW6lCBR1In0NM+RWcH cY+xukH7kbsHTDeM9ifdeHXB6RpTTx0DW400TgBL67P7bnVATeCvitS9kUKehy8fEsKU Lw59rfP2FuGNIeCeyDAx4gGaFOZiXaqUkMX5fGwHq4eN61tHwe4xeoksN0QDtj5ijWPd w2FSko+9MXIAU/XEOKRJEejfgIlhSiJc0fWFewYjXlsjJjE5Ls4yDgYSnAbGiM5NH5dC Y/EaRuXNqk6nEOLpolK4GmU+QuTbKStNlc2M57wpv7aqfcs9t5WsTZ8RwzuH3AeIEJnV dmMA== 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=yoPaiNpeZzD7SVEZb47AchjImk6CYdgKgXWzm+kM4uA=; b=mtySmEITwJ2SZqWP1q5pd0tikyNs98RkSKJRJ8JkhTC8Y4i9QEG/5CjotnIo3UH3Aj R2f8dB78pA/4FbqmRcNwtVP1UcMjh+htqmbkmX8JTqGbeT+bet34tFcCD+PNb5pwKA2t jFeawzeBX/3f0EO2aNuBKWZ8Y0/bPy6gxCw52ilS0cCm3lYpOF6ey8KKTpCeBEClXKFP v2e5PJGCNOYKG5w7mSyoKNAn+LUU3iPTvB0im8bhcLlJfdYu3B6ih0tfJZDUhnZa0Epf NRJBHYKA2oWxB34E06znge/KXGhvFGgkOJnhyOABt0FAX3WZdlrgxIEDEt8WKu7EF8P9 hFAQ== X-Gm-Message-State: ACrzQf1NNznRj4A57jBUMknSWBVVTdt1gQ2iTMBrOU6kCD/8oCB94Otw MD3vKFtlAl9U+hXhX7xa02sWjgHOZhUdDyqZOg== X-Google-Smtp-Source: AMsMyM5lRjErgrNmvzQo7ANvIrEzn+b2F7QPt+fefC7p3TO19eru6DGaSuvTrRvRZzJIdanda4/WnqMCE05zE4+WpOE= X-Received: by 2002:a62:198f:0:b0:554:f1c2:d487 with SMTP id 137-20020a62198f000000b00554f1c2d487mr25197211pfz.30.1664227730102; Mon, 26 Sep 2022 14:28:50 -0700 (PDT) MIME-Version: 1.0 References: <060F7695-D48E-413C-9501-54ECC651ABEB@cable.comcast.com> <07C46DD5-7359-410E-8820-82B319944618@alum.mit.edu> <39E525B8-D356-4F76-82FF-F1F0B3183908@ieee.org> <498p2p23-on1q-op89-p518-1874r3r6rpo@ynat.uz> In-Reply-To: From: warren ponder Date: Mon, 26 Sep 2022 14:28:39 -0700 Message-ID: To: Dave Taht Cc: Eugene Y Chang , Dave Taht via Starlink Content-Type: multipart/alternative; boundary="000000000000ada07805e99b36f4" 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 21:28:53 -0000 --000000000000ada07805e99b36f4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dave what do you need in order to add sites to the data collection. Feel free to reply separate or link to a previous thread Thx WP On Mon, Sep 26, 2022, 2:10 PM Dave Taht via Starlink < starlink@lists.bufferbloat.net> wrote: > I tend to cite rfc7567 (published 2015) a lot, which replaces rfc2309 > (published 1992!). > > Thing is, long before that, I'd come to the conclusion that fair > queuing was a requirement for > sustaining the right throughput for low rate flows in wildly variable > bandwidth. At certain places in > LTE/5g/starlink networks the payload is encrypted and the header info > required unavailable, and my advocacy of fq is certainly not shared by > everyone. > > We don't know enough about the actual points of congestion in starlink > to know if fq could be applied, > and although aqm is a very good idea everywhere, is also largely > undeployed where it would matter most. > > I focused my initial analysis of starlink on just uplink congestion, > which I believe can be easily improved given about 20 minutes with a > cross compiler for the dishy. We have a very good proof of concept as > to how to improve starlinks behavior over here: > https://forum.openwrt.org/t/cake-w-adaptive-bandwidth/135379/87 and > ironically the same script could be run on their router as it is based > on a 6 year old version of openwrt in the first place. > > I have plenty of data later than this ( > > https://docs.google.com/document/d/1puRjUVxJ6cCv-rgQ_zn-jWZU9ae0jZbFATLf4= PQKblM/edit > ) but I would like to be collecting it from at least six sites around > the world. > > On Mon, Sep 26, 2022 at 1:54 PM Eugene Y Chang via Starlink > wrote: > > > > Ok, we are getting into the details. I agree. > > > > Every node in the path has to implement this to be effective. > > In fact, every node in the path has to have the same prioritization or > the scheme becomes ineffective. > > > > Gene > > ---------------------------------------------- > > Eugene Chang > > IEEE Senior Life Member > > eugene.chang@ieee.org > > 781-799-0233 (in Honolulu) > > > > > > > > On Sep 26, 2022, at 10:48 AM, David Lang wrote: > > > > software updates can do far more than just improve recovery. > > > > In practice, large data transfers are less sensitive to latency than > smaller data transfers (i.e. downloading a CD image vs a video conference= ), > software can ensure better fairness in preventing a bulk transfer from > hurting the more latency sensitive transfers. > > > > (the example below is not completely accurate, but I think it gets the > point across) > > > > When buffers become excessivly large, you have the situation where a > video call is going to generate a small amount of data at a regular > interval, but a bulk data transfer is able to dump a huge amount of data > into the buffer instantly. > > > > If you just do FIFO, then you get a small chunk of video call, then > several seconds worth of CD transfer, followed by the next small chunk of > the video call. > > > > But the software can prevent the one app from hogging so much of the > connection and let the chunk of video call in sooner, avoiding the impact > to the real time traffic. Historically this has required the admin classi= fy > all traffic and configure equipment to implement different treatment base= d > on the classification (and this requires trust in the classification > process), the bufferbloat team has developed options (fq_codel and cake) > that can ensure fairness between applications/servers with little or no > configuration, and no trust in other systems to properly classify their > traffic. > > > > The one thing that Cake needs to work really well is to be able to know > what the data rate available is. With Starlink, this changes frequently a= nd > cake integrated into the starlink dish/router software would be far bette= r > than anything that can be done externally as the rate changes can be fed > directly into the settings (currently they are only indirectly detected) > > > > David Lang > > > > > > On Mon, 26 Sep 2022, Eugene Y Chang via Starlink wrote: > > > > You already know this. Bufferbloat is a symptom and not the cause. > Bufferbloat grows when there are (1) periods of low or no bandwidth or (2= ) > periods of insufficient bandwidth (aka network congestion). > > > > If I understand this correctly, just a software update cannot make > bufferbloat go away. It might improve the speed of recovery (e.g. throw > away all time sensitive UDP messages). > > > > Gene > > ---------------------------------------------- > > Eugene Chang > > IEEE Senior Life Member > > eugene.chang@ieee.org > > 781-799-0233 (in Honolulu) > > > > > > > > On Sep 26, 2022, at 10:04 AM, Bruce Perens 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: > > Open Source luminary Bruce Perens said: sometimes Starlink's latency an= d > 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=E2=80=99t understand why latency matte= rs. They > don=E2=80=99t see it or feel it=E2=80=99s 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=E2=80=99t k= now how > to =E2=80=9Csee=E2=80=9D the impact. > > > > Second, there needs to be a =E2=80=9COMG, I have been seeing the action= of > latency all this time and never knew it! I was being shafted.=E2=80=9D On= ce you > have this awakening, you can get all the press you want for free. > > > > Most of the time when business apps are developed, =E2=80=9Cwe=E2=80=9D= hide the impact > of poor performance (aka latency) or they hide from the discussion becaus= e > the developers don=E2=80=99t have a way to fix the latency. Maybe busines= ses don=E2=80=99t > 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= =E2=80=99t > know that latency is hurting them. Unfair but most people don=E2=80=99t k= now the > issue is latency. > > > > Talking and explaining why latency is bad is not as effective as showin= g > 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 < > 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 writ= e, > 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 Milita= ry > 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 > > > > wrote: > > > > > > The awareness & understanding of latency & impact on QoE is nearly > unknown among reporters. IMO maybe there should be some kind of backgroun= d > briefings for reporters - maybe like a simple YouTube video explainer tha= t > 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? > > > > > > =EF=BB=BFOn 9/21/22, 14:35, "Starlink on behalf of Dave Taht via Starli= nk" < > starlink-bounces@lists.bufferbloat.net 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/< > https://blog.cerowrt.org/post/state_of_fq_codel/> > > Dave T=C3=A4ht CEO, TekLibre, LLC > > > > > > > > > > -- > > FQ World Domination pending: > https://blog.cerowrt.org/post/state_of_fq_codel/< > https://blog.cerowrt.org/post/state_of_fq_codel/> > > Dave T=C3=A4ht CEO, TekLibre, LLC > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink < > https://lists.bufferbloat.net/listinfo/starlink> > > > > > > -- > > Bruce Perens K6BP > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink < > https://lists.bufferbloat.net/listinfo/starlink> > > > > > > > > > > -- > > Bruce Perens K6BP > > > > > > _______________________________________________ > > Starlink mailing list > > Starlink@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/starlink > > > > -- > FQ World Domination pending: > https://blog.cerowrt.org/post/state_of_fq_codel/ > Dave T=C3=A4ht CEO, TekLibre, LLC > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --000000000000ada07805e99b36f4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dave what do you need in order to add sites to the data c= ollection. Feel free to reply separate or link to a previous thread

Thx

WP

On Mon, Sep 26, 2022, 2:10 PM Dave Taht via S= tarlink <starlink@list= s.bufferbloat.net> wrote:
I = tend to cite rfc7567 (published 2015) a lot, which replaces rfc2309
(published 1992!).

Thing is, long before that, I'd come to the conclusion that fair
queuing was a requirement for
sustaining the right throughput for low rate flows in wildly variable
bandwidth. At certain places in
LTE/5g/starlink networks the payload is encrypted and the header info
required unavailable, and my advocacy of fq is certainly not shared by
everyone.

We don't know enough about the actual points of congestion in starlink<= br> to know if fq could be applied,
and although aqm is a very good idea everywhere, is also largely
undeployed where it would matter most.

I focused my initial analysis of starlink on just uplink congestion,
which I believe can be easily improved given about 20 minutes with a
cross compiler for the dishy. We have a very good proof of concept as
to how to improve starlinks behavior over here:
https://forum.openwrt.org/= t/cake-w-adaptive-bandwidth/135379/87 and
ironically the same script could be run on their router as it is based
on a 6 year old version of openwrt in the first place.

I have plenty of data later than this (
https= ://docs.google.com/document/d/1puRjUVxJ6cCv-rgQ_zn-jWZU9ae0jZbFATLf4PQKblM/= edit
) but I would like to be collecting it from at least six sites around
the world.

On Mon, Sep 26, 2022 at 1:54 PM Eugene Y Chang via Starlink
<starlink@lists.bufferbloat.net> wrote:
>
> Ok, we are getting into the details. I agree.
>
> Every node in the path has to implement this to be effective.
> In fact, every node in the path has to have the same prioritization or= the scheme becomes ineffective.
>
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Senior Life Member
> eugene.chang@ieee.org
> 781-799-0233 (in Honolulu)
>
>
>
> On Sep 26, 2022, at 10:48 AM, David Lang <david@lang.hm> wrote: >
> software updates can do far more than just improve recovery.
>
> In practice, large data transfers are less sensitive to latency than s= maller data transfers (i.e. downloading a CD image vs a video conference), = software can ensure better fairness in preventing a bulk transfer from hurt= ing the more latency sensitive transfers.
>
> (the example below is not completely accurate, but I think it gets the= point across)
>
> When buffers become excessivly large, you have the situation where a v= ideo call is going to generate a small amount of data at a regular interval= , but a bulk data transfer is able to dump a huge amount of data into the b= uffer instantly.
>
> If you just do FIFO, then you get a small chunk of video call, then se= veral seconds worth of CD transfer, followed by the next small chunk of the= video call.
>
> But the software can prevent the one app from hogging so much of the c= onnection and let the chunk of video call in sooner, avoiding the impact to= the real time traffic. Historically this has required the admin classify a= ll traffic and configure equipment to implement different treatment based o= n the classification (and this requires trust in the classification process= ), the bufferbloat team has developed options (fq_codel and cake) that can = ensure fairness between applications/servers with little or no configuratio= n, and no trust in other systems to properly classify their traffic.
>
> The one thing that Cake needs to work really well is to be able to kno= w what the data rate available is. With Starlink, this changes frequently a= nd cake integrated into the starlink dish/router software would be far bett= er than anything that can be done externally as the rate changes can be fed= directly into the settings (currently they are only indirectly detected) >
> David Lang
>
>
> On Mon, 26 Sep 2022, Eugene Y Chang via Starlink wrote:
>
> You already know this. Bufferbloat is a symptom and not the cause. Buf= ferbloat grows when there are (1) periods of low or no bandwidth or (2) per= iods of insufficient bandwidth (aka network congestion).
>
> If I understand this correctly, just a software update cannot make buf= ferbloat go away. It might improve the speed of recovery (e.g. throw away a= ll time sensitive UDP messages).
>
> Gene
> ----------------------------------------------
> Eugene Chang
> IEEE Senior Life Member
> eugene.chang@ieee.org
> 781-799-0233 (in Honolulu)
>
>
>
> On Sep 26, 2022, at 10:04 AM, Bruce Perens <bruce@perens.com> = wrote:
>
> Please help to explain. Here's a draft to start with:
>
> Starlink Performance Not Sufficient for Military Applications, Say Sci= entists
>
> The problem is not availability: Starlink works where nothing but anot= her satellite network would. It's not bandwidth, although others have q= uestions about sustaining bandwidth as the customer base grows. It's la= tency and jitter. As load increases, latency, the time it takes for a packe= t to get through, increases more than it should. The scientists who have fo= ught bufferbloat, a major cause of latency on the internet, know why. Space= X needs to upgrade their system to use the scientist's Open Source modi= fications to Linux to fight bufferbloat, and thus reduce latency. This is m= ostly just using a newer version, but there are some tunable parameters. Ji= tter is a change in the speed of getting a packet through the network durin= g a connection, which is inevitable in satellite networks, but will be impr= oved 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 upgra= ding their software, said scientist Dave Taht. Jim Gettys, Taht's colla= borator and creator of the X Window System, chimed in: <fill in here ple= ase>
> Open Source luminary Bruce Perens said: sometimes Starlink's laten= cy and jitter make it inadequate to remote-control my ham radio station. Bu= t the military is experimenting with remote-control of vehicles on the batt= lefield and other applications that can be demonstrated, but won't happ= en at scale without adoption of bufferbloat-fighting strategies.
>
> On Mon, Sep 26, 2022 at 12:59 PM Eugene Chang <eugene.chang@= alum.mit.edu<mailto:eugene.chang@alum.mit.edu>> wro= te:
> The key issue is most people don=E2=80=99t understand why latency matt= ers. They don=E2=80=99t see it or feel it=E2=80=99s impact.
>
> First, we have to help people see the symptoms of latency and how it i= mpacts 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=E2=80=99t = know how to =E2=80=9Csee=E2=80=9D the impact.
>
> Second, there needs to be a =E2=80=9COMG, I have been seeing the actio= n of latency all this time and never knew it! I was being shafted.=E2=80=9D= Once you have this awakening, you can get all the press you want for free.=
>
> Most of the time when business apps are developed, =E2=80=9Cwe=E2=80= =9D hide the impact of poor performance (aka latency) or they hide from the= discussion because the developers don=E2=80=99t have a way to fix the late= ncy. Maybe businesses don=E2=80=99t care because any employees affected are= just considered poor performers. (In bad economic times, the poor performe= rs are just laid off.) For employees, if they happen to be at a location wi= th bad latency, they don=E2=80=99t know that latency is hurting them. Unfai= r but most people don=E2=80=99t know the issue is latency.
>
> Talking and explaining why latency is bad is not as effective as showi= ng why latency is bad. Showing has to be with something that has a person i= mpact.
>
> Gene
> -----------------------------------
> Eugene Chang
> eugene.chang@alum.mit.edu <mailto:eugene.chang@al= um.mit.edu>
> +1-781-799-0233 (in Honolulu)
>
>
>
>
>
> On Sep 26, 2022, at 6:32 AM, Bruce Perens via Starlink <starlink@lists.bufferbloat.net<mailto:starlink@lists.bu= fferbloat.net>> wrote:
>
> If you want to get attention, you can get it for free. I can place art= icles 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, sig= n, and publish a statement. What they actually write is less relevant if th= ey 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 Militar= y 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. B= eing able to say this isn't ready for the government's application = would be an attention-getter.
>
>=C2=A0 =C2=A0 Thanks
>
>=C2=A0 =C2=A0 Bruce
>
> On Mon, Sep 26, 2022 at 9:21 AM Dave Taht via Starlink <starlink@lists.bufferbloat.net<mailto:starlink@lists.bu= fferbloat.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!&quo= t;,
> 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= <mailto:dave.taht@gmail.com>> wrote:
>
>
> On Mon, Sep 26, 2022 at 8:20 AM Livingood, Jason
> <Jason_Livingood@comcast.com <mailto:Jason= _Livingood@comcast.com>> wrote:
>
>
> The awareness & understanding of latency & impact on QoE is ne= arly unknown among reporters. IMO maybe there should be some kind of backgr= ound 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?
>
>
> =EF=BB=BFOn 9/21/22, 14:35, "Starlink on behalf of Dave Taht via = Starlink" <starlink-bounces@lists.bufferbloat.n= et <mailto:starlink-bounces@lists.bufferbloat.ne= t> on behalf of starlink@lists.bufferbloat.net <m= ailto:starlink@lists.bufferbloat.net>> wrote:
>
>=C2=A0 =C2=A0 I still find it remarkable that reporters are still missi= ng the
>=C2=A0 =C2=A0 meaning of the huge latencies for starlink, under load. >
>
>
>
> --
> FQ World Domination pending: https:/= /blog.cerowrt.org/post/state_of_fq_codel/<https://blog.cerowrt.org/post/state_of_fq_codel/>
> Dave T=C3=A4ht CEO, TekLibre, LLC
>
>
>
>
> --
> FQ World Domination pending: https:/= /blog.cerowrt.org/post/state_of_fq_codel/<https://blog.cerowrt.org/post/state_of_fq_codel/>
> Dave T=C3=A4ht CEO, TekLibre, LLC
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net <mailto:= Starlink@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinf= o/starlink <https://lists.bufferblo= at.net/listinfo/starlink>
>
>
> --
> Bruce Perens K6BP
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net <mailto:= Starlink@lists.bufferbloat.net>
> https://lists.bufferbloat.net/listinf= o/starlink <https://lists.bufferblo= at.net/listinfo/starlink>
>
>
>
>
> --
> Bruce Perens K6BP
>
>
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinf= o/starlink



--
FQ World Domination pending: https://blog= .cerowrt.org/post/state_of_fq_codel/
Dave T=C3=A4ht CEO, TekLibre, LLC
_______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/sta= rlink
--000000000000ada07805e99b36f4--