This was a nice story of overhauling good ole Cambium Networks HW with OpenWrt, FQ-CoDel & CAKE:
https://blog.nafiux.com/posts/cnpilot_r190w_openwrt_bufferbloat_fqcodel_cake/ 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 Wed, May 1, 2024 at 6:12 AM David Lang via Starlink < starlink@lists.bufferbloat.net> wrote: > On Tue, 30 Apr 2024, Eugene Y Chang wrote: > > > I’m not completely up to speed on the gory details. Please humor me. I > am pretty good on the technical marketing magic. > > > > What is the minimum configuration of an ISP infrastructure where we can > show an A/B (before and after) test? > > It can be a simplified scenario. The simpler, the better. We can talk > through the issues of how minimal is adequate. Of course and ISP engineer > will argue against simplicity. > > I did not see a very big improvement on a 4/.5 dsl link, but there was > improvement. > > if you put openwrt on the customer router and configure cake with the > targeted > bandwith at ~80% of line speed, you will usually see a drastic improvement > for > just about any connection. > > If you can put fq_codel on both ends of the link, you can usually skip > capping > the bandwidth. > > unfortunantly, it's not possible to just add this to the ISPs existing > hardware > without having the source for the firmware there (and if they have their > queues > in ASICs it's impossible to change them. > > If you can point at the dramatic decrease in latency, with no bandwidth > losses, > that Starlink has achieved on existing hardware, that may help. > > There are a number of ISPs around the world that have implemented active > queue > management and report very good results from doing so. > > But showing that their existing hardware can do it when their upstream > vendor > doesn't support it is going to be hard. > > David Lang > > > > > We will want to show the human visible impact and not debate good or not > so good measurements. If we get the business and community subscribers on > our side, we win. > > > > Note: > > Stage 1 is to show we have a pure software fix (that can work on their > hardware). The fix is “so dramatic” that subscribers can experience it > without debating measurements. > > Stage 2 discusses why the ISP should demand that their equipment vendors > add this software. (The software could already be available, but the ISP > doesn’t think it is worth the trouble to enable it.) Nothing will happen > unless we stay engaged. We need to keep the subscribers engaged, too. > > > > Should we have a conference call to discuss this? > > > > > > Gene > > ---------------------------------------------- > > Eugene Chang > > IEEE Life Senior Member > > > > > > > >> On Apr 30, 2024, at 3:52 PM, Jim Forster <j...@connectivitycap.com> > wrote: > >> > >> Gene, David, > >> ‘m > >> Agreed that the technical problem is largely solved with cake & codel. > >> > >> Also that demos are good. How to do one for this problem> > >> > >> — Jim > >> > >>> The bandwidth mantra has been used for so long that a technical > discussion cannot unseat the mantra. > >>> Some technical parties use the mantra to sell more, faster, > ineffective service. Gullible customers accept that they would be happy if > they could afford even more speed. > >>> > >>> Shouldn’t we create a demo to show the solution? > >>> To show is more effective than to debate. It is impossible to explain > to some people. > >>> Has anyone tried to create a demo (to unseat the bandwidth mantra)? > >>> Is an effective demo too complicated to create? > >>> I’d be glad to participate in defining a demo and publicity campaign. > >>> > >>> Gene > >>> > >>> > >>>> On Apr 30, 2024, at 2:36 PM, David Lang <da...@lang.hm <mailto: > da...@lang.hm>> wrote: > >>>> > >>>> On Tue, 30 Apr 2024, Eugene Y Chang via Starlink wrote: > >>>> > >>>>> 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.) > >>>> > >>>> it's largely a solved problem from a technical point of view. > fq_codel and cake solve this. > >>>> > >>>> The solution is just not deployed widely, instead people argue that > more bandwidth is needed instead. > >> > > > >_______________________________________________ > 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
