From: Frantisek Borsik <frantisek.borsik@gmail.com>
To: bob.mcmahon@umbernetworks.com
Cc: David Lang <david@lang.hm>,
"Livingood, Jason" <Jason_Livingood@comcast.com>,
Cake List <cake@lists.bufferbloat.net>,
Make-Wifi-fast <make-wifi-fast@lists.bufferbloat.net>,
bloat <bloat@lists.bufferbloat.net>,
Jeremy Austin via Rpm <rpm@lists.bufferbloat.net>,
codel@lists.bufferbloat.net,
"Dave.seddon Ca" <dave.seddon.ca@gmail.com>,
William Fisher <zzyzxr99@gmail.com>,
Igor Aleinikov <igor.aleinikov@adnacom.com>,
Jim <jim@iniholdings.com>, Jiml <jiml@quicksmart.com>,
Douglas Fairbairn <dfairbairn@megachips.com>,
Thomas <thomas@monjalon.net>,
Tim Odriscoll <tim.odriscoll@intel.com>,
Morten <morten@broerup.com>,
Sebastian Moeller <sebastian.moeller@gmail.com>,
Mt Denicolo <mt.denicolo@gmail.com>,
Mmcmahon01 <mmcmahon01@gmail.com>,
Santanu Sinha <santanusinha@yahoo.com>,
Matthew <matthew@mteley.com>, Koen DS <koen0607@gmail.com>,
Shotaro Saito <ssaito@megachips.com>, dan <dandenson@gmail.com>
Subject: [Rpm] Re: [Bloat] Re: [Cake] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon
Date: Thu, 21 May 2026 21:42:48 +0200 [thread overview]
Message-ID: <CAJUtOOgRnf51JWOgvS0oGc1iuqHKMfbn5TtNTJaQfZc7J7nALg@mail.gmail.com> (raw)
In-Reply-To: <f762d3cc760d60deea7d74adf563ce37@umbernetworks.com>
Saw this one from Bob on LinkedIn - maybe there is someone interested
lurking here...:
"Umber is looking for a Bay Area cable tech (contract, part-time to start)
as we prepare to ship our UAX-8 concentrator.
Each install uses a hybrid cable: dual fiber for data plus copper that
powers the remote radio head. The job is to cut to length from a 1000 ft
spool, terminate with a pigtail, and verify optical power and low-voltage
delivery before units go out.
The Meta Level Up training is free. Umber will provide the splicing and
power-testing equipment. First units and our power distribution system
should be ready by late summer."
https://www.linkedin.com/posts/robert-bob-mcmahon-b1a42a1_levelup-fiber-technician-pathway-meta-data-activity-7463251969630097408-AcWJ?
All the best,
Frank
Frantisek (Frank) Borsik
*In loving memory of Dave Täht: *1965-2025
https://libreqos.io/2025/04/01/in-loving-memory-of-dave/
https://www.linkedin.com/in/frantisekborsik
Signal, Telegram, WhatsApp: +421919416714
iMessage, mobile: +420775230885
Skype: casioa5302ca
frantisek.borsik@gmail.com
On Wed, May 20, 2026 at 12:45 AM <bob.mcmahon@umbernetworks.com> wrote:
> > the reason home wifi is so bad is because there is no coordination
> > between the wifi in the diffeent houses/apartments. you don't need to
> > tie all those devices into a single network to solve that, and unless
> > you do solve the coordination problem, there is no way for you to make
> > the rf environment better.
> >
> > coordination may only be an 80% solution compared to this, but 80% is a
> > lot.
> >
>
> David,
>
> Even granting the 80% claim, which I don't think holds across 134M
> occupied homes in the US once you measure broadly enough, the loss
> functions shift dramatically with density, workload, and metric.
> Throughput, tail latency, and jitter under load do not degrade for the
> same reasons, and they do not reduce to a single number.
>
> Even inside a single home with one AP and no neighbors, Wi-Fi exhibits
> pathologies unrelated to cross-network coordination: hidden queues,
> retry storms, aggregation bursts, EDCA backoff variance, roaming
> decisions made with stale information, and firmware behavior the
> operator cannot observe or control.
>
> ECN marking, L4S, pacing, and AQMs all assume the layer below them
> provides observable and reasonably bounded service time. Conventional
> APs do not provide that. Coordinating neighbors does not fix it.
>
> The deeper problem is architectural. Conventional Wi-Fi scatters the
> observations. No AP sees enough state to make globally correct decisions
> across space, time, and frequency, so every AP treats overlap as loss
> and reacts using local, partial information. Neighbor coordination
> cannot recover information that was never collected, nor can it impose
> deterministic service intervals on autonomous 802.11 MAC state machines
> running in opaque vendor firmware.
>
> Fi-Wi inverts that architecture. The 802.11 MAC moves to the
> concentrator, where the observations are co-located and scheduling
> decisions are made in software the operator or building owner controls.
> The radios handle PHY/RF execution. One RRH or twenty, the architectural
> property is the same: airtime scheduling, transport feedback, and
> observability exist in one place.
>
> I put together a small animation showing how contention probability
> rises rapidly even with relatively small contention windows and moderate
> active station counts. It helps visualize why systems often become
> MAC-limited before PHY-limited:
>
> https://www.umbernetworks.com/csma-preview.html
>
> The "single network" is ultimately a human management abstraction. RF,
> like rats, does not respect property boundaries. The medium is shared
> whether or not the management plane pretends otherwise. Coordination
> between autonomous networks tries to paper over a partition we invented,
> and the ceiling is set by the partition. Fi-Wi doesn't eliminate the
> partition globally. It dissolves it within a coverage area, by replacing
> autonomous APs with radio arrays serving one MAC. Inside the domain,
> there is no partition to paper over. Engineering that matches physics is
> the goal.
>
> Bob
>
prev parent reply other threads:[~2026-05-21 19:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-14 16:46 [Rpm] "Fi-Wi is a new forwarding plane for wireless" - Bob McMahon Frantisek Borsik
2026-05-14 15:09 ` [Rpm] Re: [Cake] " David Lang
2026-05-14 17:26 ` Frantisek Borsik
2026-05-14 19:38 ` bob.mcmahon
2026-05-14 19:55 ` David Lang
2026-05-15 11:11 ` bob.mcmahon
2026-05-15 13:57 ` David Lang
2026-05-15 14:18 ` David Lang
2026-05-15 15:17 ` bob.mcmahon
2026-05-19 13:52 ` [Rpm] Re: [Bloat] " Livingood, Jason
2026-05-19 18:59 ` David Lang
2026-05-19 22:45 ` bob.mcmahon
2026-05-21 19:42 ` Frantisek Borsik [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://lists.bufferbloat.net/postorius/lists/rpm.lists.bufferbloat.net/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJUtOOgRnf51JWOgvS0oGc1iuqHKMfbn5TtNTJaQfZc7J7nALg@mail.gmail.com \
--to=frantisek.borsik@gmail.com \
--cc=Jason_Livingood@comcast.com \
--cc=bloat@lists.bufferbloat.net \
--cc=bob.mcmahon@umbernetworks.com \
--cc=cake@lists.bufferbloat.net \
--cc=codel@lists.bufferbloat.net \
--cc=dandenson@gmail.com \
--cc=dave.seddon.ca@gmail.com \
--cc=david@lang.hm \
--cc=dfairbairn@megachips.com \
--cc=igor.aleinikov@adnacom.com \
--cc=jim@iniholdings.com \
--cc=jiml@quicksmart.com \
--cc=koen0607@gmail.com \
--cc=make-wifi-fast@lists.bufferbloat.net \
--cc=matthew@mteley.com \
--cc=mmcmahon01@gmail.com \
--cc=morten@broerup.com \
--cc=mt.denicolo@gmail.com \
--cc=rpm@lists.bufferbloat.net \
--cc=santanusinha@yahoo.com \
--cc=sebastian.moeller@gmail.com \
--cc=ssaito@megachips.com \
--cc=thomas@monjalon.net \
--cc=tim.odriscoll@intel.com \
--cc=zzyzxr99@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox