From dave.taht at gmail.com Tue Aug 2 20:25:15 2022 From: dave.taht at gmail.com (Dave Taht) Date: Tue, 2 Aug 2022 17:25:15 -0700 Subject: [Make-wifi-fast] openwrt-22-03-rc6 released Message-ID: It's my hope that the last of the major wifi bugs plaguing openwrt have been quashed. Please test. https://forum.openwrt.org/t/openwrt-22-03-0-rc6-sixth-release-candidate/133673 Especially if you are using the ath10k, 9k, or mt76 chips. For some suggested tests see: https://forum.openwrt.org/t/aql-and-the-ath10k-is-lovely/59002/830 -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC From dave.taht at gmail.com Mon Aug 8 13:03:07 2022 From: dave.taht at gmail.com (Dave Taht) Date: Mon, 8 Aug 2022 10:03:07 -0700 Subject: [Make-wifi-fast] VI vs BE on wifi Message-ID: https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further-in-wifi/133605/32 If you squint, you can see what's left of the BE defaults when competing with VI -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC From moeller0 at gmx.de Mon Aug 8 13:43:32 2022 From: moeller0 at gmx.de (Sebastian Moeller) Date: Mon, 8 Aug 2022 19:43:32 +0200 Subject: [Make-wifi-fast] VI vs BE on wifi In-Reply-To: References: Message-ID: Hi Dave, in all fairness it depends a bit on the station AP combination how much AC_BE traffic gets hit. But essentially this graph (or rather similar graphs fro my own testing a few years back) convinced me that selecting the "L4S" DSCP to ensure mapping into AC_VI is massively misguided, to be friendly. (This also nicely illustrates the folly of https://datatracker.ietf.org/doc/html/rfc8325 Mapping Diffserv to IEEE 802.11, which does not seem to cite even a single reference showing data that the proposed scheme actually survives a contact with the existing WiFi gear in the field)... > On Aug 8, 2022, at 19:03, Dave Taht via Make-wifi-fast wrote: > > https://forum.openwrt.org/t/reducing-multiplexing-latencies-still-further-in-wifi/133605/32 > > If you squint, you can see what's left of the BE defaults when competing with VI > > > -- > FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ > Dave Täht CEO, TekLibre, LLC > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast at lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast From richb.hanover at gmail.com Thu Aug 11 09:10:59 2022 From: richb.hanover at gmail.com (Rich Brown) Date: Thu, 11 Aug 2022 09:10:59 -0400 Subject: [Make-wifi-fast] SSH over Wi-Fi freezes on RC6 Message-ID: There's an interesting topic (at least, I think so) on the OpenWrt Forum with my report that when I SSH into RC6 over Wi-Fi and run htop, the session freezes in a few minutes. When the Wi-Fi SSH session is frozen, the router (LuCI, routing traffic) and an SSH connection over Ethernet work fine. I have done a bunch of testing, and my summary is at: https://forum.openwrt.org/t/ssh-over-wifi-stops-working-on-rt3200-e8450-with-22-03-0-rc6/133911/37 I have also included this info as an OpenWrt issue at: https://github.com/openwrt/openwrt/issues/10405 Any other experiments I should perform? Thanks. Rich From dave.taht at gmail.com Thu Aug 11 14:56:40 2022 From: dave.taht at gmail.com (Dave Taht) Date: Thu, 11 Aug 2022 11:56:40 -0700 Subject: [Make-wifi-fast] anybody have a nest? Message-ID: https://wccftech.com/google-and-nest-wifi-are-getting-an-update-that-improves-performance-on-slower-connections/ -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC From bob.mcmahon at broadcom.com Thu Aug 11 15:33:22 2022 From: bob.mcmahon at broadcom.com (Bob McMahon) Date: Thu, 11 Aug 2022 12:33:22 -0700 Subject: [Make-wifi-fast] anybody have a nest? In-Reply-To: References: Message-ID: I have nest protects and thermostats but not "nest wifi." I used structured wiring and WiFi APs that support the 6GHz band. I don't think Google's APs support 6GHz but could be wrong. I'm thinking to avoid mesh and use Corning's clear track fiber where possible. Then find switches that support 100Gb/s SFPs per those SerDes/laser economics. Future proof so to speak. Bob On Thu, Aug 11, 2022 at 11:56 AM Dave Taht via Make-wifi-fast < make-wifi-fast at lists.bufferbloat.net> wrote: > > https://wccftech.com/google-and-nest-wifi-are-getting-an-update-that-improves-performance-on-slower-connections/ > > -- > FQ World Domination pending: > https://blog.cerowrt.org/post/state_of_fq_codel/ > Dave Täht CEO, TekLibre, LLC > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast at lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4206 bytes Desc: S/MIME Cryptographic Signature URL: From dave.taht at gmail.com Sat Aug 13 19:27:03 2022 From: dave.taht at gmail.com (Dave Taht) Date: Sat, 13 Aug 2022 16:27:03 -0700 Subject: [Make-wifi-fast] ofdma RU Message-ID: 2 years back I had yet to see this work. https://en.wikipedia.org/wiki/Resource_Unit Is there any proof this is working now, and how or with what can you sniff it? -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC From bob.mcmahon at broadcom.com Tue Aug 16 14:54:32 2022 From: bob.mcmahon at broadcom.com (Bob McMahon) Date: Tue, 16 Aug 2022 11:54:32 -0700 Subject: [Make-wifi-fast] comments on renaming iperf 2 to iperf next generation Message-ID: Hi All, It's unfortunate that numbers have been used in iperf naming. Many think iperf3 is the next version of iperf (or iperf2.) The number in the name isn't a version number as iperf 2 and iperf 3 are different code bases, different developers, have different goals, and don't interoperate. I'm thinking it's a good time to break this number as part of the name and only use -v for version numbers. In that context, I'm thinking about renaming iperf 2 to iperf next generation. The "next generation" implies that are lots of new features around responsiveness and latency. This proposed name will be used in web sites, etc. The "iperf2" binary will still just be iperf. I'm also hoping to get an IANA service as 'iperf' that way any device that supports the iperf 2.1.8 can also advertise responsiveness support. Here is an example and proposed updates to sourceforge. My hope is that this will help clear up the confusion between the two different tools. Comments? Bob -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4206 bytes Desc: S/MIME Cryptographic Signature URL: From moeller0 at gmx.de Tue Aug 16 16:04:12 2022 From: moeller0 at gmx.de (Sebastian Moeller) Date: Tue, 16 Aug 2022 22:04:12 +0200 Subject: [Make-wifi-fast] comments on renaming iperf 2 to iperf next generation In-Reply-To: References: Message-ID: <8495AC2A-C001-43F4-9AD9-E07A98B704C0@gmx.de> Ho Bob, +1 for renaming; the iperf2 iperf3 things is really confusing for mere end users. However "next generation/NG" is a relative moniker, in a few years NG is going to be the new normal and hence the name misleading again. While somewhat lame, maybe "iperformance" might be better in side stepping the-bigger-is-better issue when including numbers in the name, or obviously the correct answer go directly to iperf42 ;) Regards Sebastian > On Aug 16, 2022, at 20:54, Bob McMahon via Make-wifi-fast wrote: > > Hi All, > > It's unfortunate that numbers have been used in iperf naming. Many think iperf3 is the next version of iperf (or iperf2.) The number in the name isn't a version number as iperf 2 and iperf 3 are different code bases, different developers, have different goals, and don't interoperate. > > I'm thinking it's a good time to break this number as part of the name and only use -v for version numbers. In that context, I'm thinking about renaming iperf 2 to iperf next generation. The "next generation" implies that are lots of new features around responsiveness and latency. > > This proposed name will be used in web sites, etc. The "iperf2" binary will still just be iperf. I'm also hoping to get an IANA service as 'iperf' that way any device that supports the iperf 2.1.8 can also advertise responsiveness support. > > Here is an example and proposed updates to sourceforge. My hope is that this will help clear up the confusion between the two different tools. > > Comments? > Bob > > This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it._______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast at lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast From bob.mcmahon at broadcom.com Tue Aug 16 16:30:06 2022 From: bob.mcmahon at broadcom.com (Bob McMahon) Date: Tue, 16 Aug 2022 13:30:06 -0700 Subject: [Make-wifi-fast] comments on renaming iperf 2 to iperf next generation In-Reply-To: <8495AC2A-C001-43F4-9AD9-E07A98B704C0@gmx.de> References: <8495AC2A-C001-43F4-9AD9-E07A98B704C0@gmx.de> Message-ID: How about something like 'Iperf Next Evolution 2022 (iperf2) ' I'm very open to better suggestions. Thanks, Bob On Tue, Aug 16, 2022 at 1:04 PM Sebastian Moeller wrote: > Ho Bob, > > +1 for renaming; the iperf2 iperf3 things is really confusing for mere end > users. > > However "next generation/NG" is a relative moniker, in a few years NG is > going to be the new normal and hence the name misleading again. > > While somewhat lame, maybe "iperformance" might be better in side stepping > the-bigger-is-better issue when including numbers in the name, or obviously > the correct answer go directly to iperf42 ;) > > Regards > Sebastian > > > > On Aug 16, 2022, at 20:54, Bob McMahon via Make-wifi-fast < > make-wifi-fast at lists.bufferbloat.net> wrote: > > > > Hi All, > > > > It's unfortunate that numbers have been used in iperf naming. Many think > iperf3 is the next version of iperf (or iperf2.) The number in the name > isn't a version number as iperf 2 and iperf 3 are different code bases, > different developers, have different goals, and don't interoperate. > > > > I'm thinking it's a good time to break this number as part of the name > and only use -v for version numbers. In that context, I'm thinking about > renaming iperf 2 to iperf next generation. The "next generation" implies > that are lots of new features around responsiveness and latency. > > > > This proposed name will be used in web sites, etc. The "iperf2" binary > will still just be iperf. I'm also hoping to get an IANA service as 'iperf' > that way any device that supports the iperf 2.1.8 can also advertise > responsiveness support. > > > > Here is an example and proposed updates to sourceforge. My hope is that > this will help clear up the confusion between the two different tools. > > > > Comments? > > Bob > > > > This electronic communication and the information and any files > transmitted with it, or attached to it, are confidential and are intended > solely for the use of the individual or entity to whom it is addressed and > may contain information that is confidential, legally privileged, protected > by privacy laws, or otherwise restricted from disclosure to anyone else. If > you are not the intended recipient or the person responsible for delivering > the e-mail to the intended recipient, you are hereby notified that any use, > copying, distributing, dissemination, forwarding, printing, or copying of > this e-mail is strictly prohibited. If you received this e-mail in error, > please return the e-mail to the sender, delete it from your computer, and > destroy any printed copy of > it._______________________________________________ > > Make-wifi-fast mailing list > > Make-wifi-fast at lists.bufferbloat.net > > https://lists.bufferbloat.net/listinfo/make-wifi-fast > > -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4206 bytes Desc: S/MIME Cryptographic Signature URL: From richb.hanover at gmail.com Tue Aug 16 16:54:24 2022 From: richb.hanover at gmail.com (Rich Brown) Date: Tue, 16 Aug 2022 16:54:24 -0400 Subject: [Make-wifi-fast] comments on renaming iperf 2 to iperf next generation In-Reply-To: References: Message-ID: I don't necessarily like or endorse any of these... Just some random neurons firing. - If you're going to change the (full) name, would you also change the name on the command line? - If you did, it might be to something like "iperfnext", which is long - Or perhaps "iperfx" but that's hard to type that final X (my ring finger doesn't get down there as easily) - "iperfx" is an anagram for "prefix" - What about "iperfect"? :-) - "xperf" is easier to type, is short. And there's a program called "Xperf" Dang. - Maybe there's a way to work "responsiveness" and "performance" into the name "res-perf"? "resperf" I dunno. From bob.mcmahon at broadcom.com Tue Aug 16 17:10:50 2022 From: bob.mcmahon at broadcom.com (Bob McMahon) Date: Tue, 16 Aug 2022 14:10:50 -0700 Subject: [Make-wifi-fast] comments on renaming iperf 2 to iperf next generation In-Reply-To: References: Message-ID: Yeah, I got some input to just leave things as is so you're not alone in your "random neurons firing." My goal is to minimize confusion. Changing the binary name from iperf to something else is something I'd like to avoid. Changing the name and description in sourceforge may only cause more confusion. Hence the pseudo polling here to see what others think. Bob On Tue, Aug 16, 2022 at 1:54 PM Rich Brown via Make-wifi-fast < make-wifi-fast at lists.bufferbloat.net> wrote: > > I don't necessarily like or endorse any of these... Just some random > neurons firing. > > - If you're going to change the (full) name, would you also change the > name on the command line? > - If you did, it might be to something like "iperfnext", which is long > - Or perhaps "iperfx" but that's hard to type that final X (my ring finger > doesn't get down there as easily) > - "iperfx" is an anagram for "prefix" > - What about "iperfect"? :-) > - "xperf" is easier to type, is short. And there's a program called > "Xperf" Dang. > - Maybe there's a way to work "responsiveness" and "performance" into the > name "res-perf"? "resperf" > > I dunno. > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast at lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4206 bytes Desc: S/MIME Cryptographic Signature URL: From dave.taht at gmail.com Thu Aug 18 13:34:47 2022 From: dave.taht at gmail.com (Dave Taht) Date: Thu, 18 Aug 2022 10:34:47 -0700 Subject: [Make-wifi-fast] cisco ultra reliable wireless backhaul Message-ID: "Cisco Ultra-Reliable Wireless Backhaul is a wireless technology that enables you to connect moving assets or extend your network where running fiber isn't feasible or affordable. It delivers up to a 7.8-Gbps data rate, 99.995% availability, less than 10-ms latency, and zero packet loss with seamless handoffs. This proven technology operates in unlicensed spectrum, deploys like Wi-Fi, and gives you full control of your network". https://www.cisco.com/c/en/us/products/wireless/ultra-reliable-wireless-backhaul/index.html Once upon a time, cisco displayed more clue. -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC From dave.taht at gmail.com Fri Aug 19 14:54:00 2022 From: dave.taht at gmail.com (Dave Taht) Date: Fri, 19 Aug 2022 11:54:00 -0700 Subject: [Make-wifi-fast] low power wifi 6 chip Message-ID: I was hoping to see someone attempt a lower power wifi 6 chip, but wasn't expecting it from this direction. https://www.nordicsemi.com/Products/nRF7002 -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC From dave.taht at gmail.com Fri Aug 19 17:38:48 2022 From: dave.taht at gmail.com (Dave Taht) Date: Fri, 19 Aug 2022 14:38:48 -0700 Subject: [Make-wifi-fast] qt bug messing up wifi every 10 sec Message-ID: https://bugreports.qt.io/browse/QTBUG-40332?focusedCommentId=390766&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel https://blog.ando.fyi/posts/diagnosing-an-unsual-wifi-issue/ -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC From dave.taht at gmail.com Sun Aug 21 09:41:15 2022 From: dave.taht at gmail.com (Dave Taht) Date: Sun, 21 Aug 2022 06:41:15 -0700 Subject: [Make-wifi-fast] tsq and ath10k Message-ID: Not sure how real this bug is. https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1670041 -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC From dave.taht at gmail.com Mon Aug 22 13:23:04 2022 From: dave.taht at gmail.com (Dave Taht) Date: Mon, 22 Aug 2022 10:23:04 -0700 Subject: [Make-wifi-fast] marketing wifi and broadband in the c-suite Message-ID: https://www.calix.com/content/dam/calix/marketing-documents/public/reports/report_marketer-bb-provider.pdf Very different world, but it stood out to me, that "managed wifi" was a number #1 priority. Having wifi that actually worked right out the box has always been mine.... 'C-level "top priority” marketing use cases include managed Wi-Fi (46%), home network cybersecurity and device security (both 45%), and professional home monitored security (42%). Rounding out the top five is social media monitoring (39%)"' -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC From bob.mcmahon at broadcom.com Mon Aug 22 15:30:08 2022 From: bob.mcmahon at broadcom.com (Bob McMahon) Date: Mon, 22 Aug 2022 12:30:08 -0700 Subject: [Make-wifi-fast] marketing wifi and broadband in the c-suite In-Reply-To: References: Message-ID: Thanks for sharing this. It's interesting that the focus is still on speed and not so much on latency/responsiveness. *In addition to navigating the competitive landscape, BSPs must also continually hone theirmarketing messages to attract and recruit new subscribers. As Figure 10 illustrates, basedon “top priority” responses, the C-levels are following a pragmatic marketing messagestrategy centered on faster speeds (54%),This is judicious given that many of their competitors are also focusing on network speed to enhance the quality of experience. * On Mon, Aug 22, 2022 at 10:23 AM Dave Taht via Make-wifi-fast < make-wifi-fast at lists.bufferbloat.net> wrote: > > https://www.calix.com/content/dam/calix/marketing-documents/public/reports/report_marketer-bb-provider.pdf > > Very different world, but it stood out to me, that "managed wifi" was > a number #1 priority. Having wifi that actually worked right out the > box has always been mine.... > > 'C-level "top priority” marketing use cases include managed Wi-Fi (46%), > home > network cybersecurity and device security (both 45%), and professional home > monitored security (42%). Rounding out the top five is social media > monitoring > (39%)"' > > -- > FQ World Domination pending: > https://blog.cerowrt.org/post/state_of_fq_codel/ > Dave Täht CEO, TekLibre, LLC > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast at lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4206 bytes Desc: S/MIME Cryptographic Signature URL: From moeller0 at gmx.de Tue Aug 23 07:59:03 2022 From: moeller0 at gmx.de (Sebastian Moeller) Date: Tue, 23 Aug 2022 13:59:03 +0200 Subject: [Make-wifi-fast] [Bloat] marketing wifi and broadband in the c-suite In-Reply-To: References: Message-ID: <5FFA1DC1-6C29-4743-B831-DD91E1F522A7@gmx.de> Well, marketing and pricing policy have "trained" end-customers that speed is the decisive factor, with faster plans being more expensive (which implies a higher value). Even if an end-customer wanted to, there currently is no mass-market offer where you "buy" lower latency. Even worse, ISPs that only offer price-tiered contracts will recommend that latency affected customers switch to faster plans (probably on the basis that it is more likely that a faster link is not congested/running at capacity, so under-managed and over-sized queues will not be as visible as on slower plans with an equal load). > On Aug 22, 2022, at 21:30, Bob McMahon via Bloat wrote: > > Thanks for sharing this. It's interesting that the focus is still on speed and not so much on latency/responsiveness. > > In addition to navigating the competitive landscape, BSPs must also continually hone their > marketing messages to attract and recruit new subscribers. As Figure 10 illustrates, based > on “top priority” responses, the C-levels are following a pragmatic marketing message > strategy centered on faster speeds (54%), > > This is judicious given that many of their competitors are also focusing on network speed to enhance the quality of experience. Likely because speed is the main factor correlating with relative plan-price and they market the products they have? Take me as an example, I am on a 100/40 plan, even though I could get 1000/50 for ~20% more money, but thanks to fully acceptable QoE, thanks to competent AQM and traffic shaping, I rather save that money. I am not saying that ISPs actively "sabotage" their lower speed offers or the like, just that increasing QoE of these too much will require to rethinking what a plan's price should correlate with*. C-suite officers are hardly interested on decreasing the ARPU by making their cheaper plans fully sufficient for most uses ;). Regards Sebastian *) This is where "responsiveness"/RPM might be helpful. > On Mon, Aug 22, 2022 at 10:23 AM Dave Taht via Make-wifi-fast wrote: > https://www.calix.com/content/dam/calix/marketing-documents/public/reports/report_marketer-bb-provider.pdf > > Very different world, but it stood out to me, that "managed wifi" was > a number #1 priority. Having wifi that actually worked right out the > box has always been mine.... > > 'C-level "top priority” marketing use cases include managed Wi-Fi (46%), home > network cybersecurity and device security (both 45%), and professional home > monitored security (42%). Rounding out the top five is social media monitoring > (39%)"' > > -- > FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ > Dave Täht CEO, TekLibre, LLC > _______________________________________________ > Make-wifi-fast mailing list > Make-wifi-fast at lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/make-wifi-fast > > This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it._______________________________________________ > Bloat mailing list > Bloat at lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat From dave.taht at gmail.com Wed Aug 24 19:55:23 2022 From: dave.taht at gmail.com (Dave Taht) Date: Wed, 24 Aug 2022 16:55:23 -0700 Subject: [Make-wifi-fast] taprio vs. wireless/mac80211 In-Reply-To: <87lerdmd2g.fsf@intel.com> References: <117aa7ded81af97c7440a9bfdcdf287de095c44f.camel@sipsolutions.net> <87lerdmd2g.fsf@intel.com> Message-ID: On Wed, Aug 24, 2022 at 4:36 PM Vinicius Costa Gomes wrote: > > Hi Johannes, > > Johannes Berg writes: > > > Hi, > > > > We're exploring the use of taprio with wireless/mac80211, and in > > mac80211 today (**) we don't have multiple queues (any more) since all > > the queuing actually happens in FQ/Codel inside mac80211. We also set > > IFF_NO_QUEUE, but that of course only really affects the default qdisc, > > not the fact that you could use it or not. It would be good if more people understood the packet aggregation problem deeply, and lost 8 minutes of their life to this. https://www.youtube.com/watch?v=Rb-UnHDw02o&t=1745s Theoretically, in wifi 7, something like single packet taprio-like scheduling across "DU"s might become feasible. > > In mac80211 thus we never back-pressure against the qdiscs, which is why > > we basically selected a single queue. Also, there's nothing else we do > > about the queue other than immediately pull a packet from it if > > available, so it'd basically pure overhead to have real queues there. > > > > In a sense, given that we cannot back-pressure against the queues, it > > feels a bit wrong to even have multiple queues. We also don't benefit in > > any way from splitting data structures onto multiple CPUs or something > > since we put it all into the same FQ/Codel anyway. > > > > > > Now, in order to use taprio, you're more or less assuming that you have > > multiple (equivalent) queues, as far as I can tell. 802.11e's notion of four hardware queues could possibly be utilized more effectively. Or you could program those hw queues differently from the default. > > > > Obviously we can trivially expose multiple equivalent queues from > > mac80211, but it feels somewhat wrong if that's just to make taprio be > > able to do something? > > > > Also how many should we have, there's more code to run so in many cases > > you probably don't want more than one, but if you want to use taprio you > > need at least two, but who says that's good enough, you might want more > > classes: > > > > /* taprio imposes that traffic classes map 1:n to tx queues */ > > if (qopt->num_tc > dev->num_tx_queues) { > > NL_SET_ERR_MSG(extack, "Number of traffic classes is > > greater than number of HW queues"); > > return -EINVAL; > > } > > > > > > The way taprio is done almost feels like maybe it shouldn't even care > > about the number of queues since taprio_dequeue_soft() anyway only > > queries the sub-qdiscs? I mean, it's scheduling traffic, if you over- > > subscribe and send more than the link can handle, you've already lost > > anyway, no? > > > > (But then Avi pointed out that the sub qdiscs are initialized per HW > > queue, so this doesn't really hold either ...) > > > > > > Anyone have recommendations what we should do? > > I will need to sleep on this, but at first glance, it seems you are > showing a limitation of taprio. > > Removing that limitation seems possible, but it would add a bit of > complexity (but not much it seems) to the code, let me write down what I > am thinking: > > 0. right now I can trust that there are more queues than traffic > classes, and using the netdev prio->tc->queue map, I can do the > scheduling almost entirely on queues. I have to remove this assumption. > > 1. with that assumption removed, it means that I can have more traffic > classes than queues, and so I have to be able to handle multiple > traffic classes mapped to a single queue, i.e. one child qdisc per TC > vs. one child per queue that we have today. Enqueueing each packet to > the right child qdisc is easy. Dequeueing also is also very similar to > what taprio does right now. > > 2. it would be great if I knew the context in which each ->dequeue() is > called, specifically which queue the ->dequeue() is for, it would > reduce the number of children that I would have to check. > > After writing this, I got the impression that it's feasible. Anyway, > will think a bit more about it. > > (2) I don't think is possible right now, but I think we can go on > without it, and leave it as a future optimization. > > Does it make sense? Did I understand the problem you are having right? > > > Cheers, > -- > Vinicius -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC From dave.taht at gmail.com Sun Aug 28 11:29:24 2022 From: dave.taht at gmail.com (Dave Taht) Date: Sun, 28 Aug 2022 08:29:24 -0700 Subject: [Make-wifi-fast] anybody got a spare $495? Message-ID: This, apparently, is how you win an award in the Wi-Fi industry. I was going to submit ending the anomaly, but... https://wifinowglobal.com/about-awards/how-to-enter/ -- FQ World Domination pending: https://blog.cerowrt.org/post/state_of_fq_codel/ Dave Täht CEO, TekLibre, LLC