Oh goodness, I wasn't suggesting that we had a total solution, I was pointing out that the gaming community was missing the point, even with evidence in their hands. That suggests we have not made the point to a technically aware part of our community. --dave On 2024-05-06 20:43, Eugene Y Chang via Starlink wrote: > Dave, > We just can’t represent that we have the total solution. > We need to show the problem can be reduced. > We need to show that latency is a significant negative phenomena. > Take out one contributor and sic the users to the next contributor. > > If we expect to solve the whole problem in one step, we end up where > we are and effectively say the problem is too complex to solve. > > > 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) > > > >> On May 6, 2024, at 2:11 AM, Dave Collier-Brown via Starlink >> wrote: >> >> I think that gamer experience doing simple (over-simple) tests with >> CAKE is a booby-trap. This discussion suggests that the real >> performance of their link is horrid, and that they turn off CAKE to >> get what they think is full performance... but isn't. >> >> https://www.reddit.com/r/HomeNetworking/comments/174k0ko/low_latency_gaming_and_bufferbloat/#:~:text=If%20there's%20any%20chance%20that,out%20any%20intermittent%20latency%20spikes. >> >> >>  (I used to work for World Gaming, and follow the game commentators >> more that I do now) >> >> --dave >> >> >> On 2024-05-06 07:25, Rich Brown via Starlink 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 though 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 symptoms. 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" == >>> 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 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äht to start the investigation into the >>> phenomenon 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 shortly 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 varying 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 zoom 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 increase 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 add load, which isn't a realistic test. (...and if you >>> actually are downloading 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 your router.) >>> - I can't believe that router manufacturers would ever allow such a >>> thing 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 your 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 have 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 >>> should I believe you?) >>> - What if it doesn't solve the problem? Who will give 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 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, faster 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 after 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/month) 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 their 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_Bufferbloat/ >>> [3] >>> https://lists.bufferbloat.net/pipermail/cerowrt-devel/2012-May/000233.html >>> [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 >>>> 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 >> -- >> David Collier-Brown, | Always do right. This will gratify >> System Programmer and Author | some people and astonish the rest >> dave.collier-brown@indexexchange.com | -- Mark Twain >> >> */CONFIDENTIALITY NOTICE AND DISCLAIMER/*/ : This telecommunication, >> including any and all attachments, contains confidential information >> intended only for the person(s) to whom it is addressed. Any >> dissemination, distribution, copying or disclosure is strictly >> prohibited and is not a waiver of confidentiality. If you have >> received this telecommunication in error, please notify the sender >> immediately by return electronic mail and delete the message from >> your inbox and deleted items folders. This telecommunication does not >> constitute an express or implied agreement to conduct transactions by >> electronic means, nor does it constitute a contract offer, a contract >> amendment or an acceptance of a contract offer. Contract terms >> contained in this telecommunication are subject to legal review and >> the completion of formal documentation and are not binding until same >> is confirmed in writing and has been signed by an authorized signatory./ >> >> _______________________________________________ >> 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 -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dave.collier-brown@indexexchange.com | -- Mark Twain