On Thu, 12 Oct 2023, rjmcmahon wrote:
I think we're looking at different parts of the elephant. I perceive huge
advances in WiFi (phy, dsp, radios, fems, etc.) and residential gateway chips
of late.
My point is that the chips behavior doesn't change when you switch to a newer
release of openwrt on the same chipset. When you do a new hardware version, you
need to do all the testing that was mentioned (and more) but if you are looking
at updating the opewrt image, you have far less that you need to check.
David Lang
Not sure the state of chips used by the openwrt folks here, though
they may be lagging a bit - not sure.
https://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-availability-second-generation-wi-fi-7
Broadcom’s Wi-Fi 7 ecosystem product portfolio includes the BCM6765,
BCM47722, and BCM4390.
The BCM6765 is optimized for the residential Wi-Fi access point market. Key
features include:
...
The BCM47722 is an enterprise access point platform SoC supporting Wi-Fi 7,
Bluetooth Low Energy, and 802.15.4 protocols. Key features include:
...
The BCM4390 is a highly-integrated Wi-Fi 7 and Bluetooth 5 combo chip
optimized for mobile handset applications. Key features include:
...
Bob
On Thu, 12 Oct 2023, rjmcmahon via Nnagain wrote:
I looked at openwrt packages and iperf 2 is at version 2.1.3 which is a
few years old.
The number of CPE/AP systems to test against is quite large. Then throwing
in versions for backwards compatibility testing adds yet another vector.
for the market as a whole, yes, it's a hard problem. But for an
individual manfacturer, they only have to work with their equipment,
not all the others. The RF side isn't changing from release to release
(and usually the firmware for the Wifi isn't changing), so that
eliminates a lot of the work. They need to do more smoke testing of
new releases than a full regression/performance test. Some
incompatibility creeping in is the most likely problem, not a subtle
performance issue.
For the Scale conference, we have a Pi tied to a couple relays hooked
to the motherboard of the router we use and it's tied in to our github
repo, so every PR gets auto-flashed to the router and simple checks
done. Things like this should be easy to setup and will catch most
issues.
David Lang
Since it's performance related, statistical techniques are required
against multiple metrics to measure statistically the same or not. Finally
with WiFi, one needs to throw in some controlled, repeatable RF
variability around the d-matrices (range) & h-matrices (frequency
responses in both phase and amplitudes per the MIMO spatial streams.)
I can see why vendors (& system integrators) might be slow to adopt the
latest if there is not some sort of extensive qualification ahead of that
adoption.
Bob
PS. Iperf 2 now has 2.5+ million downloads (if sourceforge is to be
believed.) My wife suggested I write a book titled, "How to create
software with 2.5M downloads, a zero marginal cost to produce, and get
paid zero dollars!!" I suspect many openwrt & other programmers could add
multiple chapters to such a book.
On Thu, Oct 12, 2023 at 9:04 AM rjmcmahon via Nnagain
<nnagain@lists.bufferbloat.net> wrote:
Sorry, my openwrt information seems to be incorrect and more vendors use
openwrt then I realized. So, I really don't know the numbers here.
There are not a lot of choices in the market. On the high end, like
eero, we are seeing Debian derived systems, also some chromeOS
devices. Lower end there is "buildroot", and forked openwrts like
Meraki.
So the whole home router and cpe market has some, usually obsolete,
hacked up, and unmaintained version of openwrt at its heart, on
everything from SFPs to the routers and a lot of iOt, despite many
advancements and security patches in the main build.
It would be my earnest hope, with a clear upgrade path, downstream
manufacturers would release within a few months of the main OpenWrt
releases, or even at the same time, having worked with their customers
through the 6 month release candidate cycle. Microsoft accomplishes
this, at least.
https://www.reddit.com/r/openwrt/comments/175z8t9/imminent_release_of_openwrt_2305/
I do agree with the idea that fixes should be pushed to the mainline and
that incremental upgrades should be standard practice.
+1000
Arista's SW VP gave a talk where he said that 80% of their customer
calls about bugs were already fixed but their customer wasn't following
an upgrade policy. This approach applies to most any sw based product.
+100
Bob
Hi David,
The vendors I know don't roll their own os code either. The make their
own release still mostly based from Linux and they aren't tied to the
openwrt release process.
I think GUIs on CPEs are the wrong direction. Consumer network
equipment does best when it's plug and play. Consumers don't have all
the skills needed to manage an in home packet network that includes
wifi.
I recently fixed a home network for my inlaws. It's a combo of
structured wire and WiFi APs. I purchased the latest equipment from
Amazon vs use the ISP provided equipment. I can do this reasonably
well because I'm familiar with the chips inside.
The online tech support started with trepidation as he was concerned
that the home owner, i.e me, wasn't as skilled as the ISP technicians.
He suggested we schedule that but I said we were good to go w/o one.
He asked to speak to my father in law when we were all done. He told
him, "You're lucky to have a son in law that know what he's doing. My
techs aren't as good, and I really liked working with him too."
I say this not to brag, as many on this list could do the equivalent,
but to show that we really need to train lots of technicians on things
like RF and structured wiring. Nobody should be "lucky" to get a
quality in home network. We're not lucky to have a flush toilet
anymore. This stuff is too important to rely on luck.
Bob
On Oct 11, 2023, at 3:58 PM, David Lang <david@lang.hm> wrote:
On Wed, 11 Oct 2023, rjmcmahon wrote:
I don't know the numbers but a guess is that a majority of SoCs
with WiFi
radios aren't based on openwrt.
From what I've seen, the majority of APs out there are based on
OpenWRT or one
of the competing open projects, very few roll their own OS from
scratch
I think many on this list use openwrt but
that may not be representative of the actuals. Also, the trend is
less sw in
a CPU forwarding plane and more hw, one day, linux at the CPEs
mayhttps://investors.broadcom.com/news-releases/news-release-details/broadcom-announces-availability-second-generation-wi-fi-7
not be
needed at all (if we get to remote radio heads - though this is
highly
speculative.)Peregrine - 112G PAM4
that is countered by the trend to do more (fancier GUI, media
center, etc) The
vendors all want to differentiate themselves, that's hard to do if
it's baked
into the chips
From my experience, sw is defined by the number & frequency of
commits, and
of timeliness to issues more than a version number or compile
date. So the
size and quality of the software staff can be informative.
I'm more interested in mfg node process then the mfg location &
date as the
node process gives an idea if the design is keeping up or not.
Chips designed
in 2012 are woefully behind and consume too much energy and
generate too much
heat. I think Intel provides this information on all its chips as
an example.
I'm far less concerned about the chips than the software. Security
holes are far
more likely in the software than the chips. The chips may limit the
max
performance of the devices, but the focus of this is on the
security, not the
throughput or the power efficiency (I don't mind that extra info,
but what makes
some device unsafe to use isn't the age of the chips, but the age of
the
software)
David Lang
Bob
On Wed, 11 Oct 2023, David Bray, PhD via Nnagain wrote:
There's also the concern about how do startups roll-out such a
label for
their tech in the early iteration phase? How do they afford to do
the
extra
work for the label vs. a big company (does this become a regulatory
moat?)
And let's say we have these labels. Will only consumers with the
money to
purchase the more expensive equipment that has more privacy and
security
features buy that one - leaving those who cannot afford privacy and
security bad alternatives?
As far as security goes, I would argue that the easy answer is to
ship
a current version of openwrt instead of a forked, ancient version,
and
get their changes submitted upstream (or at least maintained against
upstream). It's a different paradigm than they are used to, and
right
now the suppliers tend to also work with ancient versions of
openwrt,
but in all the companies that I have worked at, it's proven to be
less
ongoing work (and far less risk) to keep up with current versions
than
it is to stick with old versions and then do periodic 'big jump'
upgrades.
it's like car maintinance, it seems easier to ignore your tires,
brakes, and oil changes, but the minimal cost of maintaining those
systems pays off in a big way over time
David Lang
-------------------------
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
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