Re: [Make-wifi-fast] [Starlink] [Cake] [Cerowrt-devel] Due Aug 2: Internet Quality workshop CFP for the internet architecture board

["Rodney W. Grimes" <starlink@gndrsh.dnsmgr.net>]

> The distance matrix defines signal attenuations/loss between pairs.  It's
> straightforward to create a distance matrix that has hidden nodes because
> all "signal  loss" between pairs is defined.  Let's say a 120dB attenuation
> path will cause a node to be hidden as an example.
> 
>      A    B     C    D
> A   -   35   120   65
> B         -      65   65
> C               -       65
> D                         -
> 
> So in the above, AC are hidden from each other but nobody else is. It does
> assume symmetry between pairs but that's typically true.

That is not correct, symmetry in the RF world, especially wifi, is rare
due to topology issues.  A high transmitter, A,  and a low receiver, B,
has a good path A - > B, but a very weak path B -> A.   Multipathing
is another major issue that causes assymtry.

> 
> The RF device takes these distance matrices as settings and calculates the
> five branch tree values (as demonstrated in the video). There are
> limitations to solutions though but I've found those not to be an issue to
> date. I've been able to produce hidden nodes quite readily. Add the phase
> shifters and spatial stream powers can also be affected, but this isn't
> shown in this simple example.
> 
> Bob
> 
> On Mon, Aug 2, 2021 at 8:12 PM David Lang <david@lang.hm> wrote:
> 
> > I guess it depends on what you are intending to test. If you are not going
> > to
> > tinker with any of the over-the-air settings (including the number of
> > packets
> > transmitted in one aggregate), the details of what happen over the air
> > don't
> > matter much.
> >
> > But if you are going to be doing any tinkering with what is getting sent,
> > and
> > you ignore the hidden transmitter type problems, you will create a
> > solution that
> > seems to work really well in the lab and falls on it's face out in the
> > wild
> > where spectrum overload and hidden transmitters are the norm (at least in
> > urban
> > areas), not rare corner cases.
> >
> > you don't need to include them in every test, but you need to have a way
> > to
> > configure your lab to include them before you consider any
> > settings/algorithm
> > ready to try in the wild.
> >
> > David Lang
> >
> > On Mon, 2 Aug 2021, Bob McMahon wrote:
> >
> > > We find four nodes, a primary BSS and an adjunct one quite good for lots
> > of
> > > testing.  The six nodes allows for a primary BSS and two adjacent ones.
> > We
> > > want to minimize complexity to necessary and sufficient.
> > >
> > > The challenge we find is having variability (e.g. montecarlos) that's
> > > reproducible and has relevant information. Basically, the distance
> > matrices
> > > have h-matrices as their elements. Our chips can provide these
> > h-matrices.
> > >
> > > The parts for solid state programmable attenuators and phase shifters
> > > aren't very expensive. A device that supports a five branch tree and 2x2
> > > MIMO seems a very good starting point.
> > >
> > > Bob
> > >
> > > On Mon, Aug 2, 2021 at 4:55 PM Ben Greear <greearb@candelatech.com>
> > wrote:
> > >
> > >> On 8/2/21 4:16 PM, David Lang wrote:
> > >>> If you are going to setup a test environment for wifi, you need to
> > >> include the ability to make a fe cases that only happen with RF, not
> > with
> > >> wired networks and
> > >>> are commonly overlooked
> > >>>
> > >>> 1. station A can hear station B and C but they cannot hear each other
> > >>> 2. station A can hear station B but station B cannot hear station A 3.
> > >> station A can hear that station B is transmitting, but not with a strong
> > >> enough signal to
> > >>> decode the signal (yes in theory you can work around interference, but
> > >> in practice interference is still a real thing)
> > >>>
> > >>> David Lang
> > >>>
> > >>
> > >> To add to this, I think you need lots of different station devices,
> > >> different capabilities (/n, /ac, /ax, etc)
> > >> different numbers of spatial streams, and different distances from the
> > >> AP.  From download queueing perspective, changing
> > >> the capabilities may be sufficient while keeping all stations at same
> > >> distance.  This assumes you are not
> > >> actually testing the wifi rate-ctrl alg. itself, so different throughput
> > >> levels for different stations would be enough.
> > >>
> > >> So, a good station emulator setup (and/or pile of real stations) and a
> > few
> > >> RF chambers and
> > >> programmable attenuators and you can test that setup...
> > >>
> > >>  From upload perspective, I guess same setup would do the job.
> > >> Queuing/fairness might depend a bit more on the
> > >> station devices, emulated or otherwise, but I guess a clever AP could
> > >> enforce fairness in upstream direction
> > >> too by implementing per-sta queues.
> > >>
> > >> Thanks,
> > >> Ben
> > >>
> > >> --
> > >> Ben Greear <greearb@candelatech.com>
> > >> Candela Technologies Inc  http://www.candelatech.com
> > >>
> > >
> > >
> >
> 
> -- 
> 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.

[ Charset UTF-8 unsupported, converting... ]
> _______________________________________________
> Starlink mailing list
> Starlink@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/starlink
>