revolutions per minute - a new metric for measuring responsiveness
 help / color / mirror / Atom feed
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
>

      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