OK. I need help teaching my ISPs that they can do this without threatening their business model. Who can help me?
A public demo? Yes! Are you saying that if our (my) neighborhood ISP adopted the lessons from the public demo, most of the latency issues would be solved? What won’t get fixed? How do we make this a widely adopted best practice? Am I crying over issues that are already fixed? Does this simplify the issues at the FCC? Gene ---------------------------------------------- Eugene Chang IEEE Life Senior Member > On Apr 30, 2024, at 11:07 AM, Dave Taht <dave.t...@gmail.com> wrote: > > Just fq codel or cake everything and you get all that. > > Libreqos is free software for those that do not want to update their data > plane. Perhaps we should do a public demo of what it can do for every tech on > the planet. Dsl benefits, fiber does also (but it is the stats that matter > more on fiber because the customer wifi becomes bloated) > > Starlink merely fq codeled their wifi and did some aqm work (not codel I > think) to get the amazing results they are getting today. I don't have the > waveform test results handy but they are amazing. I feel a sea change in the > wind... > > > > On Tue, Apr 30, 2024, 12:51 PM Eugene Y Chang via Starlink > <starl...@lists.bufferbloat.net <mailto:starl...@lists.bufferbloat.net>> > wrote: > Colin, > I am overwhelmed with all the reasons that prevent low(er) or consistent > latency. > I think that our best ISP offerings should deliver graceful, agile, or nimble > service. Sure, handle all the high-volume data. The high-volume service just > shouldn’t preclude graceful service. Yes, the current ISP practices fall > short. Can we help them improve their service? > > Am I asking too much? > > Gene > ---------------------------------------------- > Eugene Chang > IEEE Life Senior Member > > > > >> On Apr 30, 2024, at 9:31 AM, Colin_Higbie via Starlink >> <starl...@lists.bufferbloat.net <mailto:starl...@lists.bufferbloat.net>> >> wrote: >> >> Gene, >> >> I think the lion's share of other people (many brilliant people here) on >> this thread are focused on keeping latency down when under load. I generally >> just read and don't contribute on those discussions, because that's not my >> area of expertise. I only posted my point on bandwidth, not to detract from >> the importance of reducing latency, but to correct what I believed to be an >> important error on minimum bandwidth required to be able to perform standard >> Internet functions. >> >> To my surprise, there was pushback on the figure, so I've responded to try >> to educate this group on streaming usage in the hope that the people working >> on the latency problem under load (core reason for this group to exist) can >> also be aware of the minimum bandwidth needs to ensure they don't plan based >> on bad assumptions. >> >> For a single user, minimum bandwidth (independent of latency) needs to be at >> least 25Mbps assuming the goal is to provide access to all standard Internet >> services. Anything short of that will deny users access to the primary >> streaming services, and more specifically won't be able to watch 4K HDR >> video, which is the market standard for streaming services today and likely >> will remain at that level for the next several years. >> >> I think it's fine to offer lower-cost options that don't deliver 4K HDR >> video (not everyone cares about that), but at least 25Mbps should be >> available to an Internet customer for any new Internet service rollout. >> >> Cheers, >> Colin >> >> >> -----Original Message----- >> From: Starlink <starlink-boun...@lists.bufferbloat.net >> <mailto:starlink-boun...@lists.bufferbloat.net>> On Behalf Of >> starlink-requ...@lists.bufferbloat.net >> <mailto:starlink-requ...@lists.bufferbloat.net> >> Sent: Tuesday, April 30, 2024 3:05 PM >> To: starl...@lists.bufferbloat.net <mailto:starl...@lists.bufferbloat.net> >> Subject: Starlink Digest, Vol 37, Issue 15 >> >> >> ---------------------------------------------------------------------- >> >> Message: 1 >> Date: Tue, 30 Apr 2024 09:04:43 -1000 >> From: Eugene Y Chang <eugene.ch...@ieee.org <mailto:eugene.ch...@ieee.org>> >> To: Colin_Higbie <chigb...@higbie.name <mailto:chigb...@higbie.name>>, Dave >> Taht via Starlink >> <starl...@lists.bufferbloat.net <mailto:starl...@lists.bufferbloat.net>> >> Subject: Re: [Starlink] It’s the Latency, FCC >> Message-ID: <438b1bc4-d465-497a-b6ba-700e1d411...@ieee.org >> <mailto:438b1bc4-d465-497a-b6ba-700e1d411...@ieee.org>> >> Content-Type: text/plain; charset="utf-8" >> >> I am always surprised how complicated these discussions become. (Surprised >> mostly because I forgot the kind of issues this community care about.) The >> discussion doesn’t shed light on the following scenarios. >> >> While watching stream content, activating controls needed to switch content >> sometimes (often?) have long pauses. I attribute that to buffer bloat and >> high latency. >> >> With a happy household user watching streaming media, a second user could >> have terrible shopping experience with Amazon. The interactive response >> could be (is often) horrible. (Personally, I would be doing email and >> working on a shared doc. The Amazon analogy probably applies to more people.) >> >> How can we deliver graceful performance to both persons in a household? >> Is seeking graceful performance too complicated to improve? >> (I said “graceful” to allow technical flexibility.) >> >> Gene >> ---------------------------------------------- >> Eugene Chang >> >> _______________________________________________ >> Starlink mailing list >> starl...@lists.bufferbloat.net <mailto:starl...@lists.bufferbloat.net> >> https://lists.bufferbloat.net/listinfo/starlink >> <https://lists.bufferbloat.net/listinfo/starlink> > > _______________________________________________ > Starlink mailing list > starl...@lists.bufferbloat.net <mailto:starl...@lists.bufferbloat.net> > https://lists.bufferbloat.net/listinfo/starlink > <https://lists.bufferbloat.net/listinfo/starlink>
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ LibreQoS mailing list LibreQoS@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/libreqos
