If you can help me to define how exactly it should be done, I will ask WLPC folks and we will see if there is someone willing to do it. On the other hand, this is why I was telling you about wireless LAN guys and their admiration for Juniper, Ruckus and other big buffer guys... I REALLY hope someone at the wifi conference this > week can show test results with multiple stations at multiple > distances doing the right things, as we did at gfiber here, back in > *2014*, see page 13: > > http://flent-newark.bufferbloat.net/~d/Airtime%20based%20queue%20limit%20for%20FQ_CoDel%20in%20wireless%20interface.pdf > Because wifi6 and 7 are otherwise a huge step backwards. 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 Mon, Oct 23, 2023 at 8:11 PM Dave Taht wrote: > On Mon, Oct 23, 2023 at 10:47 AM Frantisek Borsik via Nnagain > wrote: > > > > Such a great thing to read! Another LibreQoS man aboard. > > Well, here is me trying to counter the now-too-popular idea that you > can shape everything at the middlebox at the ISP. It is a good start > to do that! The packet shaping *and* observability REALLY helps! But > in the end everything always works better if you have competent fq + > rfc7567 support at every possible bottleneck link, especially on > variable rate wireless transports, and especially in the face of > potentially difficult traffic like bittorrent, nat awareness and per > host/per flow fq have to happen at the customer site.... > > Correct backpressure at the right point, further modified by smart > algorithms is 20x less cpu intensive than shaping. The thing that bugs > me most is I see people trying to shape wifi to a fixed rate, which > works if you only test one device at "the right distance", and never > otherwise. A lot of wifi manufactures like eero and google wifi got > this, but so far my testing of wifi6 was so miserable I decided to > stop working on it. I REALLY hope someone at the wifi conference this > week can show test results with multiple stations at multiple > distances doing the right things, as we did at gfiber here, back in > *2014*, see page 13: > > > http://flent-newark.bufferbloat.net/~d/Airtime%20based%20queue%20limit%20for%20FQ_CoDel%20in%20wireless%20interface.pdf > > Because wifi6 and 7 are otherwise a huge step backwards. > > > Btw, Ignacio might be here, but cc'ing him anyway. > > i loved so much that *starting from scratch* he was able to assemble a > good solution out of OpenWrt. It restores my faith in the engineering > world, to know many folk younger than me still have basic C and > makefile skills. Thx, man! > > I have been doing embedded linux software since 1998, and am often a > bit grouchy about "the kids today" being unable to compile a kernel, > write a bit of xml for the dts stuff, and boom, have a totally custom > machine that does exactly what is needed. I see many wifi > manufacturers completely unable to build or modify or modify the > ancient crap they get from the chip manufacturer, including the chip > manufacturer! > > Training AIs or engaging in social media are far more popular and > highly paid skills nowadays. > > > > > > 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 Mon, Oct 23, 2023 at 7:44 PM le berger des photons via Nnagain < > nnagain@lists.bufferbloat.net> wrote: > >> > >> you've convinced me to go see libre qos. thanks. > >> > >> On Mon, Oct 23, 2023 at 7:04 PM Dave Taht via Nnagain < > nnagain@lists.bufferbloat.net> wrote: > >>> > >>> I loved that this guy and his ISP burned a couple weeks learning how > >>> to build openwrt, built something exactly to the need, *had it work > >>> the first time* and are in progress to update in place 200+ routers to > >>> better router software, that just works, with videoconferencing, IPv6 > >>> support, and OTA functionality. No need for a truck roll, and while > >>> the available bandwidth deep in these mountains in Mexico is meager, > >>> it is now enough for most purposes. > >>> > >>> > https://blog.nafiux.com/posts/cnpilot_r190w_openwrt_bufferbloat_fqcodel_cake/ > >>> > >>> I have no idea how many of this model routers were sold or are still > >>> deployed (?), but the modest up front cost of this sort of development > >>> dwarves that of deployment. Ongoing maintenance is a problem, but at > >>> least they are in a position now to rapidly respond to CVEs and other > >>> problems when they happen, having "seized control of the methods of > >>> computation" again. > >>> > >>> OpenWrt is known to run on 1700 different models, already, (with easy > >>> ports to obscure ones like this box) - going back over a decade in > >>> some cases. > >>> > >>> Another favorite story of mine was the ISP in New Zealand that > >>> deployed LibreQos and had all their support calls (from gamers and > >>> videoconferencers) cease overnight. The support tech, formerly drowned > >>> in angst from the users, set to work automating an reflashing 600 old > >>> agw routers they had "retired" on the shelf, and then distributing > >>> them to customers as extenders because the wifi finally worked right > >>> with the fq_codel stuff now in that release. > >>> > >>> I feel like I am tooting my own horn here a bit too much, but solving > >>> the right problems like MTTR, MTBF, bufferbloat, and taking back > >>> control of your software infrastructure while being able to customize > >>> it for purpose, and turning what otherwise would be ewaste into > >>> something that will last a decade more, is my inner "green", my inner > >>> stewart brand. > >>> > >>> Compare that to so many others being marketed to, to death, that buy > >>> the latest (and often inferior) thing, every few months, perpetually > >>> fooled by promises that do not pay off in the field, and often, really > >>> lousy MTBF. Good embedded software takes many years to develop, say, > >>> oh, 7, while the hardware cycle is closer to 2, nowadays, and requires > >>> many eyeballs to fully debug and get to lots of 9s of reliability. > >>> > >>> Back when I was even more radical about good, open, embedded, software > >>> than now, I used to say: "Friends don't let friends run factory > >>> firmware.". I do wish somehow the long term maintence costs of > >>> hardware with a decade plus service lifetime would be adaquately > >>> covered. Insurance? by law? a formal setaside from the purchase price? > >>> Otherwise we run the risk of turning the world's internet into a giant > >>> toxic waste dump that will require Superfund levels of cleanup, one > >>> day, and ever more contributions to trillions of dollars of fraud, and > >>> persistent actors having first broken down the front door, perpetually > >>> on the inside, wreaking more havoc. Somehow preventing that mess, up > >>> front, seems cheaper. > >>> > >>> Take this string of vulns: > >>> https://www.google.com/search?q=cisco+router+vulnerability > >>> > >>> (try that search string with *any* manufacturer - juniper, netgear, > tplink, > >>> > >>> There is a new vuln going around about some very old software in a > >>> cisco mx series which is ancient and yet 100k+ are vulnerable - (I > >>> worked on this while at montavista in the early 00s!) - abandonware, > >>> toxic waste... > >>> > >>> Anyway, in Mexico at least, 200+ routers are going to be a lot better, > >>> through the actions of all that contribute to linux, openwrt, and one > >>> smart and caring engineer. > >>> > >>> -- > >>> Oct 30: > https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html > >>> Dave Täht CSO, LibreQos > >>> _______________________________________________ > >>> Nnagain mailing list > >>> Nnagain@lists.bufferbloat.net > >>> https://lists.bufferbloat.net/listinfo/nnagain > >> > >> _______________________________________________ > >> Nnagain mailing list > >> Nnagain@lists.bufferbloat.net > >> https://lists.bufferbloat.net/listinfo/nnagain > > > > _______________________________________________ > > Nnagain mailing list > > Nnagain@lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/nnagain > > > > -- > Oct 30: > https://netdevconf.info/0x17/news/the-maestro-and-the-music-bof.html > Dave Täht CSO, LibreQos >