From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 A112D3CB37 for ; Wed, 8 May 2024 03:59:10 -0400 (EDT) Received: by mail-qt1-x82d.google.com with SMTP id d75a77b69052e-43ddc01685aso383201cf.2 for ; Wed, 08 May 2024 00:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1715155150; x=1715759950; darn=lists.bufferbloat.net; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cRBLIUld1iStYH3S8IbyuhLSg32jDwwTAwyfffx2X2E=; b=Ok+lHMZFLYWQ2ivrsYkLY/zEo4VyKMf3pcZcOV16d0PoZEFCBDKNhb9C+u7LKEBD0X 6bvY7FOFee7GZKY71oZs/hZ6ReuFqDMx7zSpKcVzioU5a8DVOsYhXitfRp5SDdVgOkX5 nTOX8roD6Zf3Ygtd5TYD0tGHRBRS8R1HihDN6ZRK8NnJ7epAkxjtB+sKPWeecLv58dZz RV84eRLQW7M/YKnQINDt9XphVf+mplahDVXOJTumI4PfZULrT/KbUWvMITAv83SmJ1eO 22YWCa7R6DsGAqF7ImipJAq+Smf8KI8NNq2BrWBLKIlo7XHlYCXel+1I28T77c42sm3+ 9Vmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715155150; x=1715759950; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=cRBLIUld1iStYH3S8IbyuhLSg32jDwwTAwyfffx2X2E=; b=uKiCVnqfFH2xbFLV8D2uNvvMe/kO0O4uQYc5vqSEuMQJJKRx9gzrkzQtcUR+r+LgGt j2/SBiKWvkheWtK5jlg9FC/FbSOpl2sPaA2FwgGOE0XoyZADGEs1b6pATEMP0wrJIyJR uGxF3+gy6vKF3L9/gfZtwW9aRlTquSEuquUh4jZiXsgzD73VM9rkJ2LICitEHIF0oRdB riAkLziP7+iF/u11zPFA5YOcA15OD3AWEp7DRk5lfH0RUOFxt74EBto5BXVwIO9tQuPM n7I1C1I3FVDC9WPicyh4J09eZVtxPrtbcMGpLOptMQ3VAho/Tv6USDD68Zu/0FczJOCq uIqw== X-Gm-Message-State: AOJu0Yzodm0svArFRLIa3LYaKsBzT3arOvBNUVIqcZfH26hzMKVcUJ1i K41kILXdAL+TJmbAyGyKNr7ue4/FfevGbRwdy/snMJ1KlsmhTEKbo5kTdD3zUaPEuLxJhq5N53H 9/RYEkWMl7as8yGq8zJZdhH8TRFhV0VWAKwI= X-Google-Smtp-Source: AGHT+IHfq61Y9CxyLtLDW4LIEzax4eHeG80+ALGCp44MWaj4caDC4h6wIWXTWjrmkIp3JfmNlkXoTmHZTrCYHD9A1DE= X-Received: by 2002:a05:622a:304:b0:43a:c243:8669 with SMTP id d75a77b69052e-43dbf7516d5mr21748581cf.56.1715155149871; Wed, 08 May 2024 00:59:09 -0700 (PDT) MIME-Version: 1.0 References: <438B1BC4-D465-497A-B6BA-700E1D411036@ieee.org> <79C02ABB-B2A6-4B4D-98F4-6540D3F96EBB@ieee.org> <7E918B58-382A-4793-A144-13A7075CA56C@connectivitycap.com> <13rq2389-9012-p95n-s494-q3pp070s497n@ynat.uz> <6qop2p3o-351p-788q-q1q2-86sosnq3rn21@ynat.uz> <3FF32F52-4A93-496B-85FF-00020FA4A48B@gmx.de> <08F6942E-CC08-4956-B92E-CBEC091D86E4@ieee.org> In-Reply-To: From: Frantisek Borsik Date: Wed, 8 May 2024 09:58:33 +0200 Message-ID: To: Dave Taht via Starlink Cc: Rich Brown , Colin_Higbie , Dave Taht Content-Type: multipart/alternative; boundary="0000000000007163920617ecad3a" Subject: Re: [Starlink] The "reasons" that bufferbloat isn't a problem 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: Wed, 08 May 2024 07:59:10 -0000 --0000000000007163920617ecad3a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to add the latest numbers from our (LibreQoS) ongoing "QoE competitive landscape research": Out of 66k plus ISPs worldwide, barely 3k use some QoE middle-box. Preseem is the market leader, with well over 400 T2 & T3 ISPs (number shared in their wonderful Fixed Wireless Network Report 2024 Q1 Edition ), Bequant seems to be 2nd, in terms of market penetration, claiming 500+ ISPs worldwide. Then we assume Cambium Networks and Paraqum - numbers of their users are not know, but we can expect something similar, in the Preseem and Bequant ballpark. Then there is LibreQoS. All in all, it's safe to say that somewhere between 2,5 and 3 thousand Internet Service Providers worldwide are using QoE middle-box of sort. So barely 2% of the ISPs worldwide are using it, we are still in the "innovator" stage of the whole "crossing the chasm" paradigm. We are all still very early on, working on it, and I'm lovin' it. All the best, Frank Frantisek (Frank) Borsik https://www.linkedin.com/in/frantisekborsik Signal, Telegram, WhatsApp: +421919416714 iMessage, mobile: +420775230885 Skype: casioa5302ca frantisek.borsik@gmail.com On Wed, May 8, 2024 at 4:16=E2=80=AFAM Dave Taht via Starlink < starlink@lists.bufferbloat.net> wrote: > This was a wonderful post, rich! > > I note that preseem, paraqum, bequant and libreqos (a bufferbloat.net > backed project) are in the fq codel or cake Middlebox for isps *Qoe) mark= et > and all of us have made a substantial dent in the problem for oh, call it > 1000 isps worldwide total between us. Comcast also has done a pretty good > job but it seems yhe rest of the cable industry is asleep at the switch. > > The wisps totally got it with fq codel and cake arriving native for > mikeotiks entire product line and much of ubnts gear prior to that. > > > Qoe is still a pretty hard sell. Libreqos has a ton of free users and we > think over a million devices managed by it but not enough paid users to > justify even 1/10th the investment we have made so far into it (something > that I hope turns around with the upcoming v1.5 lts release and some > outputs from the nlnet and Comcast funded cakemaint and nqb projects) > > Thing is, at higher and fiber rates all the bloat moves to the wifi, and = a > ton of that, like eero especially was long ago fq codeled and so I think > several major players have also (except for those stuck with broadcom). > > That said there are a lot of defective wifi aps left to replace. Nearly > every coffee shop I have been in with the exception of Starbucks has real= ly > lousy wifi. > > I am so thrilled to see what starlink has accomplished so far with their > rollout of bufferbloat.net stuff and look forward to more. They are still > missing a few tricks... but are aware of what tricks they are missing... > > Lack of knowledge of which regrettably remains the case for 97% of the > market and 99.99$ user base. Still ar apps will drive this rventually... = I > think starlink is nicely positioned now to meet their demanding growth > goals and humanity's future in space assured, so there's that. ( i still > would rather like elone to send over a nice pair of tesla motors and > battery pack for my sailboat) > > I did have a nice jam with ajit Pai last week who is now well on his way > towards getting it. (See my twitter for the pics) > > On Mon, May 6, 2024, 4:25=E2=80=AFAM Rich Brown via Starlink < > starlink@lists.bufferbloat.net> wrote: > >> Hi Gene, >> >> I've been vacillating on whether to send this note, but have decided to >> pull the trigger. I apologize in advance for the "Debbie Downer" nature = of >> this message. I also apologize for any errors, omissions, or >> over-simplifications of the "birth of bufferbloat" story and its fixes. >> Corrections welcome. >> >> Rich >> ------ >> >> If we are going to take a shot at opening people's eyes to bufferbloat, >> we should know some of the "objections" we'll run up against. Even thoug= h >> there's terrific technical data to back it up, people seem especially >> resistant to thinking that bufferbloat might affect their network, even >> when they're seeing problems that sound exactly like bufferbloat symptom= s. >> But first, some history: >> >> The very idea of bufferbloat is simply unbelievable. Jim Gettys in 2011 >> [1] couldn't believe it, and he's a smart networking guy,. At the time, = it >> seemed incredible (that is "not credible" =3D=3D impossible) that someth= ing >> could induce 1.2 seconds of latency into his home network connection. He >> called in favors from technical contacts at his ISP and at Bell Labs who >> went over everything with a fine-toothed comb. It was all exactly as >> spec'd. But he still had the latency. >> >> This led Jim and Dave T=C3=A4ht to start the investigation into the phen= omenon >> known today as "bufferbloat" - the undesirable latency that comes from a >> router or other network equipment buffering too much data. Over several >> years, a group of smart people made huge improvements: fq_codel was >> released 14 May 2012 [3]; it was incorporated into the Linux kernel shor= tly >> afterward. CAKE came in 2015, and the fixes that minimize bufferbloat in >> Wi-Fi arrived in 2018. In 2021 cake-autorate [4] arrived to handle varyi= ng >> speed ISP links. All these techniques work great: in 2014, my 7mbps DSL >> link was quite usable. And when the pandemic hit, fq_codel on my OpenWrt >> router allowed me to use that same 7mbps DSL line for two simultaneous z= oom >> calls. >> >> As one of the authors of [2], I am part of the team that has tried over >> the years to explain bufferbloat and how to fix it. We've spoken with >> vendors. We've spent untold hours responding to posts on assorted boards >> and forums with the the bufferbloat story. >> >> With these technical fixes in hand, we cockily set about to tell the >> world about how to fix bufferbloat. Our efforts have been met with >> skepticism at best, or stony silence. What are the objections? >> >> - This is just the ordinary behavior: I would expect things to be slower >> when there's more traffic (Willfully ignoring orders of magnitude increa= se >> in delay.) >> - Besides, I'm the only one using the internet. (Except when my phone >> uploads photos. Or my computer kicks off some automated process. Or I >> browse the web. Or ...) >> - It only happens some of the time. (Exactly. That's probably when >> something's uploading photos, or your computer is doing stuff in the >> background.) >> - Those bufferbloat tests you hear about are bogus. They artificially ad= d >> load, which isn't a realistic test. (...and if you actually are download= ing >> a file?) >> - Bufferbloat only happens when the network is 100% loaded. (True. But >> when you open a web page, your browser briefly uses 100% of the link. Is >> this enough to cause momentary lag?) >> - It's OK. I just tell my kids/spouse not to use the internet when I'm >> gaming. (Huh?) >> - I have gigabit service from my ISP. (That helps, but if you're >> complaining about "slowness" you still need to rule out bufferbloat in y= our >> router.) >> - I can't believe that router manufacturers would ever allow such a thin= g >> to happen in their gear. (See the Jim Gettys story above.) >> - I mean... wouldn't router vendors want to provide the best for their >> customers? (No - implementing this (new-ish) code requires engineering >> effort. They're selling plenty of routers with decade-old software. The >> Boss says, "would we sell more if they made these changes? Probably not.= ") >> - Why would my ISP provision/sell me a router that gave crappy service? >> They're a big company, they must know about this stuff. (Maybe. We have >> reached out to all the vendors. But remember they profit if you decide y= our >> network is too slow and you upgrade to a faster device/plan.) >> - But couldn't I just tweak the QoS on my router? (Maybe. But see [5]) >> - Besides, I just spent $300 on a "gaming router". Obviously, I bought >> the most expensive/best possible solution on the market (But I still hav= e >> lag...) >> - You're telling me that a bunch of pointy-headed academics are smarter >> than commercial router developers - who sold me that $300 router? (I can= 't >> believe it.) >> - And then you say that I should throw away that gaming router and >> install some "open source firmware"? (What the heck is that? And why sho= uld >> I believe you?) >> - What if it doesn't solve the problem? Who will give me support? And ho= w >> will I get back to a vendor-supported system? (Valid point - the first >> valid point) >> - Aren't there any commercial solutions I can just buy? (Not at the >> moment. IQrouter was a shining light here - available from Amazon, simpl= e >> setup, worked a treat - but they have gone out of business. And of cours= e, >> for the skeptic, this is proof that the "fq_codel-stuff" isn't really a >> solution - it seems just like snake oil.) >> >> So... All these hurdles make it hard to convince people that bufferbloat >> could be the problem, or that they can fix for themselves. >> >> A couple of us have reached out to Consumer Reports, wondering if they >> would like a story about how vendors would prefer to sell you a new, fas= ter >> router (or new faster ISP plan) than fix your bufferbloat. This kind of >> story seemed to be straight up their alley, but we never heard back afte= r >> an initial contact. Maybe they deserve another call... >> >> The recent latency results from Starlink give me a modicum of hope. >> They're a major player. They (and their customers) can point to an order= of >> magnitude reduction in latency over other solutions. It still requires >> enough "regular customers" to tell their current ISP that they are >> switching to Starlink (and spend $600 to purchase a Dishy plus $100/mont= h) >> to provide a market incentive. >> >> Despite all this doom and gloom, I remain hopeful that things will get >> better. We know the technology exists for people to take control of thei= r >> network and solve the problem for themselves. We can continue to respond= on >> forums where people express their dismay at the crummy performance and >> suggest a solution. We can hope that a major vendor will twig to this >> effect and bring out a mass-market solution. >> >> I think your suggestion of speaking to eSports people is intriguing. >> They're highly motivated to make their personal networks better. And >> actually solving the problem would have a network effect of bringing in >> others with the same problem. >> >> Good luck, and thanks for thinking about this. >> >> Rich Brown >> >> [1] >> https://courses.cs.washington.edu/courses/cse550/21au/papers/bufferbloat= .pdf >> [2] >> https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Buff= erbloat/ >> [3] >> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.ht= ml >> [4] https://github.com/lynxthecat/cake-autorate >> [5] >> https://www.bufferbloat.net/projects/bloat/wiki/More_about_Bufferbloat/#= what-s-wrong-with-simply-configuring-qos >> >> On May 1, 2024, at 6:19 PM, Eugene Y Chang via Starlink < >> starlink@lists.bufferbloat.net> wrote: >> >> Of course. For the gamers, the focus is managing latency. They have >> control of everything else. >> >> With our high latency and wide range of values, the eSports teams train >> on campus. It will be interesting to see how much improvements there can= be >> for teams to be able to training from their homes. >> >> Gene >> ---------------------------------------------- >> Eugene Chang >> IEEE Life Senior Member >> IEEE Communications Society & Signal Processing Society, >> Hawaii Chapter Chair >> IEEE Life Member Affinity Group Hawaii Chair >> IEEE Entrepreneurship, Mentor >> eugene.chang@ieee.org >> m 781-799-0233 (in Honolulu) >> >> >> _______________________________________________ >> Starlink mailing list >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink >> > _______________________________________________ > Starlink mailing list > Starlink@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/starlink > --0000000000007163920617ecad3a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to add the latest numbers from our (LibreQoS) ongoing= "QoE competitive landscape research":

Out of = 66k plus ISPs worldwide, barely 3k use some QoE middle-box. Preseem is the = market leader, with well over 400 T2 & T3 ISPs (number shared in their = wonderful=C2=A0Fixed Wireless Network Rep= ort 2024 Q1 Edition), Bequant seems to be 2nd, in terms of market penet= ration, claiming 500+ ISPs worldwide. Then we assume Cambium Networks and P= araqum - numbers of their users are not know, but we can expect something s= imilar, in the Preseem and Bequant ballpark. Then there is LibreQoS. All in= all, it's safe to say that somewhere between 2,5 and 3 thousand Intern= et Service Providers worldwide are using QoE middle-box of sort. So barely = 2% of the ISPs worldwide are using it, we are still in the "innovator&= quot; stage of the whole "crossing the chasm" paradigm.=C2=A0

We are all still very early on, working on it, and I&= #39;m lovin' it.=C2=A0


=
<= div>All the best,

Frank

Frantisek (Frank) Borsik

=C2=A0

https= ://www.linkedin.com/in/frantisekborsik

Signal, Telegram, WhatsApp: +42191941= 6714=C2=A0

iMessage, mobile: +420775230885

Skype: casioa5302ca

frantis= ek.borsik@gmail.com

=


On Wed, May 8, 2024 at 4:16=E2=80= =AFAM Dave Taht via Starlink <starlink@lists.bufferbloat.net> wrote:
This was a wonderful post, rich!
I note that preseem, paraqum,=C2=A0 bequant and l= ibreqos (a bufferbloat= .net backed project) are in the fq codel or cake Middlebox for isps *Qo= e) market and all of us have made a substantial dent in the problem for oh,= call it 1000 isps worldwide total between us. Comcast also has done a pret= ty good job but it seems yhe rest of the cable industry is asleep at the sw= itch.

The wisps totally = got it with fq codel and cake arriving native for mikeotiks entire product = line and much of ubnts gear prior to that.


Qoe is still a pretty hard s= ell. Libreqos has a ton of free users and we think over a million devices m= anaged by it but not enough paid users to justify even 1/10th the investmen= t we have made so far into it (something that I hope turns around with the = upcoming v1.5 lts release and some outputs from the nlnet and Comcast funde= d cakemaint and nqb projects)

Thing is, at higher and fiber rates all the bloat moves to the wifi, = and a ton of that, like eero especially was long ago fq codeled and so I th= ink several major players have also (except for those stuck with broadcom).= =C2=A0

That said there a= re a lot of defective wifi aps left to replace. Nearly every coffee shop I = have been in with the exception of Starbucks has really lousy wifi.

I am so thrilled to see what st= arlink has accomplished so far with their rollout of bufferbloat.net stuff and look forward t= o more. They are still missing a few tricks... but are aware of what tricks= they are missing...

Lac= k of knowledge of which regrettably remains the case for 97% of the market = and 99.99$ user base. Still ar apps will drive this rventually... I think s= tarlink is nicely positioned now to meet their demanding growth goals and h= umanity's future in space assured, so there's that. ( i still would= rather like elone to send over a nice pair of tesla motors and battery pac= k for my sailboat)

I did= have a nice jam with ajit Pai last week who is now well on his way towards= getting it. (See my twitter for the pics)

On Mon, May 6, 2024, 4:25= =E2=80=AFAM Rich Brown via Starlink <starlink@lists.bufferbloat.net> wro= te:
<= div>Hi Gene,

I've been vacillating on whe= ther to send this note, but have decided to pull the trigger. I apologize i= n advance for the "Debbie Downer" nature of this message. I also = apologize for any errors, omissions, or over-simplifications of the "b= irth of bufferbloat" story and its fixes. Corrections welcome.

Rich
------

If w= e are going to take a shot at opening people's eyes to bufferbloat, we = should know some of the "objections" we'll run up against. Ev= en though there's terrific technical data to back it up, people seem es= pecially resistant to thinking that bufferbloat might affect their network,= even when they're seeing problems that sound exactly like bufferbloat = symptoms. But first, some history:

The very idea of bufferblo= at is simply unbelievable. Jim Gettys in 2011 [1] couldn't believe it, = and he's a smart networking guy,. At the time, it seemed incredible (th= at is "not=C2=A0credible" =3D=3D impossible) that something could= induce 1.2 seconds of latency into his home network connection. He called = in favors from technical contacts at his ISP and=C2=A0at Bell Labs who went= over everything with a fine-toothed comb. It was all exactly as spec'd= . But he still had the latency.=C2=A0

This led Jim and Dave T=C3=A4h= t to start the investigation into the phenomenon known today as "buffe= rbloat" - the undesirable latency that comes from a router or other ne= twork=C2=A0equipment buffering too much data. Over several years, a group o= f smart people made huge improvements: fq_codel was released 14 May 2012 [3= ]; it was incorporated=C2=A0into the Linux kernel shortly afterward. CAKE c= ame in 2015, and the fixes that minimize bufferbloat in Wi-Fi arrived in 20= 18. In 2021 cake-autorate [4] arrived to handle=C2=A0varying speed ISP link= s. All these techniques work great: in 2014, my 7mbps DSL link was quite us= able. And when the pandemic hit, fq_codel on my OpenWrt router=C2=A0allowed= me to use that same 7mbps DSL line for two simultaneous zoom calls.=C2=A0<= /div>

As one of the authors of [2], I am part of the tea= m that has tried over the years to explain bufferbloat and how to fix it. W= e've spoken with vendors. We've spent untold hours responding to po= sts on assorted boards and forums with the the bufferbloat story.=C2=A0

With these technical fixes in hand, we cockily set ab= out to tell the world about how to fix bufferbloat. Our efforts have been m= et with skepticism at best, or stony silence. What are the objections?=C2= =A0

- This is just the ordinary behavior: I would = expect things to be slower when there's more traffic (Willfully ignorin= g orders of magnitude increase in delay.)
- Besides, I'm the = only one using the internet. (Except when my phone uploads photos. Or my co= mputer kicks off some automated process. Or I browse the web. Or ...)
=
- It only happens some of the time. (Exactly. That's probably when= something's uploading photos, or your computer is doing stuff in the b= ackground.)
- Those bufferbloat tests you hear about are bogus. T= hey artificially add load, which isn't a realistic test. (...and if you= actually are downloading a file?)
- Bufferbloat only happens whe= n the network is 100% loaded. (True. But when you open a web page, your bro= wser briefly uses 100% of the link. Is this enough to cause momentary lag?)=
- It's OK. I just tell my kids/spouse not to use the interne= t when I'm gaming. (Huh?)
- I have gigabit service from my IS= P. (That helps, but if you're complaining about "slowness" yo= u still need to rule out bufferbloat in your router.)
- I can'= ;t believe that router manufacturers would ever allow such a thing to happe= n in their gear. (See the Jim Gettys story above.)
- I mean... wo= uldn't router vendors want to provide the best for their customers? (No= - implementing this (new-ish) code requires engineering effort. They'r= e selling plenty of routers with decade-old software. The Boss says, "= would we sell more if they made these changes? Probably not.")
- Why would my ISP provision/sell me a router that gave crappy service? = They're a big company, they must know about this stuff. (Maybe. We have= reached out to all the vendors. But remember they profit if you decide you= r network is too slow and you upgrade to a faster device/plan.)
-= But couldn't I just tweak the QoS on my router? (Maybe. But see [5])
- Besides, I just spent $300 on a "gaming router". Obvio= usly, I bought the most expensive/best possible solution on the market (But= I still have lag...)
- You're telling me that a bunch of poi= nty-headed academics are smarter than commercial router developers - who so= ld me that $300 router? (I can't believe it.)
- And then you = say that I should throw away that gaming router and install some "open= source firmware"? (What the heck is that? And why should I believe yo= u?)=C2=A0
- What if it doesn't solve the problem? Who will gi= ve me support? And how will I get back to a vendor-supported system? (Valid= point - the first valid point)
- Aren't there any commercial= solutions I can just buy? (Not at the moment. IQrouter was a shining light= here - available from Amazon, simple setup, worked a treat - but they have= gone out of business. And of course, for the skeptic, this is proof that t= he "fq_codel-stuff" isn't really a solution - it seems just l= ike snake oil.)

So... All these hurdles make it ha= rd to convince people that bufferbloat could be the problem, or that they c= an fix for themselves.

A couple of us have reached= out to Consumer Reports, wondering if they would like a story about how ve= ndors would prefer to sell you a new, faster router (or new faster ISP plan= ) than fix your bufferbloat. This kind of story seemed to be straight up th= eir alley, but we never heard back after an initial contact. Maybe they des= erve another call...

The recent latency results fr= om Starlink give me a modicum of hope. They're a major player. They (an= d their customers) can point to an order of magnitude reduction in latency = over other solutions. It still requires enough "regular customers"= ; to tell their current ISP that they are switching to Starlink (and spend = $600 to purchase a Dishy plus $100/month) to provide a market incentive.

Despite all this doom and gloom, I remain hopeful th= at things will get better. We know the technology exists for people to take= control of their network and solve the problem for themselves. We can cont= inue to respond on forums where people express their dismay at the crummy p= erformance and suggest a solution. We can hope that a major vendor will twi= g to this effect and bring out a mass-market solution.

=
I think your suggestion of speaking to eSports people is intriguing. T= hey're highly motivated to make their personal networks better. And act= ually solving the problem would have a network effect of bringing in others= with the same problem.=C2=A0

Good luck, and thank= s for thinking about this.

Rich Brown
[2]=C2=A0https://www.bufferbloat.net/projects/bloat/wiki/What_can_I_do_about_Buff= erbloat/

On May 1, 2024= , at 6:19 PM, Eugene Y Chang via Starlink <starlink@lists.bu= fferbloat.net> wrote:

Of course. For the gamers, the focus is managing latency. They = have control of everything else.

With our high latency a= nd wide range of values, the eSports teams train on campus. It will be inte= resting to see how much improvements there can be for teams to be able to t= raining from their homes.

Gene
----------------------------------------------=
Eugene Chang
IEEE Life Senior Member
IEEE Communica= tions Society & Signal Processing Society, =C2=A0 =C2=A0
=C2=A0 =C2= =A0 Hawaii Chapter Chair
IEEE Life Member Affinity Group Hawaii C= hair

= _______________________________________________
Starlink mailing list
Starlink@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/sta= rlink
_______________________________________________
Starlink mailing list
Starlin= k@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/starlink --0000000000007163920617ecad3a--