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: <CAA93jw5sAM9MiSsV6HMyQdJPox4HWvSp8HK592UMSL1BMHg8Wg@mail.gmail.com>

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: <CAA93jw5Go4tVpEXzkZ_wV0GDmE2Rbh44kWaNOWS_rLSLT6ZDqQ@mail.gmail.com>

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: <CAA93jw5Go4tVpEXzkZ_wV0GDmE2Rbh44kWaNOWS_rLSLT6ZDqQ@mail.gmail.com>
References: <CAA93jw5Go4tVpEXzkZ_wV0GDmE2Rbh44kWaNOWS_rLSLT6ZDqQ@mail.gmail.com>
Message-ID: <FD75701C-4626-4311-AE85-504CCCAB6E85@gmx.de>

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 <make-wifi-fast at lists.bufferbloat.net> 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: <ABB2CCCB-6538-4200-8664-AFC5C43D910A@gmail.com>

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: <CAA93jw4FtWMT+UEt5zH2vSD6Kp9Oe2_0BdxU5ELHs8eBLk+WQw@mail.gmail.com>

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: <CAA93jw4FtWMT+UEt5zH2vSD6Kp9Oe2_0BdxU5ELHs8eBLk+WQw@mail.gmail.com>
References: <CAA93jw4FtWMT+UEt5zH2vSD6Kp9Oe2_0BdxU5ELHs8eBLk+WQw@mail.gmail.com>
Message-ID: <CAHb6Lvp0DXAvopt92Rh=MV63ysHTPYC2oAFYj-L9gig1rpc4sQ@mail.gmail.com>

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
<https://www.corning.com/fiber-to-the-premise/worldwide/en/home/products/clear-track-fiber-pathway.html>
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: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20220811/462ca223/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20220811/462ca223/attachment.bin>

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: <CAA93jw6mZC7pTvL4Re+eGYqFfWvwgZRThceipNa9kJcLRfH12A@mail.gmail.com>

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: <CAHb6LvpB6tUozmugf7Lx+WghkXETVwR7ht2JLQ9L=k+Hq8E_Lw@mail.gmail.com>

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.
<https://sourceforge.net/projects/iperf2/> 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: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20220816/cd44e106/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20220816/cd44e106/attachment.bin>

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: <CAHb6LvpB6tUozmugf7Lx+WghkXETVwR7ht2JLQ9L=k+Hq8E_Lw@mail.gmail.com>
References: <CAHb6LvpB6tUozmugf7Lx+WghkXETVwR7ht2JLQ9L=k+Hq8E_Lw@mail.gmail.com>
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 <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


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: <CAHb6LvpB6tUozmugf7Lx+WghkXETVwR7ht2JLQ9L=k+Hq8E_Lw@mail.gmail.com>
 <8495AC2A-C001-43F4-9AD9-E07A98B704C0@gmx.de>
Message-ID: <CAHb6Lvoj_9RcghHEmpPszeg+Qh8RFMwRJDiJhd34hvN6Djq5zQ@mail.gmail.com>

How about something like 'Iperf Next Evolution 2022 (iperf2)
<https://sourceforge.net/projects/iperf2/>'

I'm very open to better suggestions.

Thanks,
Bob

On Tue, Aug 16, 2022 at 1:04 PM Sebastian Moeller <moeller0 at gmx.de> 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: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20220816/b7da1f60/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20220816/b7da1f60/attachment-0001.bin>

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: <mailman.590.1660681819.1281.make-wifi-fast@lists.bufferbloat.net>
References: <mailman.590.1660681819.1281.make-wifi-fast@lists.bufferbloat.net>
Message-ID: <EF36A9ED-AD30-445D-B562-4291F6521DD6@gmail.com>


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: <EF36A9ED-AD30-445D-B562-4291F6521DD6@gmail.com>
References: <mailman.590.1660681819.1281.make-wifi-fast@lists.bufferbloat.net>
 <EF36A9ED-AD30-445D-B562-4291F6521DD6@gmail.com>
Message-ID: <CAHb6LvrzE37ZS+pQor8tLPQE+sj8CcirHcznpBCzxwVGHwwMjw@mail.gmail.com>

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: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20220816/2c12e952/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20220816/2c12e952/attachment.bin>

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: <CAA93jw5067m8BR_4gzcs+es_4G8bxX60mkn3oDW88_ZRJx7axQ@mail.gmail.com>

"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: <CAA93jw7XYT84VT8xOcG2UAUwvKkFg8f+A1Z-V3g1G7x_vD9p3Q@mail.gmail.com>

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: <CAA93jw5AGVMPxQ3tTQOptSkX5UsvU_MWE=cL8ajt_h5HW0_XrQ@mail.gmail.com>

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: <CAA93jw6Fz6XWzPCmKSHS3yTcN=u3UB=K=+zhmce4KwW5QJRrNA@mail.gmail.com>

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: <CAA93jw7+c5DUSWT+6y8=k+gEJAG6NJKtJoM4AhurH9sRSXud2g@mail.gmail.com>

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: <CAA93jw7+c5DUSWT+6y8=k+gEJAG6NJKtJoM4AhurH9sRSXud2g@mail.gmail.com>
References: <CAA93jw7+c5DUSWT+6y8=k+gEJAG6NJKtJoM4AhurH9sRSXud2g@mail.gmail.com>
Message-ID: <CAHb6Lvo91CX9fVoTOrRf=j++J5BLOwEiLTNNOgF87CSRGrOSmg@mail.gmail.com>

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: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20220822/e8ac26ff/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4206 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.bufferbloat.net/pipermail/make-wifi-fast/attachments/20220822/e8ac26ff/attachment.bin>

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: <CAHb6Lvo91CX9fVoTOrRf=j++J5BLOwEiLTNNOgF87CSRGrOSmg@mail.gmail.com>
References: <CAA93jw7+c5DUSWT+6y8=k+gEJAG6NJKtJoM4AhurH9sRSXud2g@mail.gmail.com>
 <CAHb6Lvo91CX9fVoTOrRf=j++J5BLOwEiLTNNOgF87CSRGrOSmg@mail.gmail.com>
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 <bloat at lists.bufferbloat.net> 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 <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._______________________________________________
> 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: <CAA93jw5BiqemeLrb4oDSrJQCrS1HEia7_y1syEfmqh-Fauah5w@mail.gmail.com>

On Wed, Aug 24, 2022 at 4:36 PM Vinicius Costa Gomes
<vinicius.gomes at intel.com> wrote:
>
> Hi Johannes,
>
> Johannes Berg <johannes at sipsolutions.net> 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: <CAA93jw6OQ5Rre3Qunb9q0nBSKyMBWOYvy=L3fnpdL+OTSGS2Wg@mail.gmail.com>

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