Eugene - the easiest thing in the case of your ISP would be tell him about us: https://libreqos.io
He can take a look on it, join our support chat and get help if he won't be able to get it up and running: https://chat.libreqos.io/join/fvu3cerayyaumo377xwvpev6/ But most of the ISPs don't need to talk with us at all, it's easy to deploy. All the best, Frank Frantisek (Frank) Borsik https://www.linkedin.com/in/frantisekborsik Signal, Telegram, WhatsApp: +421919416714 iMessage, mobile: +420775230885 Skype: casioa5302ca frantisek.bor...@gmail.com On Tue, Apr 30, 2024 at 11:22 PM Eugene Y Chang via Starlink < starlink@lists.bufferbloat.net> wrote: > 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 < > starlink@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 < >> starlink@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> On Behalf Of >> starlink-requ...@lists.bufferbloat.net >> Sent: Tuesday, April 30, 2024 3:05 PM >> To: starlink@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> >> To: Colin_Higbie <chigb...@higbie.name>, Dave Taht via Starlink >> <starlink@lists.bufferbloat.net> >> Subject: Re: [Starlink] It’s the Latency, FCC >> Message-ID: <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 >> Starlink@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/starlink >> >> >> _______________________________________________ >> 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 >
_______________________________________________ Starlink mailing list Starlink@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/starlink
