Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[dpreed]

Without custom silicon, doing what I was talking about would involve non standard MAC power management, which would require all devices to agree.

David Lang's explanation was the essence of what I meant. the transmission from access point on multiple channels is just digital addition if the DACs have enough bits per sample. to make sure that the signals to the AP are equalized, just transmit at a power that makes that approximately true... which means a power amp with at most 30 dB of dynamic gain setting. typical dynamic path attenuation range (strongest to weakest ratio) among stations served by an AP is < 20 dB from my past experiments on well operating-installtions, but 25 can be seen in reflection heavy environments.-----Original Message-----
From: "David Lang" <david@lang.hm>
Sent: Fri, Jun 24, 2016 at 1:19 am
To: "Bob McMahon" <bob.mcmahon@broadcom.com>
Cc: "Bob McMahon" <bob.mcmahon@broadcom.com>, make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" <cerowrt-devel@lists.bufferbloat.net>
Subject: Re: [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

well, with the kickstarter, I think they are selling a bill of goods.

Just using the DFS channels and aggregating them as supported by N and AC 
standards would do wonders (as long as others near you don't do the same)

David Lang

On Thu, 23 Jun 2016, Bob McMahon wrote:

> Date: Thu, 23 Jun 2016 20:01:22 -0700
> From: Bob McMahon 
> To: David Lang 
> Cc: dpreed@reed.com, make-wifi-fast@lists.bufferbloat.net,
>     "cerowrt-devel@lists.bufferbloat.net"
>     
> Subject: Re: [Make-wifi-fast] more well funded attempts showing market demand
>     for better wifi
> 
> Thanks for the clarification.   Though now I'm confused about how all the
> channels would be used simultaneously with an AP only solution (which is my
> understanding of the kickstarter campaign.)
>
> Bob
>
> On Thu, Jun 23, 2016 at 7:14 PM, David Lang  wrote:
>
>> I think he is meaning when one unit is talking to one AP the signal levels
>> across multiple channels will be similar. Which is probably fairly true.
>>
>>
>> David Lang
>>
>> On Thu, 23 Jun 2016, Bob McMahon wrote:
>>
>> Curious, where does the "in a LAN setup, the variability in [receive]
>>> signal strength is likely small enough" assertion come?   Any specific
>>> power numbers here? We test with many combinations of "signal strength
>>> variability" (e.g. deltas range from 0 dBm -  50 dBm) and per different
>>> channel conditions.  This includes power variability within the spatial
>>> streams' MiMO transmission.   It would be helpful to have some physics
>>> combined with engineering to produce some pragmatic limits to this.
>>>
>>> Also, mobile devices have a goal of reducing power in order to be
>>> efficient
>>> with their battery (vs a goal to balance power such that an AP can
>>> receive simultaneously.)  Power per bit usually trumps most other design
>>> goals.  There market for battery powered wi-fi devices drives a
>>> semi-conductor mfg's revenue so my information come with that bias.
>>>
>>> Bob
>>>
>>> On Thu, Jun 23, 2016 at 1:48 PM,  wrote:
>>>
>>> The actual issues of transmitting on multiple channels at the same time
>>>> are quite minor if you do the work in the digital domain (pre-DAC).  You
>>>> just need a higher sampling rate in the DAC and add the two signals
>>>> together (and use a wideband filter that covers all the channels).  No RF
>>>> problem.
>>>>
>>>> Receiving multiple transmissions in different channels is pretty much the
>>>> same problem - just digitize (ADC) a wider bandwidth and separate in the
>>>> digital domain.  the only real issue on receive is equalization - if you
>>>> receive two different signals at different receive signal strengths, the
>>>> lower strength signal won't get as much dynamic range in its samples.
>>>>
>>>> But in a LAN setup, the variability in signal strength is likely small
>>>> enough that you can cover that with more ADC bits (or have the MAC
>>>> protocol
>>>> manage the station transmit power so that signals received at the AP are
>>>> nearly the same power.
>>>>
>>>> Equalization at transmit works very well when there is a central AP (as
>>>> in
>>>> cellular or normal WiFi systems).
>>>>
>>>>
>>>>
>>>> On Thursday, June 23, 2016 4:28pm, "Bob McMahon" >>> bob.mcmahon@broadcom.com>
>>>> said:
>>>>
>>>> _______________________________________________
>>>>> Make-wifi-fast mailing list
>>>>> Make-wifi-fast@lists.bufferbloat.net
>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>> An AP per room/area, reducing the tx power (beacon range) has been my
>>>>> approach and has scaled very well.   It does require some wires to each
>>>>>
>>>> AP
>>>>
>>>>> but I find that paying an electrician to run some quality wiring to
>>>>>
>>>> things
>>>>
>>>>> that are to remain stationary has been well worth the cost.
>>>>>
>>>>> just my $0.02,
>>>>> Bob
>>>>>
>>>>> On Thu, Jun 23, 2016 at 1:10 PM, David Lang  wrote:
>>>>>
>>>>> Well, just using the 5GHz DFS channels in 80MHz or 160 MHz wide chunks
>>>>>> would be a huge improvement, not many people are using them (yet), and
>>>>>>
>>>>> the
>>>>
>>>>> wide channels let you get a lot of data out at once. If everything is
>>>>>> within a good range of the AP, this would work pretty well. If you end
>>>>>>
>>>>> up
>>>>
>>>>> needing multiple APs, or you have many stations, I expect that you will
>>>>>>
>>>>> be
>>>>
>>>>> better off with more APs at lower power, each using different channels.
>>>>>>
>>>>>> David Lang
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, 23 Jun 2016, Bob McMahon wrote:
>>>>>>
>>>>>> Date: Thu, 23 Jun 2016 12:55:19 -0700
>>>>>>
>>>>>>> From: Bob McMahon 
>>>>>>> To: Dave Taht 
>>>>>>> Cc: make-wifi-fast@lists.bufferbloat.net,
>>>>>>>     "cerowrt-devel@lists.bufferbloat.net"
>>>>>>>     
>>>>>>> Subject: Re: [Make-wifi-fast] more well funded attempts showing market
>>>>>>> demand
>>>>>>>     for better wifi
>>>>>>>
>>>>>>>
>>>>>>> hmm, I'm skeptical.   To use multiple carriers simultaneously is
>>>>>>>
>>>>>> difficult
>>>>
>>>>> per RF issues.   Even if that is somehow resolved, to increase
>>>>>>>
>>>>>> throughput
>>>>
>>>>> usually requires some form of channel bonding, i.e. needed on both
>>>>>>>
>>>>>> sides,
>>>>
>>>>> and brings in issues with preserving frame ordering.  If this is just
>>>>>>> channel hopping, that needs coordination between both sides (and isn't
>>>>>>> simultaneous, possibly costing more than any potential gain.)   An AP
>>>>>>>
>>>>>> only
>>>>
>>>>> solution can use channel switch announcements (CSA) but there is a
>>>>>>>
>>>>>> cost to
>>>>
>>>>> those as well.
>>>>>>>
>>>>>>> I guess don't see any break though here and the marketing on the site
>>>>>>> seems
>>>>>>> to indicate something beyond physics, at least the physics that I
>>>>>>> understand.  Always willing to learn and be corrected if I'm
>>>>>>> misunderstanding things.
>>>>>>>
>>>>>>> Bob
>>>>>>>
>>>>>>> On Wed, Jun 22, 2016 at 10:18 AM, Dave Taht 
>>>>>>>
>>>>>> wrote:
>>>>
>>>>>
>>>>>>> On Wed, Jun 22, 2016 at 10:03 AM, Dave Taht 
>>>>>>>
>>>>>> wrote:
>>>>
>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi?ref=backerkit
>>>>
>>>>>
>>>>>>>>
>>>>>>>>> "Portal is the first and only router specifically engineered to cut
>>>>>>>>> through and avoid congestion, delivering consistent,
>>>>>>>>> high-performance
>>>>>>>>> WiFi with greater coverage throughout your home.
>>>>>>>>>
>>>>>>>>> Its proprietary spectrum turbocharger technology provides access to
>>>>>>>>> 300% more of the radio airwaves than any other router, improving
>>>>>>>>> performance by as much as 300x, and range and coverage by as much as
>>>>>>>>> 2x in crowded settings, such as city homes and multi-unit
>>>>>>>>> apartments"
>>>>>>>>>
>>>>>>>>> It sounds like they are promising working DFS support.
>>>>>>>>>
>>>>>>>>>
>>>>>>>> It's not clear what chipset they are using (they are claiming wave2)
>>>>>>>> -
>>>>>>>> but they are at least publicly claiming to be using openwrt. So I
>>>>>>>> threw in enough to order one for september, just so I could comment
>>>>>>>> on
>>>>>>>> their kickstarter page. :)
>>>>>>>>
>>>>>>>> I'd have loved to have got in earlier (early shipments are this month
>>>>>>>> apparently), but those were sold out.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi/comments
>>>>
>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>>> Dave Täht
>>>>>>>>> Let's go make home routers and wifi faster! With better software!
>>>>>>>>> http://blog.cerowrt.org
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Dave Täht
>>>>>>>> Let's go make home routers and wifi faster! With better software!
>>>>>>>> http://blog.cerowrt.org
>>>>>>>> _______________________________________________
>>>>>>>> Make-wifi-fast mailing list
>>>>>>>> Make-wifi-fast@lists.bufferbloat.net
>>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>> Make-wifi-fast mailing list
>>>>>> Make-wifi-fast@lists.bufferbloat.net
>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 12755 bytes --]

Is there a specific goal in mind?  This seems an AP tx centric proposal,
though I may not be fully understanding it.  I'm also curious as why not
scale in spatial domain vs the frequency domain, i.e. AP and STAs can also
scale using MiMO.  Why not just do that? So many phones today are 1x1, some
2x2 and few 3x3.   Yet APs are moving to 4x4 and I think the standard
supports 8x8.  (I'm not sure the marginal transistor count increase per
each approach.)  On the AP tx side, MuMIMO is also there which I think is
similar to the DAC proposal.

I'm far from a PHY & DSP expert, but I think the simultaneous AP receive is
the most difficult issue per the power variations, aka SNR.  Each of the
mobile device energies is affected per inverse square law (unless some form
of wave guide is used.)  Hence wi-fi use of time domain slots prior to
transmit (no longer simultaneous in time.)  Particularly needed for devices
that communicate with one another.  Unfortunately, "collocated"
energy/information sources must honor this TDM  even when not communication
with one another per tragedy of the commons.  (Agreed there is no such
thing as a collision so let's redefine it to mean that the receiver is
unable to receive per RF energy "confusion", still a tragedy of the
commons.  I don't know what drives the limits to DSP decode that could
minimize or eliminate  this tragedy.)

At the end of the day, would the ideal network would resemble a wired
ethernet (including ethernet switch fabric) without the waveguides (or
wires/fibers)?  From that perspective, here are some thoughts to the goals

o)  TX op/access to transmit driven to zero.  (Collision avoidance isn't
nearly as good as instantaneous collision detect in this context, though
"collision" should replaced with "confusion")
o)  RX confusion detection time propagated to stop offending TX(s) driven
to zero
o)  Support of different encodings (e..g phy rates) pushes towards virtual
output queueing prior (queuing at the transmitter)
o)  Power per bit xfered towards zero or driven per cost & energy density
of batteries.  Note: Atomic batteries not allowed per humans being involved.
o)  Transistor count (chip cost) per bit moved driven by Moore's law and
those economics
o)  Reduce "collision/confusion" domain (less STAs per AP) ideally to zero

Just some thoughts off the top of my head.  Please do comment and correct.
Thanks in advance for the discussion.

Bob




On Fri, Jun 24, 2016 at 2:24 PM, <dpreed@reed.com> wrote:

> Without custom silicon, doing what I was talking about would involve non
> standard MAC power management, which would require all devices to agree.
>
> David Lang's explanation was the essence of what I meant. the transmission
> from access point on multiple channels is just digital addition if the DACs
> have enough bits per sample. to make sure that the signals to the AP are
> equalized, just transmit at a power that makes that approximately true...
> which means a power amp with at most 30 dB of dynamic gain setting. typical
> dynamic path attenuation range (strongest to weakest ratio) among stations
> served by an AP is < 20 dB from my past experiments on well
> operating-installtions, but 25 can be seen in reflection heavy
> environments.-----Original Message-----
> From: "David Lang" <david@lang.hm>
> Sent: Fri, Jun 24, 2016 at 1:19 am
> To: "Bob McMahon" <bob.mcmahon@broadcom.com>
> Cc: "Bob McMahon" <bob.mcmahon@broadcom.com>,
> make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net"
> <cerowrt-devel@lists.bufferbloat.net>
> Subject: Re: [Make-wifi-fast] more well funded attempts showing market
> demandfor better wifi
>
> well, with the kickstarter, I think they are selling a bill of goods.
>
> Just using the DFS channels and aggregating them as supported by N and AC
> standards would do wonders (as long as others near you don't do the same)
>
> David Lang
>
> On Thu, 23 Jun 2016, Bob McMahon wrote:
>
> > Date: Thu, 23 Jun 2016 20:01:22 -0700
> > From: Bob McMahon
> > To: David Lang
> > Cc: dpreed@reed.com, make-wifi-fast@lists.bufferbloat.net,
> >     "cerowrt-devel@lists.bufferbloat.net"
> >
> > Subject: Re: [Make-wifi-fast] more well funded attempts showing market
> demand
> >     for better wifi
> >
> > Thanks for the clarification.   Though now I'm confused about how all the
> > channels would be used simultaneously with an AP only solution (which is
> my
> > understanding of the kickstarter campaign.)
> >
> > Bob
> >
> > On Thu, Jun 23, 2016 at 7:14 PM, David Lang  wrote:
> >
> >> I think he is meaning when one unit is talking to one AP the signal
> levels
> >> across multiple channels will be similar. Which is probably fairly true.
> >>
> >>
> >> David Lang
> >>
> >> On Thu, 23 Jun 2016, Bob McMahon wrote:
> >>
> >> Curious, where does the "in a LAN setup, the variability in [receive]
> >>> signal strength is likely small enough" assertion come?   Any specific
> >>> power numbers here? We test with many combinations of "signal strength
> >>> variability" (e.g. deltas range from 0 dBm -  50 dBm) and per different
> >>> channel conditions.  This includes power variability within the spatial
> >>> streams' MiMO transmission.   It would be helpful to have some physics
> >>> combined with engineering to produce some pragmatic limits to this.
> >>>
> >>> Also, mobile devices have a goal of reducing power in order to be
> >>> efficient
> >>> with their battery (vs a goal to balance power such that an AP can
> >>> receive simultaneously.)  Power per bit usually trumps most other
> design
> >>> goals.  There market for battery powered wi-fi devices drives a
> >>> semi-conductor mfg's revenue so my information come with that bias.
> >>>
> >>> Bob
> >>>
> >>> On Thu, Jun 23, 2016 at 1:48 PM,  wrote:
> >>>
> >>> The actual issues of transmitting on multiple channels at the same time
> >>>> are quite minor if you do the work in the digital domain (pre-DAC).
> You
> >>>> just need a higher sampling rate in the DAC and add the two signals
> >>>> together (and use a wideband filter that covers all the channels).
> No RF
> >>>> problem.
> >>>>
> >>>> Receiving multiple transmissions in different channels is pretty much
> the
> >>>> same problem - just digitize (ADC) a wider bandwidth and separate in
> the
> >>>> digital domain.  the only real issue on receive is equalization - if
> you
> >>>> receive two different signals at different receive signal strengths,
> the
> >>>> lower strength signal won't get as much dynamic range in its samples.
> >>>>
> >>>> But in a LAN setup, the variability in signal strength is likely small
> >>>> enough that you can cover that with more ADC bits (or have the MAC
> >>>> protocol
> >>>> manage the station transmit power so that signals received at the AP
> are
> >>>> nearly the same power.
> >>>>
> >>>> Equalization at transmit works very well when there is a central AP
> (as
> >>>> in
> >>>> cellular or normal WiFi systems).
> >>>>
> >>>>
> >>>>
> >>>> On Thursday, June 23, 2016 4:28pm, "Bob McMahon" >>>
> bob.mcmahon@broadcom.com>
> >>>> said:
> >>>>
> >>>> _______________________________________________
> >>>>> Make-wifi-fast mailing list
> >>>>> Make-wifi-fast@lists.bufferbloat.net
> >>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> >>>>> An AP per room/area, reducing the tx power (beacon range) has been my
> >>>>> approach and has scaled very well.   It does require some wires to
> each
> >>>>>
> >>>> AP
> >>>>
> >>>>> but I find that paying an electrician to run some quality wiring to
> >>>>>
> >>>> things
> >>>>
> >>>>> that are to remain stationary has been well worth the cost.
> >>>>>
> >>>>> just my $0.02,
> >>>>> Bob
> >>>>>
> >>>>> On Thu, Jun 23, 2016 at 1:10 PM, David Lang  wrote:
> >>>>>
> >>>>> Well, just using the 5GHz DFS channels in 80MHz or 160 MHz wide
> chunks
> >>>>>> would be a huge improvement, not many people are using them (yet),
> and
> >>>>>>
> >>>>> the
> >>>>
> >>>>> wide channels let you get a lot of data out at once. If everything is
> >>>>>> within a good range of the AP, this would work pretty well. If you
> end
> >>>>>>
> >>>>> up
> >>>>
> >>>>> needing multiple APs, or you have many stations, I expect that you
> will
> >>>>>>
> >>>>> be
> >>>>
> >>>>> better off with more APs at lower power, each using different
> channels.
> >>>>>>
> >>>>>> David Lang
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> On Thu, 23 Jun 2016, Bob McMahon wrote:
> >>>>>>
> >>>>>> Date: Thu, 23 Jun 2016 12:55:19 -0700
> >>>>>>
> >>>>>>> From: Bob McMahon
> >>>>>>> To: Dave Taht
> >>>>>>> Cc: make-wifi-fast@lists.bufferbloat.net,
> >>>>>>>     "cerowrt-devel@lists.bufferbloat.net"
> >>>>>>>
> >>>>>>> Subject: Re: [Make-wifi-fast] more well funded attempts showing
> market
> >>>>>>> demand
> >>>>>>>     for better wifi
> >>>>>>>
> >>>>>>>
> >>>>>>> hmm, I'm skeptical.   To use multiple carriers simultaneously is
> >>>>>>>
> >>>>>> difficult
> >>>>
> >>>>> per RF issues.   Even if that is somehow resolved, to increase
> >>>>>>>
> >>>>>> throughput
> >>>>
> >>>>> usually requires some form of channel bonding, i.e. needed on both
> >>>>>>>
> >>>>>> sides,
> >>>>
> >>>>> and brings in issues with preserving frame ordering.  If this is just
> >>>>>>> channel hopping, that needs coordination between both sides (and
> isn't
> >>>>>>> simultaneous, possibly costing more than any potential gain.)   An
> AP
> >>>>>>>
> >>>>>> only
> >>>>
> >>>>> solution can use channel switch announcements (CSA) but there is a
> >>>>>>>
> >>>>>> cost to
> >>>>
> >>>>> those as well.
> >>>>>>>
> >>>>>>> I guess don't see any break though here and the marketing on the
> site
> >>>>>>> seems
> >>>>>>> to indicate something beyond physics, at least the physics that I
> >>>>>>> understand.  Always willing to learn and be corrected if I'm
> >>>>>>> misunderstanding things.
> >>>>>>>
> >>>>>>> Bob
> >>>>>>>
> >>>>>>> On Wed, Jun 22, 2016 at 10:18 AM, Dave Taht
> >>>>>>>
> >>>>>> wrote:
> >>>>
> >>>>>
> >>>>>>> On Wed, Jun 22, 2016 at 10:03 AM, Dave Taht
> >>>>>>>
> >>>>>> wrote:
> >>>>
> >>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>
> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi?ref=backerkit
> >>>>
> >>>>>
> >>>>>>>>
> >>>>>>>>> "Portal is the first and only router specifically engineered to
> cut
> >>>>>>>>> through and avoid congestion, delivering consistent,
> >>>>>>>>> high-performance
> >>>>>>>>> WiFi with greater coverage throughout your home.
> >>>>>>>>>
> >>>>>>>>> Its proprietary spectrum turbocharger technology provides access
> to
> >>>>>>>>> 300% more of the radio airwaves than any other router, improving
> >>>>>>>>> performance by as much as 300x, and range and coverage by as
> much as
> >>>>>>>>> 2x in crowded settings, such as city homes and multi-unit
> >>>>>>>>> apartments"
> >>>>>>>>>
> >>>>>>>>> It sounds like they are promising working DFS support.
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> It's not clear what chipset they are using (they are claiming
> wave2)
> >>>>>>>> -
> >>>>>>>> but they are at least publicly claiming to be using openwrt. So I
> >>>>>>>> threw in enough to order one for september, just so I could
> comment
> >>>>>>>> on
> >>>>>>>> their kickstarter page. :)
> >>>>>>>>
> >>>>>>>> I'd have loved to have got in earlier (early shipments are this
> month
> >>>>>>>> apparently), but those were sold out.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>
> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi/comments
> >>>>
> >>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>>> Dave Täht
> >>>>>>>>> Let's go make home routers and wifi faster! With better software!
> >>>>>>>>> http://blog.cerowrt.org
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> --
> >>>>>>>> Dave Täht
> >>>>>>>> Let's go make home routers and wifi faster! With better software!
> >>>>>>>> http://blog.cerowrt.org
> >>>>>>>> _______________________________________________
> >>>>>>>> Make-wifi-fast mailing list
> >>>>>>>> Make-wifi-fast@lists.bufferbloat.net
> >>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> _______________________________________________
> >>>>>> Make-wifi-fast mailing list
> >>>>>> Make-wifi-fast@lists.bufferbloat.net
> >>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >
>
>

[-- Attachment #2: Type: text/html, Size: 19582 bytes --]

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 16928 bytes --]

I don't think anyone is trying to do simultanious receive of different stations. 
That is an incredibly difficult thing to do right.

MU-MIMO is aimed at haivng the AP transmit to multiple stations at the same 
time. For the typical browser/streaming use, this traffic is FAR larger than the 
traffic from the stations to the AP. As such, it is worth focusing on optimizing 
this direction.

While an ideal network may resemble a wired network without guides, I don't 
think it's a good idea to think about wifi networks that way.

The reality is that no matter how good you get, a wireless network is going to 
have lots of things that are just not going to happen with wired networks.

1. drastic variations in signal strength.

   On a wired network with a shared buss, the signal strength from all stations 
on the network is going to be very close to the same (a difference of 2x would 
be extreme)

   On a wireless network, with 'normal' omnidirctional antennas, the signal drops 
off with the square of the distance. So if you want to service clients from 1 ft 
to 100 ft away, your signal strength varies by 1000 (4 orders of magnatude), 
this is before you include effects of shielding, bounces, bad antenna alignment, 
etc (which can add several more orders of magnatude of variation)

   The receiver first normalized the strongest part of the signal to a constant 
value, and then digitizes the result, (usually with a 12-14 bit AD converter). 
Since 1000x is ~10 bits, the result of overlapping tranmissions can be one 
signal at 14 bits, and another at <4 bits. This is why digital processing isn't 
able to receive multiple stations at the same time.

2. 'hidden transmitters'

   On modern wired networks, every link has exactly two stations on it, and both 
can transmit at the same time.

   On wireless networks, it's drastically different. You have an unknown number 
of stations (which can come and go without notice).

   Not every station can hear every other station. This means that they can't 
avoid colliding with each other. In theory you can work around this by having 
some central system coordinate all the clients (either by them being told when 
to transmit, or by being given a schedule and having very precise clocks). But 
in practice the central system doesn't know when the clients have something to 
say and so in practice this doesn't work as well (except for special cases like 
voice where there is a constant amount of data to transmit)

3. variable transmit rates and aggregation

   Depending on how strong the signal is between two stations, you have different 
limits to how fast you can transmit data. There are many different standard 
modulations that you can use, but if you use one that's too fast for the signal 
conditions, the receiver isn't going to be able to decode it. If you use one 
that's too slow, you increase the probability that another station will step on 
your signal, scrambling it as far as the receiver is concerned. We now have 
stations on the network that can vary in speed by 100x, and are nearing 1000x 
(1Mb/sec to 1Gb/sec)

   Because there is so much variation in transmit rates, and older stations will 
not be able to understand the newest rates, each transmission starts off with 
some data being transmitted at the slowest available rate, telling any stations 
that are listening that there is data being transmitted for X amount of time, 
even if they can't tell what's going on as the data is being transmitted.

   The combination of this header being transmitted inefficiently, and the fact 
that stations are waiting for a clear window to transmit, means that when you do 
get a chance to transmit, you should send more than one packet at a time. This 
is something Linux is currently not doing well, qdiscs tend to round-robin 
packets without regard to where they are headed. The current work being done 
here with the queues is improving both throughput and latency by fixing this 
problem.


You really need to think differently when dealing with wireless network. The 
early wifi drivers tried to make them look just like a wired network, and we 
have found that we just needed too much other stuff to be successful whith that 
mindset.

The Analog/Radio side of things really is important, and can't just be 
abstracted away.

David Lang

On Sun, 26 Jun 2016, Bob McMahon wrote:

> Is there a specific goal in mind?  This seems an AP tx centric proposal,
> though I may not be fully understanding it.  I'm also curious as why not
> scale in spatial domain vs the frequency domain, i.e. AP and STAs can also
> scale using MiMO.  Why not just do that? So many phones today are 1x1, some
> 2x2 and few 3x3.   Yet APs are moving to 4x4 and I think the standard
> supports 8x8.  (I'm not sure the marginal transistor count increase per
> each approach.)  On the AP tx side, MuMIMO is also there which I think is
> similar to the DAC proposal.
>
> I'm far from a PHY & DSP expert, but I think the simultaneous AP receive is
> the most difficult issue per the power variations, aka SNR.  Each of the
> mobile device energies is affected per inverse square law (unless some form
> of wave guide is used.)  Hence wi-fi use of time domain slots prior to
> transmit (no longer simultaneous in time.)  Particularly needed for devices
> that communicate with one another.  Unfortunately, "collocated"
> energy/information sources must honor this TDM  even when not communication
> with one another per tragedy of the commons.  (Agreed there is no such
> thing as a collision so let's redefine it to mean that the receiver is
> unable to receive per RF energy "confusion", still a tragedy of the
> commons.  I don't know what drives the limits to DSP decode that could
> minimize or eliminate  this tragedy.)
>
> At the end of the day, would the ideal network would resemble a wired
> ethernet (including ethernet switch fabric) without the waveguides (or
> wires/fibers)?  From that perspective, here are some thoughts to the goals
>
> o)  TX op/access to transmit driven to zero.  (Collision avoidance isn't
> nearly as good as instantaneous collision detect in this context, though
> "collision" should replaced with "confusion")
> o)  RX confusion detection time propagated to stop offending TX(s) driven
> to zero
> o)  Support of different encodings (e..g phy rates) pushes towards virtual
> output queueing prior (queuing at the transmitter)
> o)  Power per bit xfered towards zero or driven per cost & energy density
> of batteries.  Note: Atomic batteries not allowed per humans being involved.
> o)  Transistor count (chip cost) per bit moved driven by Moore's law and
> those economics
> o)  Reduce "collision/confusion" domain (less STAs per AP) ideally to zero
>
> Just some thoughts off the top of my head.  Please do comment and correct.
> Thanks in advance for the discussion.
>
> Bob
>
>
>
>
> On Fri, Jun 24, 2016 at 2:24 PM, <dpreed@reed.com> wrote:
>
>> Without custom silicon, doing what I was talking about would involve non
>> standard MAC power management, which would require all devices to agree.
>>
>> David Lang's explanation was the essence of what I meant. the transmission
>> from access point on multiple channels is just digital addition if the DACs
>> have enough bits per sample. to make sure that the signals to the AP are
>> equalized, just transmit at a power that makes that approximately true...
>> which means a power amp with at most 30 dB of dynamic gain setting. typical
>> dynamic path attenuation range (strongest to weakest ratio) among stations
>> served by an AP is < 20 dB from my past experiments on well
>> operating-installtions, but 25 can be seen in reflection heavy
>> environments.-----Original Message-----
>> From: "David Lang" <david@lang.hm>
>> Sent: Fri, Jun 24, 2016 at 1:19 am
>> To: "Bob McMahon" <bob.mcmahon@broadcom.com>
>> Cc: "Bob McMahon" <bob.mcmahon@broadcom.com>,
>> make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net"
>> <cerowrt-devel@lists.bufferbloat.net>
>> Subject: Re: [Make-wifi-fast] more well funded attempts showing market
>> demandfor better wifi
>>
>> well, with the kickstarter, I think they are selling a bill of goods.
>>
>> Just using the DFS channels and aggregating them as supported by N and AC
>> standards would do wonders (as long as others near you don't do the same)
>>
>> David Lang
>>
>> On Thu, 23 Jun 2016, Bob McMahon wrote:
>>
>>> Date: Thu, 23 Jun 2016 20:01:22 -0700
>>> From: Bob McMahon
>>> To: David Lang
>>> Cc: dpreed@reed.com, make-wifi-fast@lists.bufferbloat.net,
>>>     "cerowrt-devel@lists.bufferbloat.net"
>>>
>>> Subject: Re: [Make-wifi-fast] more well funded attempts showing market
>> demand
>>>     for better wifi
>>>
>>> Thanks for the clarification.   Though now I'm confused about how all the
>>> channels would be used simultaneously with an AP only solution (which is
>> my
>>> understanding of the kickstarter campaign.)
>>>
>>> Bob
>>>
>>> On Thu, Jun 23, 2016 at 7:14 PM, David Lang  wrote:
>>>
>>>> I think he is meaning when one unit is talking to one AP the signal
>> levels
>>>> across multiple channels will be similar. Which is probably fairly true.
>>>>
>>>>
>>>> David Lang
>>>>
>>>> On Thu, 23 Jun 2016, Bob McMahon wrote:
>>>>
>>>> Curious, where does the "in a LAN setup, the variability in [receive]
>>>>> signal strength is likely small enough" assertion come?   Any specific
>>>>> power numbers here? We test with many combinations of "signal strength
>>>>> variability" (e.g. deltas range from 0 dBm -  50 dBm) and per different
>>>>> channel conditions.  This includes power variability within the spatial
>>>>> streams' MiMO transmission.   It would be helpful to have some physics
>>>>> combined with engineering to produce some pragmatic limits to this.
>>>>>
>>>>> Also, mobile devices have a goal of reducing power in order to be
>>>>> efficient
>>>>> with their battery (vs a goal to balance power such that an AP can
>>>>> receive simultaneously.)  Power per bit usually trumps most other
>> design
>>>>> goals.  There market for battery powered wi-fi devices drives a
>>>>> semi-conductor mfg's revenue so my information come with that bias.
>>>>>
>>>>> Bob
>>>>>
>>>>> On Thu, Jun 23, 2016 at 1:48 PM,  wrote:
>>>>>
>>>>> The actual issues of transmitting on multiple channels at the same time
>>>>>> are quite minor if you do the work in the digital domain (pre-DAC).
>> You
>>>>>> just need a higher sampling rate in the DAC and add the two signals
>>>>>> together (and use a wideband filter that covers all the channels).
>> No RF
>>>>>> problem.
>>>>>>
>>>>>> Receiving multiple transmissions in different channels is pretty much
>> the
>>>>>> same problem - just digitize (ADC) a wider bandwidth and separate in
>> the
>>>>>> digital domain.  the only real issue on receive is equalization - if
>> you
>>>>>> receive two different signals at different receive signal strengths,
>> the
>>>>>> lower strength signal won't get as much dynamic range in its samples.
>>>>>>
>>>>>> But in a LAN setup, the variability in signal strength is likely small
>>>>>> enough that you can cover that with more ADC bits (or have the MAC
>>>>>> protocol
>>>>>> manage the station transmit power so that signals received at the AP
>> are
>>>>>> nearly the same power.
>>>>>>
>>>>>> Equalization at transmit works very well when there is a central AP
>> (as
>>>>>> in
>>>>>> cellular or normal WiFi systems).
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thursday, June 23, 2016 4:28pm, "Bob McMahon" >>>
>> bob.mcmahon@broadcom.com>
>>>>>> said:
>>>>>>
>>>>>> _______________________________________________
>>>>>>> Make-wifi-fast mailing list
>>>>>>> Make-wifi-fast@lists.bufferbloat.net
>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>> An AP per room/area, reducing the tx power (beacon range) has been my
>>>>>>> approach and has scaled very well.   It does require some wires to
>> each
>>>>>>>
>>>>>> AP
>>>>>>
>>>>>>> but I find that paying an electrician to run some quality wiring to
>>>>>>>
>>>>>> things
>>>>>>
>>>>>>> that are to remain stationary has been well worth the cost.
>>>>>>>
>>>>>>> just my $0.02,
>>>>>>> Bob
>>>>>>>
>>>>>>> On Thu, Jun 23, 2016 at 1:10 PM, David Lang  wrote:
>>>>>>>
>>>>>>> Well, just using the 5GHz DFS channels in 80MHz or 160 MHz wide
>> chunks
>>>>>>>> would be a huge improvement, not many people are using them (yet),
>> and
>>>>>>>>
>>>>>>> the
>>>>>>
>>>>>>> wide channels let you get a lot of data out at once. If everything is
>>>>>>>> within a good range of the AP, this would work pretty well. If you
>> end
>>>>>>>>
>>>>>>> up
>>>>>>
>>>>>>> needing multiple APs, or you have many stations, I expect that you
>> will
>>>>>>>>
>>>>>>> be
>>>>>>
>>>>>>> better off with more APs at lower power, each using different
>> channels.
>>>>>>>>
>>>>>>>> David Lang
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, 23 Jun 2016, Bob McMahon wrote:
>>>>>>>>
>>>>>>>> Date: Thu, 23 Jun 2016 12:55:19 -0700
>>>>>>>>
>>>>>>>>> From: Bob McMahon
>>>>>>>>> To: Dave Taht
>>>>>>>>> Cc: make-wifi-fast@lists.bufferbloat.net,
>>>>>>>>>     "cerowrt-devel@lists.bufferbloat.net"
>>>>>>>>>
>>>>>>>>> Subject: Re: [Make-wifi-fast] more well funded attempts showing
>> market
>>>>>>>>> demand
>>>>>>>>>     for better wifi
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> hmm, I'm skeptical.   To use multiple carriers simultaneously is
>>>>>>>>>
>>>>>>>> difficult
>>>>>>
>>>>>>> per RF issues.   Even if that is somehow resolved, to increase
>>>>>>>>>
>>>>>>>> throughput
>>>>>>
>>>>>>> usually requires some form of channel bonding, i.e. needed on both
>>>>>>>>>
>>>>>>>> sides,
>>>>>>
>>>>>>> and brings in issues with preserving frame ordering.  If this is just
>>>>>>>>> channel hopping, that needs coordination between both sides (and
>> isn't
>>>>>>>>> simultaneous, possibly costing more than any potential gain.)   An
>> AP
>>>>>>>>>
>>>>>>>> only
>>>>>>
>>>>>>> solution can use channel switch announcements (CSA) but there is a
>>>>>>>>>
>>>>>>>> cost to
>>>>>>
>>>>>>> those as well.
>>>>>>>>>
>>>>>>>>> I guess don't see any break though here and the marketing on the
>> site
>>>>>>>>> seems
>>>>>>>>> to indicate something beyond physics, at least the physics that I
>>>>>>>>> understand.  Always willing to learn and be corrected if I'm
>>>>>>>>> misunderstanding things.
>>>>>>>>>
>>>>>>>>> Bob
>>>>>>>>>
>>>>>>>>> On Wed, Jun 22, 2016 at 10:18 AM, Dave Taht
>>>>>>>>>
>>>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>>> On Wed, Jun 22, 2016 at 10:03 AM, Dave Taht
>>>>>>>>>
>>>>>>>> wrote:
>>>>>>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi?ref=backerkit
>>>>>>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> "Portal is the first and only router specifically engineered to
>> cut
>>>>>>>>>>> through and avoid congestion, delivering consistent,
>>>>>>>>>>> high-performance
>>>>>>>>>>> WiFi with greater coverage throughout your home.
>>>>>>>>>>>
>>>>>>>>>>> Its proprietary spectrum turbocharger technology provides access
>> to
>>>>>>>>>>> 300% more of the radio airwaves than any other router, improving
>>>>>>>>>>> performance by as much as 300x, and range and coverage by as
>> much as
>>>>>>>>>>> 2x in crowded settings, such as city homes and multi-unit
>>>>>>>>>>> apartments"
>>>>>>>>>>>
>>>>>>>>>>> It sounds like they are promising working DFS support.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> It's not clear what chipset they are using (they are claiming
>> wave2)
>>>>>>>>>> -
>>>>>>>>>> but they are at least publicly claiming to be using openwrt. So I
>>>>>>>>>> threw in enough to order one for september, just so I could
>> comment
>>>>>>>>>> on
>>>>>>>>>> their kickstarter page. :)
>>>>>>>>>>
>>>>>>>>>> I'd have loved to have got in earlier (early shipments are this
>> month
>>>>>>>>>> apparently), but those were sold out.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>
>> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi/comments
>>>>>>
>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>> Dave Täht
>>>>>>>>>>> Let's go make home routers and wifi faster! With better software!
>>>>>>>>>>> http://blog.cerowrt.org
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Dave Täht
>>>>>>>>>> Let's go make home routers and wifi faster! With better software!
>>>>>>>>>> http://blog.cerowrt.org
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Make-wifi-fast mailing list
>>>>>>>>>> Make-wifi-fast@lists.bufferbloat.net
>>>>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>> Make-wifi-fast mailing list
>>>>>>>> Make-wifi-fast@lists.bufferbloat.net
>>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>
>>
>>
>

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 20509 bytes --]

I appreciate and agree with what you posted, including that a wired network
without guides is not the same as a guide-less mobile network.  I do think
the thought experiment can help set some goal posts and, where the
goalposts don't make sense, some can be thrown out.  Also, there may be new
ones as well per mobility vs tertiary demands.

I ask myself a question, "What happened in 2000 that wi-fi became viable
such that atheros and others were able to form new companies?   Did a
mathematician discover some new math or did a physicist  find a better way
to explain energy as a means for moving information?"  Superposition
certainly applied 50+ years ago and I suspect most physicists understood it
equally well back then.

Hence, wi-fi isn't a triumph of math nor physics but rather an advancement
in engineering, aka the realization of those fields into products useful to
humans.  I suspect the future of wi-fi is more of the same - hence the
desire to set some engineering goal posts.

So to your points (and in the thought experiment context:)

1) Drastic variation in signal strength.  Reality of physics?  Seems yes.
Solvable by math?  I suspect so but could be wrong.  Solvable by
engineering now? Not sure.  In ten years?  Not sure.
2) Hidden transmitters.  Does it really matter?   Superposition applies
hidden or not so will fixing the "receiver confusion" get rid of this issue?
3) a) Variable rates: arguably a huge engineering design mistake for
multiple reasons (though understandably done this way.)
    b) Aggregation:  Artifact of media access latency that makes the
transport network incredibly difficult for things like TCP.  Possibly
another eng. design flaw.

Trying to learn from experts so thanks again for including me in these
discussions.

Bob

On Sun, Jun 26, 2016 at 5:00 PM, David Lang <david@lang.hm> wrote:

> I don't think anyone is trying to do simultanious receive of different
> stations. That is an incredibly difficult thing to do right.
>
> MU-MIMO is aimed at haivng the AP transmit to multiple stations at the
> same time. For the typical browser/streaming use, this traffic is FAR
> larger than the traffic from the stations to the AP. As such, it is worth
> focusing on optimizing this direction.
>
> While an ideal network may resemble a wired network without guides, I
> don't think it's a good idea to think about wifi networks that way.
>
> The reality is that no matter how good you get, a wireless network is
> going to have lots of things that are just not going to happen with wired
> networks.
>
> 1. drastic variations in signal strength.
>
>   On a wired network with a shared buss, the signal strength from all
> stations on the network is going to be very close to the same (a difference
> of 2x would be extreme)
>
>   On a wireless network, with 'normal' omnidirctional antennas, the signal
> drops off with the square of the distance. So if you want to service
> clients from 1 ft to 100 ft away, your signal strength varies by 1000 (4
> orders of magnatude), this is before you include effects of shielding,
> bounces, bad antenna alignment, etc (which can add several more orders of
> magnatude of variation)
>
>   The receiver first normalized the strongest part of the signal to a
> constant value, and then digitizes the result, (usually with a 12-14 bit AD
> converter). Since 1000x is ~10 bits, the result of overlapping tranmissions
> can be one signal at 14 bits, and another at <4 bits. This is why digital
> processing isn't able to receive multiple stations at the same time.
>
> 2. 'hidden transmitters'
>
>   On modern wired networks, every link has exactly two stations on it, and
> both can transmit at the same time.
>
>   On wireless networks, it's drastically different. You have an unknown
> number of stations (which can come and go without notice).
>
>   Not every station can hear every other station. This means that they
> can't avoid colliding with each other. In theory you can work around this
> by having some central system coordinate all the clients (either by them
> being told when to transmit, or by being given a schedule and having very
> precise clocks). But in practice the central system doesn't know when the
> clients have something to say and so in practice this doesn't work as well
> (except for special cases like voice where there is a constant amount of
> data to transmit)
>
> 3. variable transmit rates and aggregation
>
>   Depending on how strong the signal is between two stations, you have
> different limits to how fast you can transmit data. There are many
> different standard modulations that you can use, but if you use one that's
> too fast for the signal conditions, the receiver isn't going to be able to
> decode it. If you use one that's too slow, you increase the probability
> that another station will step on your signal, scrambling it as far as the
> receiver is concerned. We now have stations on the network that can vary in
> speed by 100x, and are nearing 1000x (1Mb/sec to 1Gb/sec)
>
>   Because there is so much variation in transmit rates, and older stations
> will not be able to understand the newest rates, each transmission starts
> off with some data being transmitted at the slowest available rate, telling
> any stations that are listening that there is data being transmitted for X
> amount of time, even if they can't tell what's going on as the data is
> being transmitted.
>
>   The combination of this header being transmitted inefficiently, and the
> fact that stations are waiting for a clear window to transmit, means that
> when you do get a chance to transmit, you should send more than one packet
> at a time. This is something Linux is currently not doing well, qdiscs tend
> to round-robin packets without regard to where they are headed. The current
> work being done here with the queues is improving both throughput and
> latency by fixing this problem.
>
>
> You really need to think differently when dealing with wireless network.
> The early wifi drivers tried to make them look just like a wired network,
> and we have found that we just needed too much other stuff to be successful
> whith that mindset.
>
> The Analog/Radio side of things really is important, and can't just be
> abstracted away.
>
> David Lang
>
>
> On Sun, 26 Jun 2016, Bob McMahon wrote:
>
> Is there a specific goal in mind?  This seems an AP tx centric proposal,
>> though I may not be fully understanding it.  I'm also curious as why not
>> scale in spatial domain vs the frequency domain, i.e. AP and STAs can also
>> scale using MiMO.  Why not just do that? So many phones today are 1x1,
>> some
>> 2x2 and few 3x3.   Yet APs are moving to 4x4 and I think the standard
>> supports 8x8.  (I'm not sure the marginal transistor count increase per
>> each approach.)  On the AP tx side, MuMIMO is also there which I think is
>> similar to the DAC proposal.
>>
>> I'm far from a PHY & DSP expert, but I think the simultaneous AP receive
>> is
>> the most difficult issue per the power variations, aka SNR.  Each of the
>> mobile device energies is affected per inverse square law (unless some
>> form
>> of wave guide is used.)  Hence wi-fi use of time domain slots prior to
>> transmit (no longer simultaneous in time.)  Particularly needed for
>> devices
>> that communicate with one another.  Unfortunately, "collocated"
>> energy/information sources must honor this TDM  even when not
>> communication
>> with one another per tragedy of the commons.  (Agreed there is no such
>> thing as a collision so let's redefine it to mean that the receiver is
>> unable to receive per RF energy "confusion", still a tragedy of the
>> commons.  I don't know what drives the limits to DSP decode that could
>> minimize or eliminate  this tragedy.)
>>
>> At the end of the day, would the ideal network would resemble a wired
>> ethernet (including ethernet switch fabric) without the waveguides (or
>> wires/fibers)?  From that perspective, here are some thoughts to the goals
>>
>> o)  TX op/access to transmit driven to zero.  (Collision avoidance isn't
>> nearly as good as instantaneous collision detect in this context, though
>> "collision" should replaced with "confusion")
>> o)  RX confusion detection time propagated to stop offending TX(s) driven
>> to zero
>> o)  Support of different encodings (e..g phy rates) pushes towards virtual
>> output queueing prior (queuing at the transmitter)
>> o)  Power per bit xfered towards zero or driven per cost & energy density
>> of batteries.  Note: Atomic batteries not allowed per humans being
>> involved.
>> o)  Transistor count (chip cost) per bit moved driven by Moore's law and
>> those economics
>> o)  Reduce "collision/confusion" domain (less STAs per AP) ideally to zero
>>
>> Just some thoughts off the top of my head.  Please do comment and correct.
>> Thanks in advance for the discussion.
>>
>> Bob
>>
>>
>>
>>
>> On Fri, Jun 24, 2016 at 2:24 PM, <dpreed@reed.com> wrote:
>>
>> Without custom silicon, doing what I was talking about would involve non
>>> standard MAC power management, which would require all devices to agree.
>>>
>>> David Lang's explanation was the essence of what I meant. the
>>> transmission
>>> from access point on multiple channels is just digital addition if the
>>> DACs
>>> have enough bits per sample. to make sure that the signals to the AP are
>>> equalized, just transmit at a power that makes that approximately true...
>>> which means a power amp with at most 30 dB of dynamic gain setting.
>>> typical
>>> dynamic path attenuation range (strongest to weakest ratio) among
>>> stations
>>> served by an AP is < 20 dB from my past experiments on well
>>> operating-installtions, but 25 can be seen in reflection heavy
>>> environments.-----Original Message-----
>>> From: "David Lang" <david@lang.hm>
>>> Sent: Fri, Jun 24, 2016 at 1:19 am
>>> To: "Bob McMahon" <bob.mcmahon@broadcom.com>
>>> Cc: "Bob McMahon" <bob.mcmahon@broadcom.com>,
>>> make-wifi-fast@lists.bufferbloat.net, "
>>> cerowrt-devel@lists.bufferbloat.net"
>>> <cerowrt-devel@lists.bufferbloat.net>
>>> Subject: Re: [Make-wifi-fast] more well funded attempts showing market
>>> demandfor better wifi
>>>
>>> well, with the kickstarter, I think they are selling a bill of goods.
>>>
>>> Just using the DFS channels and aggregating them as supported by N and AC
>>> standards would do wonders (as long as others near you don't do the same)
>>>
>>> David Lang
>>>
>>> On Thu, 23 Jun 2016, Bob McMahon wrote:
>>>
>>> Date: Thu, 23 Jun 2016 20:01:22 -0700
>>>> From: Bob McMahon
>>>> To: David Lang
>>>> Cc: dpreed@reed.com, make-wifi-fast@lists.bufferbloat.net,
>>>>     "cerowrt-devel@lists.bufferbloat.net"
>>>>
>>>> Subject: Re: [Make-wifi-fast] more well funded attempts showing market
>>>>
>>> demand
>>>
>>>>     for better wifi
>>>>
>>>> Thanks for the clarification.   Though now I'm confused about how all
>>>> the
>>>> channels would be used simultaneously with an AP only solution (which is
>>>>
>>> my
>>>
>>>> understanding of the kickstarter campaign.)
>>>>
>>>> Bob
>>>>
>>>> On Thu, Jun 23, 2016 at 7:14 PM, David Lang  wrote:
>>>>
>>>> I think he is meaning when one unit is talking to one AP the signal
>>>>>
>>>> levels
>>>
>>>> across multiple channels will be similar. Which is probably fairly true.
>>>>>
>>>>>
>>>>> David Lang
>>>>>
>>>>> On Thu, 23 Jun 2016, Bob McMahon wrote:
>>>>>
>>>>> Curious, where does the "in a LAN setup, the variability in [receive]
>>>>>
>>>>>> signal strength is likely small enough" assertion come?   Any specific
>>>>>> power numbers here? We test with many combinations of "signal strength
>>>>>> variability" (e.g. deltas range from 0 dBm -  50 dBm) and per
>>>>>> different
>>>>>> channel conditions.  This includes power variability within the
>>>>>> spatial
>>>>>> streams' MiMO transmission.   It would be helpful to have some physics
>>>>>> combined with engineering to produce some pragmatic limits to this.
>>>>>>
>>>>>> Also, mobile devices have a goal of reducing power in order to be
>>>>>> efficient
>>>>>> with their battery (vs a goal to balance power such that an AP can
>>>>>> receive simultaneously.)  Power per bit usually trumps most other
>>>>>>
>>>>> design
>>>
>>>> goals.  There market for battery powered wi-fi devices drives a
>>>>>> semi-conductor mfg's revenue so my information come with that bias.
>>>>>>
>>>>>> Bob
>>>>>>
>>>>>> On Thu, Jun 23, 2016 at 1:48 PM,  wrote:
>>>>>>
>>>>>> The actual issues of transmitting on multiple channels at the same
>>>>>> time
>>>>>>
>>>>>>> are quite minor if you do the work in the digital domain (pre-DAC).
>>>>>>>
>>>>>> You
>>>
>>>> just need a higher sampling rate in the DAC and add the two signals
>>>>>>> together (and use a wideband filter that covers all the channels).
>>>>>>>
>>>>>> No RF
>>>
>>>> problem.
>>>>>>>
>>>>>>> Receiving multiple transmissions in different channels is pretty much
>>>>>>>
>>>>>> the
>>>
>>>> same problem - just digitize (ADC) a wider bandwidth and separate in
>>>>>>>
>>>>>> the
>>>
>>>> digital domain.  the only real issue on receive is equalization - if
>>>>>>>
>>>>>> you
>>>
>>>> receive two different signals at different receive signal strengths,
>>>>>>>
>>>>>> the
>>>
>>>> lower strength signal won't get as much dynamic range in its samples.
>>>>>>>
>>>>>>> But in a LAN setup, the variability in signal strength is likely
>>>>>>> small
>>>>>>> enough that you can cover that with more ADC bits (or have the MAC
>>>>>>> protocol
>>>>>>> manage the station transmit power so that signals received at the AP
>>>>>>>
>>>>>> are
>>>
>>>> nearly the same power.
>>>>>>>
>>>>>>> Equalization at transmit works very well when there is a central AP
>>>>>>>
>>>>>> (as
>>>
>>>> in
>>>>>>> cellular or normal WiFi systems).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thursday, June 23, 2016 4:28pm, "Bob McMahon" >>>
>>>>>>>
>>>>>> bob.mcmahon@broadcom.com>
>>>
>>>> said:
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>>> Make-wifi-fast mailing list
>>>>>>>> Make-wifi-fast@lists.bufferbloat.net
>>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>>> An AP per room/area, reducing the tx power (beacon range) has been
>>>>>>>> my
>>>>>>>> approach and has scaled very well.   It does require some wires to
>>>>>>>>
>>>>>>> each
>>>
>>>>
>>>>>>>> AP
>>>>>>>
>>>>>>> but I find that paying an electrician to run some quality wiring to
>>>>>>>>
>>>>>>>> things
>>>>>>>
>>>>>>> that are to remain stationary has been well worth the cost.
>>>>>>>>
>>>>>>>> just my $0.02,
>>>>>>>> Bob
>>>>>>>>
>>>>>>>> On Thu, Jun 23, 2016 at 1:10 PM, David Lang  wrote:
>>>>>>>>
>>>>>>>> Well, just using the 5GHz DFS channels in 80MHz or 160 MHz wide
>>>>>>>>
>>>>>>> chunks
>>>
>>>> would be a huge improvement, not many people are using them (yet),
>>>>>>>>>
>>>>>>>> and
>>>
>>>>
>>>>>>>>> the
>>>>>>>>
>>>>>>>
>>>>>>> wide channels let you get a lot of data out at once. If everything is
>>>>>>>>
>>>>>>>>> within a good range of the AP, this would work pretty well. If you
>>>>>>>>>
>>>>>>>> end
>>>
>>>>
>>>>>>>>> up
>>>>>>>>
>>>>>>>
>>>>>>> needing multiple APs, or you have many stations, I expect that you
>>>>>>>>
>>>>>>> will
>>>
>>>>
>>>>>>>>> be
>>>>>>>>
>>>>>>>
>>>>>>> better off with more APs at lower power, each using different
>>>>>>>>
>>>>>>> channels.
>>>
>>>>
>>>>>>>>> David Lang
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, 23 Jun 2016, Bob McMahon wrote:
>>>>>>>>>
>>>>>>>>> Date: Thu, 23 Jun 2016 12:55:19 -0700
>>>>>>>>>
>>>>>>>>> From: Bob McMahon
>>>>>>>>>> To: Dave Taht
>>>>>>>>>> Cc: make-wifi-fast@lists.bufferbloat.net,
>>>>>>>>>>     "cerowrt-devel@lists.bufferbloat.net"
>>>>>>>>>>
>>>>>>>>>> Subject: Re: [Make-wifi-fast] more well funded attempts showing
>>>>>>>>>>
>>>>>>>>> market
>>>
>>>> demand
>>>>>>>>>>     for better wifi
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> hmm, I'm skeptical.   To use multiple carriers simultaneously is
>>>>>>>>>>
>>>>>>>>>> difficult
>>>>>>>>>
>>>>>>>>
>>>>>>> per RF issues.   Even if that is somehow resolved, to increase
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> throughput
>>>>>>>>>
>>>>>>>>
>>>>>>> usually requires some form of channel bonding, i.e. needed on both
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> sides,
>>>>>>>>>
>>>>>>>>
>>>>>>> and brings in issues with preserving frame ordering.  If this is just
>>>>>>>>
>>>>>>>>> channel hopping, that needs coordination between both sides (and
>>>>>>>>>>
>>>>>>>>> isn't
>>>
>>>> simultaneous, possibly costing more than any potential gain.)   An
>>>>>>>>>>
>>>>>>>>> AP
>>>
>>>>
>>>>>>>>>> only
>>>>>>>>>
>>>>>>>>
>>>>>>> solution can use channel switch announcements (CSA) but there is a
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> cost to
>>>>>>>>>
>>>>>>>>
>>>>>>> those as well.
>>>>>>>>
>>>>>>>>>
>>>>>>>>>> I guess don't see any break though here and the marketing on the
>>>>>>>>>>
>>>>>>>>> site
>>>
>>>> seems
>>>>>>>>>> to indicate something beyond physics, at least the physics that I
>>>>>>>>>> understand.  Always willing to learn and be corrected if I'm
>>>>>>>>>> misunderstanding things.
>>>>>>>>>>
>>>>>>>>>> Bob
>>>>>>>>>>
>>>>>>>>>> On Wed, Jun 22, 2016 at 10:18 AM, Dave Taht
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>> On Wed, Jun 22, 2016 at 10:03 AM, Dave Taht
>>>>>>>>>>
>>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi?ref=backerkit
>>>
>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>>> "Portal is the first and only router specifically engineered to
>>>>>>>>>>>>
>>>>>>>>>>> cut
>>>
>>>> through and avoid congestion, delivering consistent,
>>>>>>>>>>>> high-performance
>>>>>>>>>>>> WiFi with greater coverage throughout your home.
>>>>>>>>>>>>
>>>>>>>>>>>> Its proprietary spectrum turbocharger technology provides access
>>>>>>>>>>>>
>>>>>>>>>>> to
>>>
>>>> 300% more of the radio airwaves than any other router, improving
>>>>>>>>>>>> performance by as much as 300x, and range and coverage by as
>>>>>>>>>>>>
>>>>>>>>>>> much as
>>>
>>>> 2x in crowded settings, such as city homes and multi-unit
>>>>>>>>>>>> apartments"
>>>>>>>>>>>>
>>>>>>>>>>>> It sounds like they are promising working DFS support.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> It's not clear what chipset they are using (they are claiming
>>>>>>>>>>>
>>>>>>>>>> wave2)
>>>
>>>> -
>>>>>>>>>>> but they are at least publicly claiming to be using openwrt. So I
>>>>>>>>>>> threw in enough to order one for september, just so I could
>>>>>>>>>>>
>>>>>>>>>> comment
>>>
>>>> on
>>>>>>>>>>> their kickstarter page. :)
>>>>>>>>>>>
>>>>>>>>>>> I'd have loved to have got in earlier (early shipments are this
>>>>>>>>>>>
>>>>>>>>>> month
>>>
>>>> apparently), but those were sold out.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi/comments
>>>
>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>
>>>>>>>>>>>> Dave Täht
>>>>>>>>>>>> Let's go make home routers and wifi faster! With better
>>>>>>>>>>>> software!
>>>>>>>>>>>> http://blog.cerowrt.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Dave Täht
>>>>>>>>>>> Let's go make home routers and wifi faster! With better software!
>>>>>>>>>>> http://blog.cerowrt.org
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Make-wifi-fast mailing list
>>>>>>>>>>> Make-wifi-fast@lists.bufferbloat.net
>>>>>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>
>>>>>>>>>> Make-wifi-fast mailing list
>>>>>>>>> Make-wifi-fast@lists.bufferbloat.net
>>>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>
>>>

[-- Attachment #2: Type: text/html, Size: 46055 bytes --]

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 25512 bytes --]

hitting your points almost in reverse order

> 3) a) Variable rates: arguably a huge engineering design mistake for
> multiple reasons (though understandably done this way.)

We know how to send data faster now than we did 5 years ago, which was faster 
than we knew how to do 5 years before that, etc. We also will know how to send 
data faster 5 years from now.

Unless you plan to ignore all future improvements, you cannot stick with just a 
single data rate (and if you do, I'm sure that a competitor of yours who doesn't 
ignore future improvements will eat your lunch in a couple of years)

This completely ignores the fact that some modulation schemes require a better 
signal to noise ratio than others, so unless you want to either give up 
distance, or give up speed, you cannot pick the "one and true" rate to use.

This is why wifi defaults to slowing down when it has trouble getting through. 
if the problem is noise, this is the right thing to do, when the problem is 
hidden transmitters, it's exactly the wrong thing to do) At the time it was 
designed it was extremely expensive, so deployments were expected to be few, so 
the biggest problem expected was noise

>    b) Aggregation:  Artifact of media access latency that makes the
> transport network incredibly difficult for things like TCP.  Possibly
> another eng. design flaw.

it's not that simple. It's not the latency, it's the per-transmission overhead
that's the difference. This is the same reason why wired networks sometimes use
jumbo frames, the per-transmission overhead is the same, so by packing more data
into a single transmission, you get more efficient use of the media, so faster
effective speeds.

> 2) Hidden transmitters.  Does it really matter?   Superposition applies
> hidden or not so will fixing the "receiver confusion" get rid of this issue?

If transmitters aren't hidden from each other, they can wait until the airwaves
are quiet and then transmit. This works very well in practice. But eventually,
any successful network is going to grow until it exceeds the size at which all
stations can hear each other.

> 1) Drastic variation in signal strength.  Reality of physics?  Seems yes.
> Solvable by math?  I suspect so but could be wrong.  Solvable by
> engineering now? Not sure.  In ten years?  Not sure.

Improvements in 10 years, yes. solutions, no.

you are constrained by physics. you can only detect the signal that arrives at
your antennas. If you have two transmitters next to each other transmitting at
the same time, they are going to interfere with each other in ways that nothing
is going to be able to solve.

But similarly to the way that mu-mimo is able to use multiple antennas sending
different signals to create useful interference patterns so that multiple
stations that are 'far enough' apart can each receive a useable signal. Further
improvements in signal processing and Analog to Digital converters could make it
so that stations that are far enough apart in angle, but close enough in power
could be deciphered at the same time. I'd give good odds that data rates below
the signal station peak will be required to make this practical.

But the problem of being able to hear a whisper from across the room at the same
time that someone is yelling in your ear is such a problem that I don't believe
that it is ever going to be 'solved' as a general case. The noise and distortion 
of the strong signal can be larger than the weak signal. And the strength of a 
bounce of the strong signal can be larger than the weak signal.

getting to the point where several signals of similar strength could be handled 
at the same time would be a big help.

> I ask myself a question, "What happened in 2000 that wi-fi became viable
> such that atheros and others were able to form new companies?   Did a
> mathematician discover some new math or did a physicist  find a better way
> to explain energy as a means for moving information?"

Mo, what happened was Moore's law came to help. It took equipment that was 
selling at ~$1000/station and cut it's price to $100/station (and today better 
equipment is available at <$10/station).

I remember putting a $750 deposit down (the purchase price of the card) at a 
conference to borrow a 802.11b (1-11Mb/sec) pcmcia card for my laptop. At around 
the same time, I spent ~$500 to equip a small office with a proprietary AP and 
two 1Mb pcmcia cards (and considered it a bargin). Today you can buy USB 802.11n 
dongles for <$10 and for ~$100 you can get a 802.11ac device that (under the 
right conditions) can top 1Gb/sec.

The APs were several thousand dollars each. Today a $200-300 AP is near the high 
end of the consumer devices, and you can get them for ~50 if you push (or ~$25 
if you are willing to buy used)

It didn't take higher speeds (AC, N, or even G) to make wifi popular, it just 
required that the equipment come down enough in price.

David Lang


On Sun, 26 Jun 2016, Bob McMahon wrote:

> I appreciate and agree with what you posted, including that a wired network
> without guides is not the same as a guide-less mobile network.  I do think
> the thought experiment can help set some goal posts and, where the
> goalposts don't make sense, some can be thrown out.  Also, there may be new
> ones as well per mobility vs tertiary demands.
>
> I ask myself a question, "What happened in 2000 that wi-fi became viable
> such that atheros and others were able to form new companies?   Did a
> mathematician discover some new math or did a physicist  find a better way
> to explain energy as a means for moving information?"  Superposition
> certainly applied 50+ years ago and I suspect most physicists understood it
> equally well back then.
>
> Hence, wi-fi isn't a triumph of math nor physics but rather an advancement
> in engineering, aka the realization of those fields into products useful to
> humans.  I suspect the future of wi-fi is more of the same - hence the
> desire to set some engineering goal posts.
>
> So to your points (and in the thought experiment context:)
>
> 1) Drastic variation in signal strength.  Reality of physics?  Seems yes.
> Solvable by math?  I suspect so but could be wrong.  Solvable by
> engineering now? Not sure.  In ten years?  Not sure.
> 2) Hidden transmitters.  Does it really matter?   Superposition applies
> hidden or not so will fixing the "receiver confusion" get rid of this issue?
> 3) a) Variable rates: arguably a huge engineering design mistake for
> multiple reasons (though understandably done this way.)
>    b) Aggregation:  Artifact of media access latency that makes the
> transport network incredibly difficult for things like TCP.  Possibly
> another eng. design flaw.
>
> Trying to learn from experts so thanks again for including me in these
> discussions.
>
> Bob
>
> On Sun, Jun 26, 2016 at 5:00 PM, David Lang <david@lang.hm> wrote:
>
>> I don't think anyone is trying to do simultanious receive of different
>> stations. That is an incredibly difficult thing to do right.
>>
>> MU-MIMO is aimed at haivng the AP transmit to multiple stations at the
>> same time. For the typical browser/streaming use, this traffic is FAR
>> larger than the traffic from the stations to the AP. As such, it is worth
>> focusing on optimizing this direction.
>>
>> While an ideal network may resemble a wired network without guides, I
>> don't think it's a good idea to think about wifi networks that way.
>>
>> The reality is that no matter how good you get, a wireless network is
>> going to have lots of things that are just not going to happen with wired
>> networks.
>>
>> 1. drastic variations in signal strength.
>>
>>   On a wired network with a shared buss, the signal strength from all
>> stations on the network is going to be very close to the same (a difference
>> of 2x would be extreme)
>>
>>   On a wireless network, with 'normal' omnidirctional antennas, the signal
>> drops off with the square of the distance. So if you want to service
>> clients from 1 ft to 100 ft away, your signal strength varies by 1000 (4
>> orders of magnatude), this is before you include effects of shielding,
>> bounces, bad antenna alignment, etc (which can add several more orders of
>> magnatude of variation)
>>
>>   The receiver first normalized the strongest part of the signal to a
>> constant value, and then digitizes the result, (usually with a 12-14 bit AD
>> converter). Since 1000x is ~10 bits, the result of overlapping tranmissions
>> can be one signal at 14 bits, and another at <4 bits. This is why digital
>> processing isn't able to receive multiple stations at the same time.
>>
>> 2. 'hidden transmitters'
>>
>>   On modern wired networks, every link has exactly two stations on it, and
>> both can transmit at the same time.
>>
>>   On wireless networks, it's drastically different. You have an unknown
>> number of stations (which can come and go without notice).
>>
>>   Not every station can hear every other station. This means that they
>> can't avoid colliding with each other. In theory you can work around this
>> by having some central system coordinate all the clients (either by them
>> being told when to transmit, or by being given a schedule and having very
>> precise clocks). But in practice the central system doesn't know when the
>> clients have something to say and so in practice this doesn't work as well
>> (except for special cases like voice where there is a constant amount of
>> data to transmit)
>>
>> 3. variable transmit rates and aggregation
>>
>>   Depending on how strong the signal is between two stations, you have
>> different limits to how fast you can transmit data. There are many
>> different standard modulations that you can use, but if you use one that's
>> too fast for the signal conditions, the receiver isn't going to be able to
>> decode it. If you use one that's too slow, you increase the probability
>> that another station will step on your signal, scrambling it as far as the
>> receiver is concerned. We now have stations on the network that can vary in
>> speed by 100x, and are nearing 1000x (1Mb/sec to 1Gb/sec)
>>
>>   Because there is so much variation in transmit rates, and older stations
>> will not be able to understand the newest rates, each transmission starts
>> off with some data being transmitted at the slowest available rate, telling
>> any stations that are listening that there is data being transmitted for X
>> amount of time, even if they can't tell what's going on as the data is
>> being transmitted.
>>
>>   The combination of this header being transmitted inefficiently, and the
>> fact that stations are waiting for a clear window to transmit, means that
>> when you do get a chance to transmit, you should send more than one packet
>> at a time. This is something Linux is currently not doing well, qdiscs tend
>> to round-robin packets without regard to where they are headed. The current
>> work being done here with the queues is improving both throughput and
>> latency by fixing this problem.
>>
>>
>> You really need to think differently when dealing with wireless network.
>> The early wifi drivers tried to make them look just like a wired network,
>> and we have found that we just needed too much other stuff to be successful
>> whith that mindset.
>>
>> The Analog/Radio side of things really is important, and can't just be
>> abstracted away.
>>
>> David Lang
>>
>>
>> On Sun, 26 Jun 2016, Bob McMahon wrote:
>>
>> Is there a specific goal in mind?  This seems an AP tx centric proposal,
>>> though I may not be fully understanding it.  I'm also curious as why not
>>> scale in spatial domain vs the frequency domain, i.e. AP and STAs can also
>>> scale using MiMO.  Why not just do that? So many phones today are 1x1,
>>> some
>>> 2x2 and few 3x3.   Yet APs are moving to 4x4 and I think the standard
>>> supports 8x8.  (I'm not sure the marginal transistor count increase per
>>> each approach.)  On the AP tx side, MuMIMO is also there which I think is
>>> similar to the DAC proposal.
>>>
>>> I'm far from a PHY & DSP expert, but I think the simultaneous AP receive
>>> is
>>> the most difficult issue per the power variations, aka SNR.  Each of the
>>> mobile device energies is affected per inverse square law (unless some
>>> form
>>> of wave guide is used.)  Hence wi-fi use of time domain slots prior to
>>> transmit (no longer simultaneous in time.)  Particularly needed for
>>> devices
>>> that communicate with one another.  Unfortunately, "collocated"
>>> energy/information sources must honor this TDM  even when not
>>> communication
>>> with one another per tragedy of the commons.  (Agreed there is no such
>>> thing as a collision so let's redefine it to mean that the receiver is
>>> unable to receive per RF energy "confusion", still a tragedy of the
>>> commons.  I don't know what drives the limits to DSP decode that could
>>> minimize or eliminate  this tragedy.)
>>>
>>> At the end of the day, would the ideal network would resemble a wired
>>> ethernet (including ethernet switch fabric) without the waveguides (or
>>> wires/fibers)?  From that perspective, here are some thoughts to the goals
>>>
>>> o)  TX op/access to transmit driven to zero.  (Collision avoidance isn't
>>> nearly as good as instantaneous collision detect in this context, though
>>> "collision" should replaced with "confusion")
>>> o)  RX confusion detection time propagated to stop offending TX(s) driven
>>> to zero
>>> o)  Support of different encodings (e..g phy rates) pushes towards virtual
>>> output queueing prior (queuing at the transmitter)
>>> o)  Power per bit xfered towards zero or driven per cost & energy density
>>> of batteries.  Note: Atomic batteries not allowed per humans being
>>> involved.
>>> o)  Transistor count (chip cost) per bit moved driven by Moore's law and
>>> those economics
>>> o)  Reduce "collision/confusion" domain (less STAs per AP) ideally to zero
>>>
>>> Just some thoughts off the top of my head.  Please do comment and correct.
>>> Thanks in advance for the discussion.
>>>
>>> Bob
>>>
>>>
>>>
>>>
>>> On Fri, Jun 24, 2016 at 2:24 PM, <dpreed@reed.com> wrote:
>>>
>>> Without custom silicon, doing what I was talking about would involve non
>>>> standard MAC power management, which would require all devices to agree.
>>>>
>>>> David Lang's explanation was the essence of what I meant. the
>>>> transmission
>>>> from access point on multiple channels is just digital addition if the
>>>> DACs
>>>> have enough bits per sample. to make sure that the signals to the AP are
>>>> equalized, just transmit at a power that makes that approximately true...
>>>> which means a power amp with at most 30 dB of dynamic gain setting.
>>>> typical
>>>> dynamic path attenuation range (strongest to weakest ratio) among
>>>> stations
>>>> served by an AP is < 20 dB from my past experiments on well
>>>> operating-installtions, but 25 can be seen in reflection heavy
>>>> environments.-----Original Message-----
>>>> From: "David Lang" <david@lang.hm>
>>>> Sent: Fri, Jun 24, 2016 at 1:19 am
>>>> To: "Bob McMahon" <bob.mcmahon@broadcom.com>
>>>> Cc: "Bob McMahon" <bob.mcmahon@broadcom.com>,
>>>> make-wifi-fast@lists.bufferbloat.net, "
>>>> cerowrt-devel@lists.bufferbloat.net"
>>>> <cerowrt-devel@lists.bufferbloat.net>
>>>> Subject: Re: [Make-wifi-fast] more well funded attempts showing market
>>>> demandfor better wifi
>>>>
>>>> well, with the kickstarter, I think they are selling a bill of goods.
>>>>
>>>> Just using the DFS channels and aggregating them as supported by N and AC
>>>> standards would do wonders (as long as others near you don't do the same)
>>>>
>>>> David Lang
>>>>
>>>> On Thu, 23 Jun 2016, Bob McMahon wrote:
>>>>
>>>> Date: Thu, 23 Jun 2016 20:01:22 -0700
>>>>> From: Bob McMahon
>>>>> To: David Lang
>>>>> Cc: dpreed@reed.com, make-wifi-fast@lists.bufferbloat.net,
>>>>>     "cerowrt-devel@lists.bufferbloat.net"
>>>>>
>>>>> Subject: Re: [Make-wifi-fast] more well funded attempts showing market
>>>>>
>>>> demand
>>>>
>>>>>     for better wifi
>>>>>
>>>>> Thanks for the clarification.   Though now I'm confused about how all
>>>>> the
>>>>> channels would be used simultaneously with an AP only solution (which is
>>>>>
>>>> my
>>>>
>>>>> understanding of the kickstarter campaign.)
>>>>>
>>>>> Bob
>>>>>
>>>>> On Thu, Jun 23, 2016 at 7:14 PM, David Lang  wrote:
>>>>>
>>>>> I think he is meaning when one unit is talking to one AP the signal
>>>>>>
>>>>> levels
>>>>
>>>>> across multiple channels will be similar. Which is probably fairly true.
>>>>>>
>>>>>>
>>>>>> David Lang
>>>>>>
>>>>>> On Thu, 23 Jun 2016, Bob McMahon wrote:
>>>>>>
>>>>>> Curious, where does the "in a LAN setup, the variability in [receive]
>>>>>>
>>>>>>> signal strength is likely small enough" assertion come?   Any specific
>>>>>>> power numbers here? We test with many combinations of "signal strength
>>>>>>> variability" (e.g. deltas range from 0 dBm -  50 dBm) and per
>>>>>>> different
>>>>>>> channel conditions.  This includes power variability within the
>>>>>>> spatial
>>>>>>> streams' MiMO transmission.   It would be helpful to have some physics
>>>>>>> combined with engineering to produce some pragmatic limits to this.
>>>>>>>
>>>>>>> Also, mobile devices have a goal of reducing power in order to be
>>>>>>> efficient
>>>>>>> with their battery (vs a goal to balance power such that an AP can
>>>>>>> receive simultaneously.)  Power per bit usually trumps most other
>>>>>>>
>>>>>> design
>>>>
>>>>> goals.  There market for battery powered wi-fi devices drives a
>>>>>>> semi-conductor mfg's revenue so my information come with that bias.
>>>>>>>
>>>>>>> Bob
>>>>>>>
>>>>>>> On Thu, Jun 23, 2016 at 1:48 PM,  wrote:
>>>>>>>
>>>>>>> The actual issues of transmitting on multiple channels at the same
>>>>>>> time
>>>>>>>
>>>>>>>> are quite minor if you do the work in the digital domain (pre-DAC).
>>>>>>>>
>>>>>>> You
>>>>
>>>>> just need a higher sampling rate in the DAC and add the two signals
>>>>>>>> together (and use a wideband filter that covers all the channels).
>>>>>>>>
>>>>>>> No RF
>>>>
>>>>> problem.
>>>>>>>>
>>>>>>>> Receiving multiple transmissions in different channels is pretty much
>>>>>>>>
>>>>>>> the
>>>>
>>>>> same problem - just digitize (ADC) a wider bandwidth and separate in
>>>>>>>>
>>>>>>> the
>>>>
>>>>> digital domain.  the only real issue on receive is equalization - if
>>>>>>>>
>>>>>>> you
>>>>
>>>>> receive two different signals at different receive signal strengths,
>>>>>>>>
>>>>>>> the
>>>>
>>>>> lower strength signal won't get as much dynamic range in its samples.
>>>>>>>>
>>>>>>>> But in a LAN setup, the variability in signal strength is likely
>>>>>>>> small
>>>>>>>> enough that you can cover that with more ADC bits (or have the MAC
>>>>>>>> protocol
>>>>>>>> manage the station transmit power so that signals received at the AP
>>>>>>>>
>>>>>>> are
>>>>
>>>>> nearly the same power.
>>>>>>>>
>>>>>>>> Equalization at transmit works very well when there is a central AP
>>>>>>>>
>>>>>>> (as
>>>>
>>>>> in
>>>>>>>> cellular or normal WiFi systems).
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thursday, June 23, 2016 4:28pm, "Bob McMahon" >>>
>>>>>>>>
>>>>>>> bob.mcmahon@broadcom.com>
>>>>
>>>>> said:
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>>
>>>>>>>>> Make-wifi-fast mailing list
>>>>>>>>> Make-wifi-fast@lists.bufferbloat.net
>>>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>>>> An AP per room/area, reducing the tx power (beacon range) has been
>>>>>>>>> my
>>>>>>>>> approach and has scaled very well.   It does require some wires to
>>>>>>>>>
>>>>>>>> each
>>>>
>>>>>
>>>>>>>>> AP
>>>>>>>>
>>>>>>>> but I find that paying an electrician to run some quality wiring to
>>>>>>>>>
>>>>>>>>> things
>>>>>>>>
>>>>>>>> that are to remain stationary has been well worth the cost.
>>>>>>>>>
>>>>>>>>> just my $0.02,
>>>>>>>>> Bob
>>>>>>>>>
>>>>>>>>> On Thu, Jun 23, 2016 at 1:10 PM, David Lang  wrote:
>>>>>>>>>
>>>>>>>>> Well, just using the 5GHz DFS channels in 80MHz or 160 MHz wide
>>>>>>>>>
>>>>>>>> chunks
>>>>
>>>>> would be a huge improvement, not many people are using them (yet),
>>>>>>>>>>
>>>>>>>>> and
>>>>
>>>>>
>>>>>>>>>> the
>>>>>>>>>
>>>>>>>>
>>>>>>>> wide channels let you get a lot of data out at once. If everything is
>>>>>>>>>
>>>>>>>>>> within a good range of the AP, this would work pretty well. If you
>>>>>>>>>>
>>>>>>>>> end
>>>>
>>>>>
>>>>>>>>>> up
>>>>>>>>>
>>>>>>>>
>>>>>>>> needing multiple APs, or you have many stations, I expect that you
>>>>>>>>>
>>>>>>>> will
>>>>
>>>>>
>>>>>>>>>> be
>>>>>>>>>
>>>>>>>>
>>>>>>>> better off with more APs at lower power, each using different
>>>>>>>>>
>>>>>>>> channels.
>>>>
>>>>>
>>>>>>>>>> David Lang
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, 23 Jun 2016, Bob McMahon wrote:
>>>>>>>>>>
>>>>>>>>>> Date: Thu, 23 Jun 2016 12:55:19 -0700
>>>>>>>>>>
>>>>>>>>>> From: Bob McMahon
>>>>>>>>>>> To: Dave Taht
>>>>>>>>>>> Cc: make-wifi-fast@lists.bufferbloat.net,
>>>>>>>>>>>     "cerowrt-devel@lists.bufferbloat.net"
>>>>>>>>>>>
>>>>>>>>>>> Subject: Re: [Make-wifi-fast] more well funded attempts showing
>>>>>>>>>>>
>>>>>>>>>> market
>>>>
>>>>> demand
>>>>>>>>>>>     for better wifi
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> hmm, I'm skeptical.   To use multiple carriers simultaneously is
>>>>>>>>>>>
>>>>>>>>>>> difficult
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> per RF issues.   Even if that is somehow resolved, to increase
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> throughput
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> usually requires some form of channel bonding, i.e. needed on both
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> sides,
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> and brings in issues with preserving frame ordering.  If this is just
>>>>>>>>>
>>>>>>>>>> channel hopping, that needs coordination between both sides (and
>>>>>>>>>>>
>>>>>>>>>> isn't
>>>>
>>>>> simultaneous, possibly costing more than any potential gain.)   An
>>>>>>>>>>>
>>>>>>>>>> AP
>>>>
>>>>>
>>>>>>>>>>> only
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> solution can use channel switch announcements (CSA) but there is a
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> cost to
>>>>>>>>>>
>>>>>>>>>
>>>>>>>> those as well.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> I guess don't see any break though here and the marketing on the
>>>>>>>>>>>
>>>>>>>>>> site
>>>>
>>>>> seems
>>>>>>>>>>> to indicate something beyond physics, at least the physics that I
>>>>>>>>>>> understand.  Always willing to learn and be corrected if I'm
>>>>>>>>>>> misunderstanding things.
>>>>>>>>>>>
>>>>>>>>>>> Bob
>>>>>>>>>>>
>>>>>>>>>>> On Wed, Jun 22, 2016 at 10:18 AM, Dave Taht
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>> On Wed, Jun 22, 2016 at 10:03 AM, Dave Taht
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi?ref=backerkit
>>>>
>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>> "Portal is the first and only router specifically engineered to
>>>>>>>>>>>>>
>>>>>>>>>>>> cut
>>>>
>>>>> through and avoid congestion, delivering consistent,
>>>>>>>>>>>>> high-performance
>>>>>>>>>>>>> WiFi with greater coverage throughout your home.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Its proprietary spectrum turbocharger technology provides access
>>>>>>>>>>>>>
>>>>>>>>>>>> to
>>>>
>>>>> 300% more of the radio airwaves than any other router, improving
>>>>>>>>>>>>> performance by as much as 300x, and range and coverage by as
>>>>>>>>>>>>>
>>>>>>>>>>>> much as
>>>>
>>>>> 2x in crowded settings, such as city homes and multi-unit
>>>>>>>>>>>>> apartments"
>>>>>>>>>>>>>
>>>>>>>>>>>>> It sounds like they are promising working DFS support.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> It's not clear what chipset they are using (they are claiming
>>>>>>>>>>>>
>>>>>>>>>>> wave2)
>>>>
>>>>> -
>>>>>>>>>>>> but they are at least publicly claiming to be using openwrt. So I
>>>>>>>>>>>> threw in enough to order one for september, just so I could
>>>>>>>>>>>>
>>>>>>>>>>> comment
>>>>
>>>>> on
>>>>>>>>>>>> their kickstarter page. :)
>>>>>>>>>>>>
>>>>>>>>>>>> I'd have loved to have got in earlier (early shipments are this
>>>>>>>>>>>>
>>>>>>>>>>> month
>>>>
>>>>> apparently), but those were sold out.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>
>>>> https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi/comments
>>>>
>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>>
>>>>>>>>>>>>> Dave Täht
>>>>>>>>>>>>> Let's go make home routers and wifi faster! With better
>>>>>>>>>>>>> software!
>>>>>>>>>>>>> http://blog.cerowrt.org
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Dave Täht
>>>>>>>>>>>> Let's go make home routers and wifi faster! With better software!
>>>>>>>>>>>> http://blog.cerowrt.org
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> Make-wifi-fast mailing list
>>>>>>>>>>>> Make-wifi-fast@lists.bufferbloat.net
>>>>>>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>
>>>>>>>>>>> Make-wifi-fast mailing list
>>>>>>>>>> Make-wifi-fast@lists.bufferbloat.net
>>>>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>
>>>>
>

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Dave Taht]

In terms of wifi history... since I go back to the 70s...

was that we did not know how to do it - 73 we had aloha, which begat
ethernet... and for years progress was slow. Even as late as 91 or so
a "good" microwave link cost something like 40k an end, and required
special cooling and permits on so on. Wifi was started as an ipx/spx
bridge tech that didn't start to get anywhere until the mid 90s.

It was far from obvious at any point that the cost reductions would
take place that did, there was so much work in the analog domain that
looked (at the time) resistant to moores law. As for spectrum, finding
ways to leverage 2.4ghz cost metricom's backers in particular more
money than I care to think about, and I'm always pointing at how the
discovery that a more centralized clock and a retransmit at the mac
layer is what eventually made 802.11b viable. Many other wireless
ideas have been tried and died - wimax, for example, UWB, for another.
Bluetooth has evolved into adding "discovery prototol", which was kind
of unexpected... (there is even 6lopan over bluetooth now). The 5ghz
spectrum users have tended to adopt their own mac, as has some other
less popular bands.

While I'm pretty happy that we've got much of the queuing theory for
fixing 802.11n and 802.1ac nailed now, outstanding problems include
the hidden station problem, the rise in the background noise levels,
insufficient channels, and increasingly proprietary standards and
chipsets, as well as transport, switching and routing protocols
layered on top originally designed for isochronus transports.

I like to think (or possibly delude myself), that the solutions to
airtime fairness scheduling now emerging may one day lead to saner
scheduling around the hidden station problem in particular. Otherwise,
and elsewhere, there remain a lot of rocks to bang together, and a
long list of other issues we've captured elsewhere.

I am still periodically reviewing and updating this as we go along, as
it remains the best central document we have on all that's wrong in
wifi with some hints as to how to go about fixing them.

https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 3092 bytes --]

Hi All,

This is a very interesting thread - thanks to all for taking the time to
respond.   (Personally, I now have better understanding of the difficulties
associated with a PHY subsystem that supports a wide 1GHz.)

Not to derail the current discussion, but I am curious to ideas on
addressing the overhead associated with media access per collision
avoidance.  This overhead seems to be limiting transmits to about 10K per
second (even when a link has no competition for access.)   Is there a way,
maybe using another dedicated radio, to achieve near instantaneous
collision detect (where the CD is driven by the receiver state) such that
mobile devices can sample RF energy to get theses states and state changes
much more quickly?

Thanks,
Bob





On Mon, Jun 27, 2016 at 10:55 AM, Dave Taht <dave.taht@gmail.com> wrote:

> In terms of wifi history... since I go back to the 70s...
>
> was that we did not know how to do it - 73 we had aloha, which begat
> ethernet... and for years progress was slow. Even as late as 91 or so
> a "good" microwave link cost something like 40k an end, and required
> special cooling and permits on so on. Wifi was started as an ipx/spx
> bridge tech that didn't start to get anywhere until the mid 90s.
>
> It was far from obvious at any point that the cost reductions would
> take place that did, there was so much work in the analog domain that
> looked (at the time) resistant to moores law. As for spectrum, finding
> ways to leverage 2.4ghz cost metricom's backers in particular more
> money than I care to think about, and I'm always pointing at how the
> discovery that a more centralized clock and a retransmit at the mac
> layer is what eventually made 802.11b viable. Many other wireless
> ideas have been tried and died - wimax, for example, UWB, for another.
> Bluetooth has evolved into adding "discovery prototol", which was kind
> of unexpected... (there is even 6lopan over bluetooth now). The 5ghz
> spectrum users have tended to adopt their own mac, as has some other
> less popular bands.
>
> While I'm pretty happy that we've got much of the queuing theory for
> fixing 802.11n and 802.1ac nailed now, outstanding problems include
> the hidden station problem, the rise in the background noise levels,
> insufficient channels, and increasingly proprietary standards and
> chipsets, as well as transport, switching and routing protocols
> layered on top originally designed for isochronus transports.
>
> I like to think (or possibly delude myself), that the solutions to
> airtime fairness scheduling now emerging may one day lead to saner
> scheduling around the hidden station problem in particular. Otherwise,
> and elsewhere, there remain a lot of rocks to bang together, and a
> long list of other issues we've captured elsewhere.
>
> I am still periodically reviewing and updating this as we go along, as
> it remains the best central document we have on all that's wrong in
> wifi with some hints as to how to go about fixing them.
>
>
> https://docs.google.com/document/d/1Se36svYE1Uzpppe1HWnEyat_sAGghB3kE285LElJBW4/edit
>

[-- Attachment #2: Type: text/html, Size: 3811 bytes --]

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[David Lang]

On Mon, 27 Jun 2016, Bob McMahon wrote:

> Hi All,
>
> This is a very interesting thread - thanks to all for taking the time to
> respond.   (Personally, I now have better understanding of the difficulties
> associated with a PHY subsystem that supports a wide 1GHz.)
>
> Not to derail the current discussion, but I am curious to ideas on
> addressing the overhead associated with media access per collision
> avoidance.  This overhead seems to be limiting transmits to about 10K per
> second (even when a link has no competition for access.)

I'm not sure where you're getting 10K/second from. We do need to limit the 
amount of data transmitted in one session to give other stations a chance to 
talk, but if the AP replies immediatly to ack the traffic, and the airwaves are 
idle, you can transmit again pretty quickly.

people using -ac equipment with a single station are getting 900Mb/sec today.

>   Is there a way,
> maybe using another dedicated radio, to achieve near instantaneous
> collision detect (where the CD is driven by the receiver state) such that
> mobile devices can sample RF energy to get theses states and state changes
> much more quickly?

This gets back to the same problems (hidden transmitter , and the simultanious 
reception of wildly different signal strengths)

When you are sending, you will hear yourself as a VERY strong signal, trying to 
hear if someone else is transmitting at the same time is almost impossible (100 
ft to 1 ft is 4 orders of magnatude, 1 ft to 1 inch is another 2 orders of 
magnatude)

And it's very possible that the station that you are colliding with isn't one 
you can hear at all.

Any AP is going to have a better antenna than any phone. (sometimes several 
orders of magnatude better), so even if you were located at the same place as 
the AP, the AP is going to hear signals that you don't.

Then consider the case where you and the other station are on opposite sides of 
the AP at max range.

and then add cases where there is a wall between you and the other station, but 
the AP can hear both of you.

David Lang

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 3007 bytes --]

The ~10K is coming from empirical measurements where all aggregation
technologies are disabled, i.e. only one small IP packet per medium
arbitration/access and where there is only one transmitter and one
receiver.  900Mb/sec is typically a peak-average throughput measurement
where max (or near max) aggregation occurs, amortizing the access overhead
across multiple packets.

Yes, devices can be hidden from each other but not from the AP (hence the
use of RTS/CTS per hidden node mitigation.) Isn't it the AP's view of the
"carrier state" that matters (at least in infrastructure mode?)  If that's
the case, what about a different band (and different radio) such that the
strong signal carrying the data could be separated from the the BSSID's
"carrier/energy state" signal?

Bob

On Mon, Jun 27, 2016 at 12:40 PM, David Lang <david@lang.hm> wrote:

> On Mon, 27 Jun 2016, Bob McMahon wrote:
>
> Hi All,
>>
>> This is a very interesting thread - thanks to all for taking the time to
>> respond.   (Personally, I now have better understanding of the
>> difficulties
>> associated with a PHY subsystem that supports a wide 1GHz.)
>>
>> Not to derail the current discussion, but I am curious to ideas on
>> addressing the overhead associated with media access per collision
>> avoidance.  This overhead seems to be limiting transmits to about 10K per
>> second (even when a link has no competition for access.)
>>
>
> I'm not sure where you're getting 10K/second from. We do need to limit the
> amount of data transmitted in one session to give other stations a chance
> to talk, but if the AP replies immediatly to ack the traffic, and the
> airwaves are idle, you can transmit again pretty quickly.
>
> people using -ac equipment with a single station are getting 900Mb/sec
> today.
>
>   Is there a way,
>> maybe using another dedicated radio, to achieve near instantaneous
>> collision detect (where the CD is driven by the receiver state) such that
>> mobile devices can sample RF energy to get theses states and state changes
>> much more quickly?
>>
>
> This gets back to the same problems (hidden transmitter , and the
> simultanious reception of wildly different signal strengths)
>
> When you are sending, you will hear yourself as a VERY strong signal,
> trying to hear if someone else is transmitting at the same time is almost
> impossible (100 ft to 1 ft is 4 orders of magnatude, 1 ft to 1 inch is
> another 2 orders of magnatude)
>
> And it's very possible that the station that you are colliding with isn't
> one you can hear at all.
>
> Any AP is going to have a better antenna than any phone. (sometimes
> several orders of magnatude better), so even if you were located at the
> same place as the AP, the AP is going to hear signals that you don't.
>
> Then consider the case where you and the other station are on opposite
> sides of the AP at max range.
>
> and then add cases where there is a wall between you and the other
> station, but the AP can hear both of you.
>
> David Lang
>

[-- Attachment #2: Type: text/html, Size: 3821 bytes --]

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[David Lang]

On Mon, 27 Jun 2016, Bob McMahon wrote:

> The ~10K is coming from empirical measurements where all aggregation
> technologies are disabled, i.e. only one small IP packet per medium
> arbitration/access and where there is only one transmitter and one
> receiver.  900Mb/sec is typically a peak-average throughput measurement
> where max (or near max) aggregation occurs, amortizing the access overhead
> across multiple packets.

so 10K is minimum size packets being transmitted?or around 200 transmissions/sec 
(plus 200 ack transmissions/sec)?

> Yes, devices can be hidden from each other but not from the AP (hence the
> use of RTS/CTS per hidden node mitigation.) Isn't it the AP's view of the
> "carrier state" that matters (at least in infrastructure mode?)  If that's
> the case, what about a different band (and different radio) such that the
> strong signal carrying the data could be separated from the the BSSID's
> "carrier/energy state" signal?

how do you solve the interference problem on this other band/radio? When you 
have other APs in the area operating, you will have the same problem there.

David Lang

> Bob
>
> On Mon, Jun 27, 2016 at 12:40 PM, David Lang <david@lang.hm> wrote:
>
>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>
>> Hi All,
>>>
>>> This is a very interesting thread - thanks to all for taking the time to
>>> respond.   (Personally, I now have better understanding of the
>>> difficulties
>>> associated with a PHY subsystem that supports a wide 1GHz.)
>>>
>>> Not to derail the current discussion, but I am curious to ideas on
>>> addressing the overhead associated with media access per collision
>>> avoidance.  This overhead seems to be limiting transmits to about 10K per
>>> second (even when a link has no competition for access.)
>>>
>>
>> I'm not sure where you're getting 10K/second from. We do need to limit the
>> amount of data transmitted in one session to give other stations a chance
>> to talk, but if the AP replies immediatly to ack the traffic, and the
>> airwaves are idle, you can transmit again pretty quickly.
>>
>> people using -ac equipment with a single station are getting 900Mb/sec
>> today.
>>
>>   Is there a way,
>>> maybe using another dedicated radio, to achieve near instantaneous
>>> collision detect (where the CD is driven by the receiver state) such that
>>> mobile devices can sample RF energy to get theses states and state changes
>>> much more quickly?
>>>
>>
>> This gets back to the same problems (hidden transmitter , and the
>> simultanious reception of wildly different signal strengths)
>>
>> When you are sending, you will hear yourself as a VERY strong signal,
>> trying to hear if someone else is transmitting at the same time is almost
>> impossible (100 ft to 1 ft is 4 orders of magnatude, 1 ft to 1 inch is
>> another 2 orders of magnatude)
>>
>> And it's very possible that the station that you are colliding with isn't
>> one you can hear at all.
>>
>> Any AP is going to have a better antenna than any phone. (sometimes
>> several orders of magnatude better), so even if you were located at the
>> same place as the AP, the AP is going to hear signals that you don't.
>>
>> Then consider the case where you and the other station are on opposite
>> sides of the AP at max range.
>>
>> and then add cases where there is a wall between you and the other
>> station, but the AP can hear both of you.
>>
>> David Lang
>>
>

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 4986 bytes --]

packet size is smallest udp payload per a socket write() which in turn
drives the smallest packet supported by "the wire."

Here is a back of the envelope calculation giving ~100 microseconds per BE
access.

# Overhead estimates (slot time is 9 us):
# o DIFS 50 us or *AIFS (3 * 9 us) = 27 us
# o *Backoff Slot * CWmin,  9 us * rand[0,xf] (avg) = 7 * 9=63 us
# o 5G 20 us
# o Multimode header 20 us
# o PLCP (symbols) 2 * 4 us = 8 us
# o *SIFS 16 us
# o ACK 40 us
#
# Even if there is no collision and the CW stays at the aCWmin, the average
# backoff time incurred by CSMA/CA is aDIFS + aCWmin/2 * aSlotTime = 16 µs
# +(2+7.5)*9 µs = 101.5 µs for OFDM PHY, while the data rate with OFDM PHY
# can reach 600 Mbps in 802.11n, leading to a transmission time of 20 µs
# for a 1500 byte packet.

All devices in a BSSID would have to agree that the second radio is to be
used for BSSID "carrier state" information and all energy will be sourced
by the AP serving that BSSID.  (A guess is doing this wouldn't improve the
100 us by enough to justify the cost and that a new MAC protocol is
required.  Just curious to what such a protocol and phy subsystem would
look like assuming collision avoidance could be replaced with collision
detect.)

Bob



On Mon, Jun 27, 2016 at 1:09 PM, David Lang <david@lang.hm> wrote:

> On Mon, 27 Jun 2016, Bob McMahon wrote:
>
> The ~10K is coming from empirical measurements where all aggregation
>> technologies are disabled, i.e. only one small IP packet per medium
>> arbitration/access and where there is only one transmitter and one
>> receiver.  900Mb/sec is typically a peak-average throughput measurement
>> where max (or near max) aggregation occurs, amortizing the access overhead
>> across multiple packets.
>>
>
> so 10K is minimum size packets being transmitted?or around 200
> transmissions/sec (plus 200 ack transmissions/sec)?
>
> Yes, devices can be hidden from each other but not from the AP (hence the
>> use of RTS/CTS per hidden node mitigation.) Isn't it the AP's view of the
>> "carrier state" that matters (at least in infrastructure mode?)  If that's
>> the case, what about a different band (and different radio) such that the
>> strong signal carrying the data could be separated from the the BSSID's
>> "carrier/energy state" signal?
>>
>
> how do you solve the interference problem on this other band/radio? When
> you have other APs in the area operating, you will have the same problem
> there.
>
> David Lang
>
>
> Bob
>>
>> On Mon, Jun 27, 2016 at 12:40 PM, David Lang <david@lang.hm> wrote:
>>
>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>>
>>> Hi All,
>>>
>>>>
>>>> This is a very interesting thread - thanks to all for taking the time to
>>>> respond.   (Personally, I now have better understanding of the
>>>> difficulties
>>>> associated with a PHY subsystem that supports a wide 1GHz.)
>>>>
>>>> Not to derail the current discussion, but I am curious to ideas on
>>>> addressing the overhead associated with media access per collision
>>>> avoidance.  This overhead seems to be limiting transmits to about 10K
>>>> per
>>>> second (even when a link has no competition for access.)
>>>>
>>>>
>>> I'm not sure where you're getting 10K/second from. We do need to limit
>>> the
>>> amount of data transmitted in one session to give other stations a chance
>>> to talk, but if the AP replies immediatly to ack the traffic, and the
>>> airwaves are idle, you can transmit again pretty quickly.
>>>
>>> people using -ac equipment with a single station are getting 900Mb/sec
>>> today.
>>>
>>>   Is there a way,
>>>
>>>> maybe using another dedicated radio, to achieve near instantaneous
>>>> collision detect (where the CD is driven by the receiver state) such
>>>> that
>>>> mobile devices can sample RF energy to get theses states and state
>>>> changes
>>>> much more quickly?
>>>>
>>>>
>>> This gets back to the same problems (hidden transmitter , and the
>>> simultanious reception of wildly different signal strengths)
>>>
>>> When you are sending, you will hear yourself as a VERY strong signal,
>>> trying to hear if someone else is transmitting at the same time is almost
>>> impossible (100 ft to 1 ft is 4 orders of magnatude, 1 ft to 1 inch is
>>> another 2 orders of magnatude)
>>>
>>> And it's very possible that the station that you are colliding with isn't
>>> one you can hear at all.
>>>
>>> Any AP is going to have a better antenna than any phone. (sometimes
>>> several orders of magnatude better), so even if you were located at the
>>> same place as the AP, the AP is going to hear signals that you don't.
>>>
>>> Then consider the case where you and the other station are on opposite
>>> sides of the AP at max range.
>>>
>>> and then add cases where there is a wall between you and the other
>>> station, but the AP can hear both of you.
>>>
>>> David Lang
>>>
>>>
>>

[-- Attachment #2: Type: text/html, Size: 6510 bytes --]

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 6293 bytes --]

On Mon, 27 Jun 2016, Bob McMahon wrote:

> packet size is smallest udp payload per a socket write() which in turn
> drives the smallest packet supported by "the wire."
>
> Here is a back of the envelope calculation giving ~100 microseconds per BE
> access.
>
> # Overhead estimates (slot time is 9 us):
> # o DIFS 50 us or *AIFS (3 * 9 us) = 27 us
> # o *Backoff Slot * CWmin,  9 us * rand[0,xf] (avg) = 7 * 9=63 us
> # o 5G 20 us
> # o Multimode header 20 us
> # o PLCP (symbols) 2 * 4 us = 8 us
> # o *SIFS 16 us
> # o ACK 40 us

isn't the ack a separate transmission by the other end of the connection? 
(subject to all the same overhead)

> #
> # Even if there is no collision and the CW stays at the aCWmin, the average
> # backoff time incurred by CSMA/CA is aDIFS + aCWmin/2 * aSlotTime = 16 µs
> # +(2+7.5)*9 µs = 101.5 µs for OFDM PHY, while the data rate with OFDM PHY
> # can reach 600 Mbps in 802.11n, leading to a transmission time of 20 µs
> # for a 1500 byte packet.

well, are you talking a 64 byte packet or a 1500 byte packet?

But this is a good example of why good aggregation is desirable. It doesn't have
to add a lot of latency. you could send 6x as much data in 2x the time by
sending 9K per transmission instead of 1.5K per transmission (+100us/7.5K)

if the aggregation is done lazily (send whatever's pending, don't wait for more 
data if you have an available transmit slot), this can be done with virtually no 
impact on latency, you just have to set a reasonable maximum, and adjust it 
based on your transmission rate.

The problem is that right now thing don't set a reasonable max, and they do 
greedy aggregation (wait until you have a lot of data to send before you send 
anything)

> All devices in a BSSID would have to agree that the second radio is to be
> used for BSSID "carrier state" information and all energy will be sourced
> by the AP serving that BSSID.  (A guess is doing this wouldn't improve the
> 100 us by enough to justify the cost and that a new MAC protocol is
> required.  Just curious to what such a protocol and phy subsystem would
> look like assuming collision avoidance could be replaced with collision
> detect.)

if the second radio is on a separate band, you have the problem that propogation
isn't going to be the same, so it's very possible to be able to talk to the AP
on the 'normal' channel, but not on the 'coordination' channel.

I'm also not sure what good it would do, once a transmission has been stepped
on, it will need to be re-sent (I guess you would be able to re-send immediatly)

David Lang

> Bob
>
>
>
> On Mon, Jun 27, 2016 at 1:09 PM, David Lang <david@lang.hm> wrote:
>
>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>
>> The ~10K is coming from empirical measurements where all aggregation
>>> technologies are disabled, i.e. only one small IP packet per medium
>>> arbitration/access and where there is only one transmitter and one
>>> receiver.  900Mb/sec is typically a peak-average throughput measurement
>>> where max (or near max) aggregation occurs, amortizing the access overhead
>>> across multiple packets.
>>>
>>
>> so 10K is minimum size packets being transmitted?or around 200
>> transmissions/sec (plus 200 ack transmissions/sec)?
>>
>> Yes, devices can be hidden from each other but not from the AP (hence the
>>> use of RTS/CTS per hidden node mitigation.) Isn't it the AP's view of the
>>> "carrier state" that matters (at least in infrastructure mode?)  If that's
>>> the case, what about a different band (and different radio) such that the
>>> strong signal carrying the data could be separated from the the BSSID's
>>> "carrier/energy state" signal?
>>>
>>
>> how do you solve the interference problem on this other band/radio? When
>> you have other APs in the area operating, you will have the same problem
>> there.
>>
>> David Lang
>>
>>
>> Bob
>>>
>>> On Mon, Jun 27, 2016 at 12:40 PM, David Lang <david@lang.hm> wrote:
>>>
>>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>>>
>>>> Hi All,
>>>>
>>>>>
>>>>> This is a very interesting thread - thanks to all for taking the time to
>>>>> respond.   (Personally, I now have better understanding of the
>>>>> difficulties
>>>>> associated with a PHY subsystem that supports a wide 1GHz.)
>>>>>
>>>>> Not to derail the current discussion, but I am curious to ideas on
>>>>> addressing the overhead associated with media access per collision
>>>>> avoidance.  This overhead seems to be limiting transmits to about 10K
>>>>> per
>>>>> second (even when a link has no competition for access.)
>>>>>
>>>>>
>>>> I'm not sure where you're getting 10K/second from. We do need to limit
>>>> the
>>>> amount of data transmitted in one session to give other stations a chance
>>>> to talk, but if the AP replies immediatly to ack the traffic, and the
>>>> airwaves are idle, you can transmit again pretty quickly.
>>>>
>>>> people using -ac equipment with a single station are getting 900Mb/sec
>>>> today.
>>>>
>>>>   Is there a way,
>>>>
>>>>> maybe using another dedicated radio, to achieve near instantaneous
>>>>> collision detect (where the CD is driven by the receiver state) such
>>>>> that
>>>>> mobile devices can sample RF energy to get theses states and state
>>>>> changes
>>>>> much more quickly?
>>>>>
>>>>>
>>>> This gets back to the same problems (hidden transmitter , and the
>>>> simultanious reception of wildly different signal strengths)
>>>>
>>>> When you are sending, you will hear yourself as a VERY strong signal,
>>>> trying to hear if someone else is transmitting at the same time is almost
>>>> impossible (100 ft to 1 ft is 4 orders of magnatude, 1 ft to 1 inch is
>>>> another 2 orders of magnatude)
>>>>
>>>> And it's very possible that the station that you are colliding with isn't
>>>> one you can hear at all.
>>>>
>>>> Any AP is going to have a better antenna than any phone. (sometimes
>>>> several orders of magnatude better), so even if you were located at the
>>>> same place as the AP, the AP is going to hear signals that you don't.
>>>>
>>>> Then consider the case where you and the other station are on opposite
>>>> sides of the AP at max range.
>>>>
>>>> and then add cases where there is a wall between you and the other
>>>> station, but the AP can hear both of you.
>>>>
>>>> David Lang
>>>>
>>>>
>>>
>

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 7281 bytes --]

While the 802.11 ack doesn't need to do collision avoidance, it does need
to wait a SIFS, send a PHY header and its typically transmitted at lower
PHY rate.   My estimate is 40 us for that overhead.  So yes, one would have
to get rid of that too, e.g. assume a transmit without a collision
succeeded - hopefully negating the need for the 802.11 ack.

(It does seem the wired engineers have it much easier per the point/point,
full duplex and wave guides.)

Bob

On Mon, Jun 27, 2016 at 2:09 PM, David Lang <david@lang.hm> wrote:

> On Mon, 27 Jun 2016, Bob McMahon wrote:
>
> packet size is smallest udp payload per a socket write() which in turn
>> drives the smallest packet supported by "the wire."
>>
>> Here is a back of the envelope calculation giving ~100 microseconds per BE
>> access.
>>
>> # Overhead estimates (slot time is 9 us):
>> # o DIFS 50 us or *AIFS (3 * 9 us) = 27 us
>> # o *Backoff Slot * CWmin,  9 us * rand[0,xf] (avg) = 7 * 9=63 us
>> # o 5G 20 us
>> # o Multimode header 20 us
>> # o PLCP (symbols) 2 * 4 us = 8 us
>> # o *SIFS 16 us
>> # o ACK 40 us
>>
>
> isn't the ack a separate transmission by the other end of the connection?
> (subject to all the same overhead)
>
> #
>> # Even if there is no collision and the CW stays at the aCWmin, the
>> average
>> # backoff time incurred by CSMA/CA is aDIFS + aCWmin/2 * aSlotTime = 16 µs
>> # +(2+7.5)*9 µs = 101.5 µs for OFDM PHY, while the data rate with OFDM PHY
>> # can reach 600 Mbps in 802.11n, leading to a transmission time of 20 µs
>> # for a 1500 byte packet.
>>
>
> well, are you talking a 64 byte packet or a 1500 byte packet?
>
> But this is a good example of why good aggregation is desirable. It
> doesn't have
> to add a lot of latency. you could send 6x as much data in 2x the time by
> sending 9K per transmission instead of 1.5K per transmission (+100us/7.5K)
>
> if the aggregation is done lazily (send whatever's pending, don't wait for
> more data if you have an available transmit slot), this can be done with
> virtually no impact on latency, you just have to set a reasonable maximum,
> and adjust it based on your transmission rate.
>
> The problem is that right now thing don't set a reasonable max, and they
> do greedy aggregation (wait until you have a lot of data to send before you
> send anything)
>
> All devices in a BSSID would have to agree that the second radio is to be
>> used for BSSID "carrier state" information and all energy will be sourced
>> by the AP serving that BSSID.  (A guess is doing this wouldn't improve the
>> 100 us by enough to justify the cost and that a new MAC protocol is
>> required.  Just curious to what such a protocol and phy subsystem would
>> look like assuming collision avoidance could be replaced with collision
>> detect.)
>>
>
> if the second radio is on a separate band, you have the problem that
> propogation
> isn't going to be the same, so it's very possible to be able to talk to
> the AP
> on the 'normal' channel, but not on the 'coordination' channel.
>
> I'm also not sure what good it would do, once a transmission has been
> stepped
> on, it will need to be re-sent (I guess you would be able to re-send
> immediatly)
>
>
> David Lang
>
> Bob
>>
>>
>>
>> On Mon, Jun 27, 2016 at 1:09 PM, David Lang <david@lang.hm> wrote:
>>
>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>>
>>> The ~10K is coming from empirical measurements where all aggregation
>>>
>>>> technologies are disabled, i.e. only one small IP packet per medium
>>>> arbitration/access and where there is only one transmitter and one
>>>> receiver.  900Mb/sec is typically a peak-average throughput measurement
>>>> where max (or near max) aggregation occurs, amortizing the access
>>>> overhead
>>>> across multiple packets.
>>>>
>>>>
>>> so 10K is minimum size packets being transmitted?or around 200
>>> transmissions/sec (plus 200 ack transmissions/sec)?
>>>
>>> Yes, devices can be hidden from each other but not from the AP (hence the
>>>
>>>> use of RTS/CTS per hidden node mitigation.) Isn't it the AP's view of
>>>> the
>>>> "carrier state" that matters (at least in infrastructure mode?)  If
>>>> that's
>>>> the case, what about a different band (and different radio) such that
>>>> the
>>>> strong signal carrying the data could be separated from the the BSSID's
>>>> "carrier/energy state" signal?
>>>>
>>>>
>>> how do you solve the interference problem on this other band/radio? When
>>> you have other APs in the area operating, you will have the same problem
>>> there.
>>>
>>> David Lang
>>>
>>>
>>> Bob
>>>
>>>>
>>>> On Mon, Jun 27, 2016 at 12:40 PM, David Lang <david@lang.hm> wrote:
>>>>
>>>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>>>
>>>>>
>>>>> Hi All,
>>>>>
>>>>>
>>>>>> This is a very interesting thread - thanks to all for taking the time
>>>>>> to
>>>>>> respond.   (Personally, I now have better understanding of the
>>>>>> difficulties
>>>>>> associated with a PHY subsystem that supports a wide 1GHz.)
>>>>>>
>>>>>> Not to derail the current discussion, but I am curious to ideas on
>>>>>> addressing the overhead associated with media access per collision
>>>>>> avoidance.  This overhead seems to be limiting transmits to about 10K
>>>>>> per
>>>>>> second (even when a link has no competition for access.)
>>>>>>
>>>>>>
>>>>>> I'm not sure where you're getting 10K/second from. We do need to limit
>>>>> the
>>>>> amount of data transmitted in one session to give other stations a
>>>>> chance
>>>>> to talk, but if the AP replies immediatly to ack the traffic, and the
>>>>> airwaves are idle, you can transmit again pretty quickly.
>>>>>
>>>>> people using -ac equipment with a single station are getting 900Mb/sec
>>>>> today.
>>>>>
>>>>>   Is there a way,
>>>>>
>>>>> maybe using another dedicated radio, to achieve near instantaneous
>>>>>> collision detect (where the CD is driven by the receiver state) such
>>>>>> that
>>>>>> mobile devices can sample RF energy to get theses states and state
>>>>>> changes
>>>>>> much more quickly?
>>>>>>
>>>>>>
>>>>>> This gets back to the same problems (hidden transmitter , and the
>>>>> simultanious reception of wildly different signal strengths)
>>>>>
>>>>> When you are sending, you will hear yourself as a VERY strong signal,
>>>>> trying to hear if someone else is transmitting at the same time is
>>>>> almost
>>>>> impossible (100 ft to 1 ft is 4 orders of magnatude, 1 ft to 1 inch is
>>>>> another 2 orders of magnatude)
>>>>>
>>>>> And it's very possible that the station that you are colliding with
>>>>> isn't
>>>>> one you can hear at all.
>>>>>
>>>>> Any AP is going to have a better antenna than any phone. (sometimes
>>>>> several orders of magnatude better), so even if you were located at the
>>>>> same place as the AP, the AP is going to hear signals that you don't.
>>>>>
>>>>> Then consider the case where you and the other station are on opposite
>>>>> sides of the AP at max range.
>>>>>
>>>>> and then add cases where there is a wall between you and the other
>>>>> station, but the AP can hear both of you.
>>>>>
>>>>> David Lang
>>>>>
>>>>>
>>>>>
>>>>

[-- Attachment #2: Type: text/html, Size: 9116 bytes --]

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 7855 bytes --]

On Mon, 27 Jun 2016, Bob McMahon wrote:

> While the 802.11 ack doesn't need to do collision avoidance, it does need
> to wait a SIFS, send a PHY header and its typically transmitted at lower
> PHY rate.   My estimate is 40 us for that overhead.  So yes, one would have
> to get rid of that too, e.g. assume a transmit without a collision
> succeeded - hopefully negating the need for the 802.11 ack.

don't forget that while there is teh 802.11 ack, there is also the TCP ack that 
will show up later as well.

> (It does seem the wired engineers have it much easier per the point/point,
> full duplex and wave guides.)

yep. even wireless is far easier when you can do point-to-point with highly 
directional antennas. Even if you don't do full duplex as well.

It's the mobility and unpredictability of the stations that makes things hard. 
The fact that Wifi works as well as it does is impressive, given the amount 
things have changed since it was designed, and the fact that backwards 
compatibility has been maintained.

David Lang

> Bob
>
> On Mon, Jun 27, 2016 at 2:09 PM, David Lang <david@lang.hm> wrote:
>
>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>
>> packet size is smallest udp payload per a socket write() which in turn
>>> drives the smallest packet supported by "the wire."
>>>
>>> Here is a back of the envelope calculation giving ~100 microseconds per BE
>>> access.
>>>
>>> # Overhead estimates (slot time is 9 us):
>>> # o DIFS 50 us or *AIFS (3 * 9 us) = 27 us
>>> # o *Backoff Slot * CWmin,  9 us * rand[0,xf] (avg) = 7 * 9=63 us
>>> # o 5G 20 us
>>> # o Multimode header 20 us
>>> # o PLCP (symbols) 2 * 4 us = 8 us
>>> # o *SIFS 16 us
>>> # o ACK 40 us
>>>
>>
>> isn't the ack a separate transmission by the other end of the connection?
>> (subject to all the same overhead)
>>
>> #
>>> # Even if there is no collision and the CW stays at the aCWmin, the
>>> average
>>> # backoff time incurred by CSMA/CA is aDIFS + aCWmin/2 * aSlotTime = 16 µs
>>> # +(2+7.5)*9 µs = 101.5 µs for OFDM PHY, while the data rate with OFDM PHY
>>> # can reach 600 Mbps in 802.11n, leading to a transmission time of 20 µs
>>> # for a 1500 byte packet.
>>>
>>
>> well, are you talking a 64 byte packet or a 1500 byte packet?
>>
>> But this is a good example of why good aggregation is desirable. It
>> doesn't have
>> to add a lot of latency. you could send 6x as much data in 2x the time by
>> sending 9K per transmission instead of 1.5K per transmission (+100us/7.5K)
>>
>> if the aggregation is done lazily (send whatever's pending, don't wait for
>> more data if you have an available transmit slot), this can be done with
>> virtually no impact on latency, you just have to set a reasonable maximum,
>> and adjust it based on your transmission rate.
>>
>> The problem is that right now thing don't set a reasonable max, and they
>> do greedy aggregation (wait until you have a lot of data to send before you
>> send anything)
>>
>> All devices in a BSSID would have to agree that the second radio is to be
>>> used for BSSID "carrier state" information and all energy will be sourced
>>> by the AP serving that BSSID.  (A guess is doing this wouldn't improve the
>>> 100 us by enough to justify the cost and that a new MAC protocol is
>>> required.  Just curious to what such a protocol and phy subsystem would
>>> look like assuming collision avoidance could be replaced with collision
>>> detect.)
>>>
>>
>> if the second radio is on a separate band, you have the problem that
>> propogation
>> isn't going to be the same, so it's very possible to be able to talk to
>> the AP
>> on the 'normal' channel, but not on the 'coordination' channel.
>>
>> I'm also not sure what good it would do, once a transmission has been
>> stepped
>> on, it will need to be re-sent (I guess you would be able to re-send
>> immediatly)
>>
>>
>> David Lang
>>
>> Bob
>>>
>>>
>>>
>>> On Mon, Jun 27, 2016 at 1:09 PM, David Lang <david@lang.hm> wrote:
>>>
>>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>>>
>>>> The ~10K is coming from empirical measurements where all aggregation
>>>>
>>>>> technologies are disabled, i.e. only one small IP packet per medium
>>>>> arbitration/access and where there is only one transmitter and one
>>>>> receiver.  900Mb/sec is typically a peak-average throughput measurement
>>>>> where max (or near max) aggregation occurs, amortizing the access
>>>>> overhead
>>>>> across multiple packets.
>>>>>
>>>>>
>>>> so 10K is minimum size packets being transmitted?or around 200
>>>> transmissions/sec (plus 200 ack transmissions/sec)?
>>>>
>>>> Yes, devices can be hidden from each other but not from the AP (hence the
>>>>
>>>>> use of RTS/CTS per hidden node mitigation.) Isn't it the AP's view of
>>>>> the
>>>>> "carrier state" that matters (at least in infrastructure mode?)  If
>>>>> that's
>>>>> the case, what about a different band (and different radio) such that
>>>>> the
>>>>> strong signal carrying the data could be separated from the the BSSID's
>>>>> "carrier/energy state" signal?
>>>>>
>>>>>
>>>> how do you solve the interference problem on this other band/radio? When
>>>> you have other APs in the area operating, you will have the same problem
>>>> there.
>>>>
>>>> David Lang
>>>>
>>>>
>>>> Bob
>>>>
>>>>>
>>>>> On Mon, Jun 27, 2016 at 12:40 PM, David Lang <david@lang.hm> wrote:
>>>>>
>>>>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>>>>
>>>>>>
>>>>>> Hi All,
>>>>>>
>>>>>>
>>>>>>> This is a very interesting thread - thanks to all for taking the time
>>>>>>> to
>>>>>>> respond.   (Personally, I now have better understanding of the
>>>>>>> difficulties
>>>>>>> associated with a PHY subsystem that supports a wide 1GHz.)
>>>>>>>
>>>>>>> Not to derail the current discussion, but I am curious to ideas on
>>>>>>> addressing the overhead associated with media access per collision
>>>>>>> avoidance.  This overhead seems to be limiting transmits to about 10K
>>>>>>> per
>>>>>>> second (even when a link has no competition for access.)
>>>>>>>
>>>>>>>
>>>>>>> I'm not sure where you're getting 10K/second from. We do need to limit
>>>>>> the
>>>>>> amount of data transmitted in one session to give other stations a
>>>>>> chance
>>>>>> to talk, but if the AP replies immediatly to ack the traffic, and the
>>>>>> airwaves are idle, you can transmit again pretty quickly.
>>>>>>
>>>>>> people using -ac equipment with a single station are getting 900Mb/sec
>>>>>> today.
>>>>>>
>>>>>>   Is there a way,
>>>>>>
>>>>>> maybe using another dedicated radio, to achieve near instantaneous
>>>>>>> collision detect (where the CD is driven by the receiver state) such
>>>>>>> that
>>>>>>> mobile devices can sample RF energy to get theses states and state
>>>>>>> changes
>>>>>>> much more quickly?
>>>>>>>
>>>>>>>
>>>>>>> This gets back to the same problems (hidden transmitter , and the
>>>>>> simultanious reception of wildly different signal strengths)
>>>>>>
>>>>>> When you are sending, you will hear yourself as a VERY strong signal,
>>>>>> trying to hear if someone else is transmitting at the same time is
>>>>>> almost
>>>>>> impossible (100 ft to 1 ft is 4 orders of magnatude, 1 ft to 1 inch is
>>>>>> another 2 orders of magnatude)
>>>>>>
>>>>>> And it's very possible that the station that you are colliding with
>>>>>> isn't
>>>>>> one you can hear at all.
>>>>>>
>>>>>> Any AP is going to have a better antenna than any phone. (sometimes
>>>>>> several orders of magnatude better), so even if you were located at the
>>>>>> same place as the AP, the AP is going to hear signals that you don't.
>>>>>>
>>>>>> Then consider the case where you and the other station are on opposite
>>>>>> sides of the AP at max range.
>>>>>>
>>>>>> and then add cases where there is a wall between you and the other
>>>>>> station, but the AP can hear both of you.
>>>>>>
>>>>>> David Lang
>>>>>>
>>>>>>
>>>>>>
>>>>>
>

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Bob McMahon]

[-- Attachment #1: Type: text/plain, Size: 8876 bytes --]

On a clean, conducted network I'm getting about 900 us UDP end/end latency
and about 2 ms TCP RTT, no aggregation, 9x2 VHT, small packets,
undersubscribed (1Mbs) offered load for both protocols.   So TCP does seem
to double the latency per the need to fully arbitrate access and send its
ack.

Bob

On Mon, Jun 27, 2016 at 3:18 PM, David Lang <david@lang.hm> wrote:

> On Mon, 27 Jun 2016, Bob McMahon wrote:
>
> While the 802.11 ack doesn't need to do collision avoidance, it does need
>> to wait a SIFS, send a PHY header and its typically transmitted at lower
>> PHY rate.   My estimate is 40 us for that overhead.  So yes, one would
>> have
>> to get rid of that too, e.g. assume a transmit without a collision
>> succeeded - hopefully negating the need for the 802.11 ack.
>>
>
> don't forget that while there is teh 802.11 ack, there is also the TCP ack
> that will show up later as well.
>
> (It does seem the wired engineers have it much easier per the point/point,
>> full duplex and wave guides.)
>>
>
> yep. even wireless is far easier when you can do point-to-point with
> highly directional antennas. Even if you don't do full duplex as well.
>
> It's the mobility and unpredictability of the stations that makes things
> hard. The fact that Wifi works as well as it does is impressive, given the
> amount things have changed since it was designed, and the fact that
> backwards compatibility has been maintained.
>
>
> David Lang
>
> Bob
>>
>> On Mon, Jun 27, 2016 at 2:09 PM, David Lang <david@lang.hm> wrote:
>>
>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>>
>>> packet size is smallest udp payload per a socket write() which in turn
>>>
>>>> drives the smallest packet supported by "the wire."
>>>>
>>>> Here is a back of the envelope calculation giving ~100 microseconds per
>>>> BE
>>>> access.
>>>>
>>>> # Overhead estimates (slot time is 9 us):
>>>> # o DIFS 50 us or *AIFS (3 * 9 us) = 27 us
>>>> # o *Backoff Slot * CWmin,  9 us * rand[0,xf] (avg) = 7 * 9=63 us
>>>> # o 5G 20 us
>>>> # o Multimode header 20 us
>>>> # o PLCP (symbols) 2 * 4 us = 8 us
>>>> # o *SIFS 16 us
>>>> # o ACK 40 us
>>>>
>>>>
>>> isn't the ack a separate transmission by the other end of the connection?
>>> (subject to all the same overhead)
>>>
>>> #
>>>
>>>> # Even if there is no collision and the CW stays at the aCWmin, the
>>>> average
>>>> # backoff time incurred by CSMA/CA is aDIFS + aCWmin/2 * aSlotTime = 16
>>>> µs
>>>> # +(2+7.5)*9 µs = 101.5 µs for OFDM PHY, while the data rate with OFDM
>>>> PHY
>>>> # can reach 600 Mbps in 802.11n, leading to a transmission time of 20 µs
>>>> # for a 1500 byte packet.
>>>>
>>>>
>>> well, are you talking a 64 byte packet or a 1500 byte packet?
>>>
>>> But this is a good example of why good aggregation is desirable. It
>>> doesn't have
>>> to add a lot of latency. you could send 6x as much data in 2x the time by
>>> sending 9K per transmission instead of 1.5K per transmission
>>> (+100us/7.5K)
>>>
>>> if the aggregation is done lazily (send whatever's pending, don't wait
>>> for
>>> more data if you have an available transmit slot), this can be done with
>>> virtually no impact on latency, you just have to set a reasonable
>>> maximum,
>>> and adjust it based on your transmission rate.
>>>
>>> The problem is that right now thing don't set a reasonable max, and they
>>> do greedy aggregation (wait until you have a lot of data to send before
>>> you
>>> send anything)
>>>
>>> All devices in a BSSID would have to agree that the second radio is to be
>>>
>>>> used for BSSID "carrier state" information and all energy will be
>>>> sourced
>>>> by the AP serving that BSSID.  (A guess is doing this wouldn't improve
>>>> the
>>>> 100 us by enough to justify the cost and that a new MAC protocol is
>>>> required.  Just curious to what such a protocol and phy subsystem would
>>>> look like assuming collision avoidance could be replaced with collision
>>>> detect.)
>>>>
>>>>
>>> if the second radio is on a separate band, you have the problem that
>>> propogation
>>> isn't going to be the same, so it's very possible to be able to talk to
>>> the AP
>>> on the 'normal' channel, but not on the 'coordination' channel.
>>>
>>> I'm also not sure what good it would do, once a transmission has been
>>> stepped
>>> on, it will need to be re-sent (I guess you would be able to re-send
>>> immediatly)
>>>
>>>
>>> David Lang
>>>
>>> Bob
>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jun 27, 2016 at 1:09 PM, David Lang <david@lang.hm> wrote:
>>>>
>>>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>>>
>>>>>
>>>>> The ~10K is coming from empirical measurements where all aggregation
>>>>>
>>>>> technologies are disabled, i.e. only one small IP packet per medium
>>>>>> arbitration/access and where there is only one transmitter and one
>>>>>> receiver.  900Mb/sec is typically a peak-average throughput
>>>>>> measurement
>>>>>> where max (or near max) aggregation occurs, amortizing the access
>>>>>> overhead
>>>>>> across multiple packets.
>>>>>>
>>>>>>
>>>>>> so 10K is minimum size packets being transmitted?or around 200
>>>>> transmissions/sec (plus 200 ack transmissions/sec)?
>>>>>
>>>>> Yes, devices can be hidden from each other but not from the AP (hence
>>>>> the
>>>>>
>>>>> use of RTS/CTS per hidden node mitigation.) Isn't it the AP's view of
>>>>>> the
>>>>>> "carrier state" that matters (at least in infrastructure mode?)  If
>>>>>> that's
>>>>>> the case, what about a different band (and different radio) such that
>>>>>> the
>>>>>> strong signal carrying the data could be separated from the the
>>>>>> BSSID's
>>>>>> "carrier/energy state" signal?
>>>>>>
>>>>>>
>>>>>> how do you solve the interference problem on this other band/radio?
>>>>> When
>>>>> you have other APs in the area operating, you will have the same
>>>>> problem
>>>>> there.
>>>>>
>>>>> David Lang
>>>>>
>>>>>
>>>>> Bob
>>>>>
>>>>>
>>>>>> On Mon, Jun 27, 2016 at 12:40 PM, David Lang <david@lang.hm> wrote:
>>>>>>
>>>>>> On Mon, 27 Jun 2016, Bob McMahon wrote:
>>>>>>
>>>>>>
>>>>>>> Hi All,
>>>>>>>
>>>>>>>
>>>>>>> This is a very interesting thread - thanks to all for taking the time
>>>>>>>> to
>>>>>>>> respond.   (Personally, I now have better understanding of the
>>>>>>>> difficulties
>>>>>>>> associated with a PHY subsystem that supports a wide 1GHz.)
>>>>>>>>
>>>>>>>> Not to derail the current discussion, but I am curious to ideas on
>>>>>>>> addressing the overhead associated with media access per collision
>>>>>>>> avoidance.  This overhead seems to be limiting transmits to about
>>>>>>>> 10K
>>>>>>>> per
>>>>>>>> second (even when a link has no competition for access.)
>>>>>>>>
>>>>>>>>
>>>>>>>> I'm not sure where you're getting 10K/second from. We do need to
>>>>>>>> limit
>>>>>>>>
>>>>>>> the
>>>>>>> amount of data transmitted in one session to give other stations a
>>>>>>> chance
>>>>>>> to talk, but if the AP replies immediatly to ack the traffic, and the
>>>>>>> airwaves are idle, you can transmit again pretty quickly.
>>>>>>>
>>>>>>> people using -ac equipment with a single station are getting
>>>>>>> 900Mb/sec
>>>>>>> today.
>>>>>>>
>>>>>>>   Is there a way,
>>>>>>>
>>>>>>> maybe using another dedicated radio, to achieve near instantaneous
>>>>>>>
>>>>>>>> collision detect (where the CD is driven by the receiver state) such
>>>>>>>> that
>>>>>>>> mobile devices can sample RF energy to get theses states and state
>>>>>>>> changes
>>>>>>>> much more quickly?
>>>>>>>>
>>>>>>>>
>>>>>>>> This gets back to the same problems (hidden transmitter , and the
>>>>>>>>
>>>>>>> simultanious reception of wildly different signal strengths)
>>>>>>>
>>>>>>> When you are sending, you will hear yourself as a VERY strong signal,
>>>>>>> trying to hear if someone else is transmitting at the same time is
>>>>>>> almost
>>>>>>> impossible (100 ft to 1 ft is 4 orders of magnatude, 1 ft to 1 inch
>>>>>>> is
>>>>>>> another 2 orders of magnatude)
>>>>>>>
>>>>>>> And it's very possible that the station that you are colliding with
>>>>>>> isn't
>>>>>>> one you can hear at all.
>>>>>>>
>>>>>>> Any AP is going to have a better antenna than any phone. (sometimes
>>>>>>> several orders of magnatude better), so even if you were located at
>>>>>>> the
>>>>>>> same place as the AP, the AP is going to hear signals that you don't.
>>>>>>>
>>>>>>> Then consider the case where you and the other station are on
>>>>>>> opposite
>>>>>>> sides of the AP at max range.
>>>>>>>
>>>>>>> and then add cases where there is a wall between you and the other
>>>>>>> station, but the AP can hear both of you.
>>>>>>>
>>>>>>> David Lang
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>

[-- Attachment #2: Type: text/html, Size: 10854 bytes --]

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Sebastian Moeller]

Hi Dave, 

On June 27, 2016 2:00:55 AM GMT+02:00, David Lang <david@lang.hm> wrote:
>I don't think anyone is trying to do simultanious receive of different
>stations. 
>That is an incredibly difficult thing to do right.
>
>MU-MIMO is aimed at haivng the AP transmit to multiple stations at the
>same 
>time. For the typical browser/streaming use, this traffic is FAR larger
>than the 
>traffic from the stations to the AP. As such, it is worth focusing on
>optimizing 
>this direction.
>
>While an ideal network may resemble a wired network without guides, I
>don't 
>think it's a good idea to think about wifi networks that way.
>
>The reality is that no matter how good you get, a wireless network is
>going to 
>have lots of things that are just not going to happen with wired
>networks.
>
>1. drastic variations in signal strength.
>
>On a wired network with a shared buss, the signal strength from all
>stations 
>on the network is going to be very close to the same (a difference of
>2x would 
>be extreme)
>
>On a wireless network, with 'normal' omnidirctional antennas, the
>signal drops 
>off with the square of the distance. So if you want to service clients
>from 1 ft 
>to 100 ft away, your signal strength varies by 1000 (4 orders of
>magnatude), 
>this is before you include effects of shielding, bounces, bad antenna
>alignment, 
>etc (which can add several more orders of magnatude of variation)
>
>The receiver first normalized the strongest part of the signal to a
>constant 
>value, and then digitizes the result, (usually with a 12-14 bit AD
>converter). 
>Since 1000x is ~10 bits, the result of overlapping tranmissions can be
>one 
>signal at 14 bits, and another at <4 bits. This is why digital
>processing isn't 
>able to receive multiple stations at the same time.

      But, I you add 10 Bits to your AD converter you basically solved this. Now, most likely this also needs to be of higher quality and of low internal noise, so probably expensive... Add to this the wide-band requirement of the sample the full band approach and we are looking at a price ad converter. On the bright side, mass-producing that might lower the price for nice oscilloscopes...


Best Regards
       Sebastian 


>
>2. 'hidden transmitters'
>
>On modern wired networks, every link has exactly two stations on it,
>and both 
>can transmit at the same time.
>
>On wireless networks, it's drastically different. You have an unknown
>number 
>of stations (which can come and go without notice).
>
>Not every station can hear every other station. This means that they
>can't 
>avoid colliding with each other. In theory you can work around this by
>having 
>some central system coordinate all the clients (either by them being
>told when 
>to transmit, or by being given a schedule and having very precise
>clocks). But 
>in practice the central system doesn't know when the clients have
>something to 
>say and so in practice this doesn't work as well (except for special
>cases like 
>voice where there is a constant amount of data to transmit)
>
>3. variable transmit rates and aggregation
>
>Depending on how strong the signal is between two stations, you have
>different 
>limits to how fast you can transmit data. There are many different
>standard 
>modulations that you can use, but if you use one that's too fast for
>the signal 
>conditions, the receiver isn't going to be able to decode it. If you
>use one 
>that's too slow, you increase the probability that another station will
>step on 
>your signal, scrambling it as far as the receiver is concerned. We now
>have 
>stations on the network that can vary in speed by 100x, and are nearing
>1000x 
>(1Mb/sec to 1Gb/sec)
>
>Because there is so much variation in transmit rates, and older
>stations will 
>not be able to understand the newest rates, each transmission starts
>off with 
>some data being transmitted at the slowest available rate, telling any
>stations 
>that are listening that there is data being transmitted for X amount of
>time, 
>even if they can't tell what's going on as the data is being
>transmitted.
>
>The combination of this header being transmitted inefficiently, and the
>fact 
>that stations are waiting for a clear window to transmit, means that
>when you do 
>get a chance to transmit, you should send more than one packet at a
>time. This 
>is something Linux is currently not doing well, qdiscs tend to
>round-robin 
>packets without regard to where they are headed. The current work being
>done 
>here with the queues is improving both throughput and latency by fixing
>this 
>problem.
>
>
>You really need to think differently when dealing with wireless
>network. The 
>early wifi drivers tried to make them look just like a wired network,
>and we 
>have found that we just needed too much other stuff to be successful
>whith that 
>mindset.
>
>The Analog/Radio side of things really is important, and can't just be 
>abstracted away.
>
>David Lang
>
>On Sun, 26 Jun 2016, Bob McMahon wrote:
>
>> Is there a specific goal in mind?  This seems an AP tx centric
>proposal,
>> though I may not be fully understanding it.  I'm also curious as why
>not
>> scale in spatial domain vs the frequency domain, i.e. AP and STAs can
>also
>> scale using MiMO.  Why not just do that? So many phones today are
>1x1, some
>> 2x2 and few 3x3.   Yet APs are moving to 4x4 and I think the standard
>> supports 8x8.  (I'm not sure the marginal transistor count increase
>per
>> each approach.)  On the AP tx side, MuMIMO is also there which I
>think is
>> similar to the DAC proposal.
>>
>> I'm far from a PHY & DSP expert, but I think the simultaneous AP
>receive is
>> the most difficult issue per the power variations, aka SNR.  Each of
>the
>> mobile device energies is affected per inverse square law (unless
>some form
>> of wave guide is used.)  Hence wi-fi use of time domain slots prior
>to
>> transmit (no longer simultaneous in time.)  Particularly needed for
>devices
>> that communicate with one another.  Unfortunately, "collocated"
>> energy/information sources must honor this TDM  even when not
>communication
>> with one another per tragedy of the commons.  (Agreed there is no
>such
>> thing as a collision so let's redefine it to mean that the receiver
>is
>> unable to receive per RF energy "confusion", still a tragedy of the
>> commons.  I don't know what drives the limits to DSP decode that
>could
>> minimize or eliminate  this tragedy.)
>>
>> At the end of the day, would the ideal network would resemble a wired
>> ethernet (including ethernet switch fabric) without the waveguides
>(or
>> wires/fibers)?  From that perspective, here are some thoughts to the
>goals
>>
>> o)  TX op/access to transmit driven to zero.  (Collision avoidance
>isn't
>> nearly as good as instantaneous collision detect in this context,
>though
>> "collision" should replaced with "confusion")
>> o)  RX confusion detection time propagated to stop offending TX(s)
>driven
>> to zero
>> o)  Support of different encodings (e..g phy rates) pushes towards
>virtual
>> output queueing prior (queuing at the transmitter)
>> o)  Power per bit xfered towards zero or driven per cost & energy
>density
>> of batteries.  Note: Atomic batteries not allowed per humans being
>involved.
>> o)  Transistor count (chip cost) per bit moved driven by Moore's law
>and
>> those economics
>> o)  Reduce "collision/confusion" domain (less STAs per AP) ideally to
>zero
>>
>> Just some thoughts off the top of my head.  Please do comment and
>correct.
>> Thanks in advance for the discussion.
>>
>> Bob
>>
>>
>>
>>
>> On Fri, Jun 24, 2016 at 2:24 PM, <dpreed@reed.com> wrote:
>>
>>> Without custom silicon, doing what I was talking about would involve
>non
>>> standard MAC power management, which would require all devices to
>agree.
>>>
>>> David Lang's explanation was the essence of what I meant. the
>transmission
>>> from access point on multiple channels is just digital addition if
>the DACs
>>> have enough bits per sample. to make sure that the signals to the AP
>are
>>> equalized, just transmit at a power that makes that approximately
>true...
>>> which means a power amp with at most 30 dB of dynamic gain setting.
>typical
>>> dynamic path attenuation range (strongest to weakest ratio) among
>stations
>>> served by an AP is < 20 dB from my past experiments on well
>>> operating-installtions, but 25 can be seen in reflection heavy
>>> environments.-----Original Message-----
>>> From: "David Lang" <david@lang.hm>
>>> Sent: Fri, Jun 24, 2016 at 1:19 am
>>> To: "Bob McMahon" <bob.mcmahon@broadcom.com>
>>> Cc: "Bob McMahon" <bob.mcmahon@broadcom.com>,
>>> make-wifi-fast@lists.bufferbloat.net,
>"cerowrt-devel@lists.bufferbloat.net"
>>> <cerowrt-devel@lists.bufferbloat.net>
>>> Subject: Re: [Make-wifi-fast] more well funded attempts showing
>market
>>> demandfor better wifi
>>>
>>> well, with the kickstarter, I think they are selling a bill of
>goods.
>>>
>>> Just using the DFS channels and aggregating them as supported by N
>and AC
>>> standards would do wonders (as long as others near you don't do the
>same)
>>>
>>> David Lang
>>>
>>> On Thu, 23 Jun 2016, Bob McMahon wrote:
>>>
>>>> Date: Thu, 23 Jun 2016 20:01:22 -0700
>>>> From: Bob McMahon
>>>> To: David Lang
>>>> Cc: dpreed@reed.com, make-wifi-fast@lists.bufferbloat.net,
>>>>     "cerowrt-devel@lists.bufferbloat.net"
>>>>
>>>> Subject: Re: [Make-wifi-fast] more well funded attempts showing
>market
>>> demand
>>>>     for better wifi
>>>>
>>>> Thanks for the clarification.   Though now I'm confused about how
>all the
>>>> channels would be used simultaneously with an AP only solution
>(which is
>>> my
>>>> understanding of the kickstarter campaign.)
>>>>
>>>> Bob
>>>>
>>>> On Thu, Jun 23, 2016 at 7:14 PM, David Lang  wrote:
>>>>
>>>>> I think he is meaning when one unit is talking to one AP the
>signal
>>> levels
>>>>> across multiple channels will be similar. Which is probably fairly
>true.
>>>>>
>>>>>
>>>>> David Lang
>>>>>
>>>>> On Thu, 23 Jun 2016, Bob McMahon wrote:
>>>>>
>>>>> Curious, where does the "in a LAN setup, the variability in
>[receive]
>>>>>> signal strength is likely small enough" assertion come?   Any
>specific
>>>>>> power numbers here? We test with many combinations of "signal
>strength
>>>>>> variability" (e.g. deltas range from 0 dBm -  50 dBm) and per
>different
>>>>>> channel conditions.  This includes power variability within the
>spatial
>>>>>> streams' MiMO transmission.   It would be helpful to have some
>physics
>>>>>> combined with engineering to produce some pragmatic limits to
>this.
>>>>>>
>>>>>> Also, mobile devices have a goal of reducing power in order to be
>>>>>> efficient
>>>>>> with their battery (vs a goal to balance power such that an AP
>can
>>>>>> receive simultaneously.)  Power per bit usually trumps most other
>>> design
>>>>>> goals.  There market for battery powered wi-fi devices drives a
>>>>>> semi-conductor mfg's revenue so my information come with that
>bias.
>>>>>>
>>>>>> Bob
>>>>>>
>>>>>> On Thu, Jun 23, 2016 at 1:48 PM,  wrote:
>>>>>>
>>>>>> The actual issues of transmitting on multiple channels at the
>same time
>>>>>>> are quite minor if you do the work in the digital domain
>(pre-DAC).
>>> You
>>>>>>> just need a higher sampling rate in the DAC and add the two
>signals
>>>>>>> together (and use a wideband filter that covers all the
>channels).
>>> No RF
>>>>>>> problem.
>>>>>>>
>>>>>>> Receiving multiple transmissions in different channels is pretty
>much
>>> the
>>>>>>> same problem - just digitize (ADC) a wider bandwidth and
>separate in
>>> the
>>>>>>> digital domain.  the only real issue on receive is equalization
>- if
>>> you
>>>>>>> receive two different signals at different receive signal
>strengths,
>>> the
>>>>>>> lower strength signal won't get as much dynamic range in its
>samples.
>>>>>>>
>>>>>>> But in a LAN setup, the variability in signal strength is likely
>small
>>>>>>> enough that you can cover that with more ADC bits (or have the
>MAC
>>>>>>> protocol
>>>>>>> manage the station transmit power so that signals received at
>the AP
>>> are
>>>>>>> nearly the same power.
>>>>>>>
>>>>>>> Equalization at transmit works very well when there is a central
>AP
>>> (as
>>>>>>> in
>>>>>>> cellular or normal WiFi systems).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thursday, June 23, 2016 4:28pm, "Bob McMahon" >>>
>>> bob.mcmahon@broadcom.com>
>>>>>>> said:
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>> Make-wifi-fast mailing list
>>>>>>>> Make-wifi-fast@lists.bufferbloat.net
>>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>>> An AP per room/area, reducing the tx power (beacon range) has
>been my
>>>>>>>> approach and has scaled very well.   It does require some wires
>to
>>> each
>>>>>>>>
>>>>>>> AP
>>>>>>>
>>>>>>>> but I find that paying an electrician to run some quality
>wiring to
>>>>>>>>
>>>>>>> things
>>>>>>>
>>>>>>>> that are to remain stationary has been well worth the cost.
>>>>>>>>
>>>>>>>> just my $0.02,
>>>>>>>> Bob
>>>>>>>>
>>>>>>>> On Thu, Jun 23, 2016 at 1:10 PM, David Lang  wrote:
>>>>>>>>
>>>>>>>> Well, just using the 5GHz DFS channels in 80MHz or 160 MHz wide
>>> chunks
>>>>>>>>> would be a huge improvement, not many people are using them
>(yet),
>>> and
>>>>>>>>>
>>>>>>>> the
>>>>>>>
>>>>>>>> wide channels let you get a lot of data out at once. If
>everything is
>>>>>>>>> within a good range of the AP, this would work pretty well. If
>you
>>> end
>>>>>>>>>
>>>>>>>> up
>>>>>>>
>>>>>>>> needing multiple APs, or you have many stations, I expect that
>you
>>> will
>>>>>>>>>
>>>>>>>> be
>>>>>>>
>>>>>>>> better off with more APs at lower power, each using different
>>> channels.
>>>>>>>>>
>>>>>>>>> David Lang
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, 23 Jun 2016, Bob McMahon wrote:
>>>>>>>>>
>>>>>>>>> Date: Thu, 23 Jun 2016 12:55:19 -0700
>>>>>>>>>
>>>>>>>>>> From: Bob McMahon
>>>>>>>>>> To: Dave Taht
>>>>>>>>>> Cc: make-wifi-fast@lists.bufferbloat.net,
>>>>>>>>>>     "cerowrt-devel@lists.bufferbloat.net"
>>>>>>>>>>
>>>>>>>>>> Subject: Re: [Make-wifi-fast] more well funded attempts
>showing
>>> market
>>>>>>>>>> demand
>>>>>>>>>>     for better wifi
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> hmm, I'm skeptical.   To use multiple carriers simultaneously
>is
>>>>>>>>>>
>>>>>>>>> difficult
>>>>>>>
>>>>>>>> per RF issues.   Even if that is somehow resolved, to increase
>>>>>>>>>>
>>>>>>>>> throughput
>>>>>>>
>>>>>>>> usually requires some form of channel bonding, i.e. needed on
>both
>>>>>>>>>>
>>>>>>>>> sides,
>>>>>>>
>>>>>>>> and brings in issues with preserving frame ordering.  If this
>is just
>>>>>>>>>> channel hopping, that needs coordination between both sides
>(and
>>> isn't
>>>>>>>>>> simultaneous, possibly costing more than any potential gain.)
>  An
>>> AP
>>>>>>>>>>
>>>>>>>>> only
>>>>>>>
>>>>>>>> solution can use channel switch announcements (CSA) but there
>is a
>>>>>>>>>>
>>>>>>>>> cost to
>>>>>>>
>>>>>>>> those as well.
>>>>>>>>>>
>>>>>>>>>> I guess don't see any break though here and the marketing on
>the
>>> site
>>>>>>>>>> seems
>>>>>>>>>> to indicate something beyond physics, at least the physics
>that I
>>>>>>>>>> understand.  Always willing to learn and be corrected if I'm
>>>>>>>>>> misunderstanding things.
>>>>>>>>>>
>>>>>>>>>> Bob
>>>>>>>>>>
>>>>>>>>>> On Wed, Jun 22, 2016 at 10:18 AM, Dave Taht
>>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>>> On Wed, Jun 22, 2016 at 10:03 AM, Dave Taht
>>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>>
>https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi?ref=backerkit
>>>>>>>
>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> "Portal is the first and only router specifically
>engineered to
>>> cut
>>>>>>>>>>>> through and avoid congestion, delivering consistent,
>>>>>>>>>>>> high-performance
>>>>>>>>>>>> WiFi with greater coverage throughout your home.
>>>>>>>>>>>>
>>>>>>>>>>>> Its proprietary spectrum turbocharger technology provides
>access
>>> to
>>>>>>>>>>>> 300% more of the radio airwaves than any other router,
>improving
>>>>>>>>>>>> performance by as much as 300x, and range and coverage by
>as
>>> much as
>>>>>>>>>>>> 2x in crowded settings, such as city homes and multi-unit
>>>>>>>>>>>> apartments"
>>>>>>>>>>>>
>>>>>>>>>>>> It sounds like they are promising working DFS support.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> It's not clear what chipset they are using (they are
>claiming
>>> wave2)
>>>>>>>>>>> -
>>>>>>>>>>> but they are at least publicly claiming to be using openwrt.
>So I
>>>>>>>>>>> threw in enough to order one for september, just so I could
>>> comment
>>>>>>>>>>> on
>>>>>>>>>>> their kickstarter page. :)
>>>>>>>>>>>
>>>>>>>>>>> I'd have loved to have got in earlier (early shipments are
>this
>>> month
>>>>>>>>>>> apparently), but those were sold out.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>
>>>
>https://www.kickstarter.com/projects/portalwifi/portal-turbocharged-wifi/comments
>>>>>>>
>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>>> Dave Täht
>>>>>>>>>>>> Let's go make home routers and wifi faster! With better
>software!
>>>>>>>>>>>> http://blog.cerowrt.org
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Dave Täht
>>>>>>>>>>> Let's go make home routers and wifi faster! With better
>software!
>>>>>>>>>>> http://blog.cerowrt.org
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> Make-wifi-fast mailing list
>>>>>>>>>>> Make-wifi-fast@lists.bufferbloat.net
>>>>>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>> Make-wifi-fast mailing list
>>>>>>>>> Make-wifi-fast@lists.bufferbloat.net
>>>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>
>>>
>>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Cerowrt-devel mailing list
>Cerowrt-devel@lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/cerowrt-devel

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[David Lang]

On Mon, 27 Jun 2016, Sebastian Moeller wrote:

>> On a wireless network, with 'normal' omnidirctional antennas, the signal 
>> drops off with the square of the distance. So if you want to service clients 
>> from 1 ft to 100 ft away, your signal strength varies by 1000 (4 orders of 
>> magnatude), this is before you include effects of shielding, bounces, bad 
>> antenna alignment, etc (which can add several more orders of magnatude of 
>> variation)
>>
>> The receiver first normalized the strongest part of the signal to a constant 
>> value, and then digitizes the result, (usually with a 12-14 bit AD 
>> converter). Since 1000x is ~10 bits, the result of overlapping tranmissions 
>> can be one signal at 14 bits, and another at <4 bits. This is why digital 
>> processing isn't able to receive multiple stations at the same time.
>
>      But, I you add 10 Bits to your AD converter you basically solved this. 
> Now, most likely this also needs to be of higher quality and of low internal 
> noise, so probably expensive... Add to this the wide-band requirement of the 
> sample the full band approach and we are looking at a price ad converter. On 
> the bright side, mass-producing that might lower the price for nice 
> oscilloscopes...

well, TI only manufactures AD converters up to 16 bit at these speeds, so 24 bit 
converters are hardly something to just buy. They do make 24 and 32 bit ADCs, 
but only ones that could be used for signals <5MHz wide (and we are pushing to 
160 MHz wide channels on wifi)

also note my comment about walls/etc providing shielding that can add a few more 
orders of magnatude on the signals.

And then when you start being able to detect signals at that level, the first 
ones you are going to hit are bounces from your strongest signal off of all 
sorts of things.

You will also find that noise and distortion in the legitimate strong signal is 
going to be at strengths close to the strength of the weak signal you are trying 
to hear.

As I said, I see things getting better, but it's going to be a very hard thing 
to do, and I'd expect to see reverse mu-mimo (similarly strong signals from 
several directions) long before the ability to detect wildly weaker signals.

I also expect that as the ability to more accurately digitize the signal grows, 
we will first take advantage of it for higher speeds.

David Lang

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[moeller0]

Hi David,

> On Jun 27, 2016, at 09:44 , David Lang <david@lang.hm> wrote:
> 
> On Mon, 27 Jun 2016, Sebastian Moeller wrote:
> 
>>> On a wireless network, with 'normal' omnidirctional antennas, the signal drops off with the square of the distance. So if you want to service clients from 1 ft to 100 ft away, your signal strength varies by 1000 (4 orders of magnatude), this is before you include effects of shielding, bounces, bad antenna alignment, etc (which can add several more orders of magnatude of variation)
>>> 
>>> The receiver first normalized the strongest part of the signal to a constant value, and then digitizes the result, (usually with a 12-14 bit AD converter). Since 1000x is ~10 bits, the result of overlapping tranmissions can be one signal at 14 bits, and another at <4 bits. This is why digital processing isn't able to receive multiple stations at the same time.
>> 
>>     But, I you add 10 Bits to your AD converter you basically solved this. Now, most likely this also needs to be of higher quality and of low internal noise, so probably expensive... Add to this the wide-band requirement of the sample the full band approach and we are looking at a price ad converter. On the bright side, mass-producing that might lower the price for nice oscilloscopes...
> 
> well, TI only manufactures AD converters up to 16 bit at these speeds, so 24 bit converters are hardly something to just buy. They do make 24 and 32 bit ADCs, but only ones that could be used for signals <5MHz wide (and we are pushing to 160 MHz wide channels on wifi)

	But David’s idea was to sample the full 5GHz band simultaneously, so we would need something like a down-mixer and an ADC system with around 2GHz bandwidth (due to Nyquist), I believe multiplexing multiple slower ADC’s as done in better oscilloscopes might work, but that will not help reduce the price not solve the bit resolution question.

> 
> also note my comment about walls/etc providing shielding that can add a few more orders of magnatude on the signals.

	Well, yes, but in the end the normalizing amplifier really can be considered a range adjustor that makes up for the ADC’s lack of dynamik resolution. I would venture the guess not having to normalize might allow speed up the “wifi pre-amble” since one amplifier less to stabilize…

> 
> And then when you start being able to detect signals at that level, the first ones you are going to hit are bounces from your strongest signal off of all sorts of things.

	But that is independent of whether you sample to whole 5GHz range in one go or not? I would guess as long as the ADC/amplifier does not go into saturation both should perform similarly.

> 
> You will also find that noise and distortion in the legitimate strong signal is going to be at strengths close to the strength of the weak signal you are trying to hear.

	But if that noise and distortion appear in the weak signals frequency band we have issues already today?

> 
> As I said, I see things getting better, but it’s going to be a very hard thing to do, and I'd expect to see reverse mu-mimo (similarly strong signals from several directions) long before the ability to detect wildly weaker signals.

	You are probably right.

> 
> I also expect that as the ability to more accurately digitize the signal grows, we will first take advantage of it for higher speeds.

	Yes, but higher speed currently means mostly wider bands, and the full 4-5GHz range is sort of the logical end-point ;).

Best Regards
	Sebastian

> 
> David Lang

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[Jason Abele]

On Mon, Jun 27, 2016 at 2:43 AM, moeller0 <moeller0@gmx.de> wrote:
> Hi David,
>
>> On Jun 27, 2016, at 09:44 , David Lang <david@lang.hm> wrote:
>>
>> On Mon, 27 Jun 2016, Sebastian Moeller wrote:
>>
>>>> On a wireless network, with 'normal' omnidirctional antennas, the signal drops off with the square of the distance. So if you want to service clients from 1 ft to 100 ft away, your signal strength varies by 1000 (4 orders of magnatude), this is before you include effects of shielding, bounces, bad antenna alignment, etc (which can add several more orders of magnatude of variation)
>>>>
>>>> The receiver first normalized the strongest part of the signal to a constant value, and then digitizes the result, (usually with a 12-14 bit AD converter). Since 1000x is ~10 bits, the result of overlapping tranmissions can be one signal at 14 bits, and another at <4 bits. This is why digital processing isn't able to receive multiple stations at the same time.
>>>
>>>     But, I you add 10 Bits to your AD converter you basically solved this. Now, most likely this also needs to be of higher quality and of low internal noise, so probably expensive... Add to this the wide-band requirement of the sample the full band approach and we are looking at a price ad converter. On the bright side, mass-producing that might lower the price for nice oscilloscopes...
>>
>> well, TI only manufactures AD converters up to 16 bit at these speeds, so 24 bit converters are hardly something to just buy. They do make 24 and 32 bit ADCs, but only ones that could be used for signals <5MHz wide (and we are pushing to 160 MHz wide channels on wifi)
>
>         But David’s idea was to sample the full 5GHz band simultaneously, so we would need something like a down-mixer and an ADC system with around 2GHz bandwidth (due to Nyquist), I believe multiplexing multiple slower ADC’s as done in better oscilloscopes might work, but that will not help reduce the price not solve the bit resolution question.
>

The reason you can not just add bits to the ADC is the thermal noise
floor: https://en.wikipedia.org/wiki/Johnson%E2%80%93Nyquist_noise#Noise_power_in_decibels

If you assume a maximum transmit power of ~20dBm (100mW) and a 160MHz
channel bandwidth (with a consequent thermal noise floor of -92 dBm),
the total possible dynamic range is ~112dB, if you receiver and
transmitter a coupled with no loss.  At ~6dB/bit in the ADC, anything
beyond 19bits is just quantizing noise and wasting power (which is
heat, which raises your local thermal noise floor, etc).  If your
channel bandwidth is 1GHz, the effective noise floor rises by another
~2bits, so ~17bits of dynamic range max, before accounting for path
loss and distortion.

Speaking of distortion, look at the intermod (IP3) or harmonic
distortion figures for those wideband ADC sometime, if the signals of
interest are of widely varying amplitudes in narrower bandwidths, the
performance limit will usually be distortion from the strongest
signal, not the thermal noise floor.  This usually limits dynamic
range to less than 10 effective bits.

Also transmitters are usually only required to suppress their adjacent
channel noise to around -50dB below the transmit power, so a little
over 8bits of dynamic range before the ADC is quantizing an interferer
rather than the signal of interest.

I am surprised that 802.11 still uses the same spreading code for all
stations.  I am no expert on cellular CDMA deployments, but I think
they have been using different spreading codes for each station to
increase capacity and improve the ability to mathematically remove the
interference of other physically close stations for decades.  As
complex as the 802.11 MAC is becoming, I do not understand why an
approach like MU-MIMO was chosen over negotiating a separate spreading
code per station.

My best guess is that it keeps the complexity (and therefore power) at
the AP rather than in the (increasingly mobile, power-constrained)
station.  Hopefully the rise of mesh / peer-to-peer networks in mobile
stations will apply the right engineering pressure to re-think the
idea of keeping all complexity in the AP.

Cheers,
Jason

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[David Lang]

On Mon, 27 Jun 2016, Jason Abele wrote:

> The reason you can not just add bits to the ADC is the thermal noise
> floor: https://en.wikipedia.org/wiki/Johnson%E2%80%93Nyquist_noise#Noise_power_in_decibels
>
> If you assume a maximum transmit power of ~20dBm (100mW) and a 160MHz
> channel bandwidth (with a consequent thermal noise floor of -92 dBm),
> the total possible dynamic range is ~112dB, if you receiver and
> transmitter a coupled with no loss.  At ~6dB/bit in the ADC, anything
> beyond 19bits is just quantizing noise and wasting power (which is
> heat, which raises your local thermal noise floor, etc).  If your
> channel bandwidth is 1GHz, the effective noise floor rises by another
> ~2bits, so ~17bits of dynamic range max, before accounting for path
> loss and distortion.
>
> Speaking of distortion, look at the intermod (IP3) or harmonic
> distortion figures for those wideband ADC sometime, if the signals of
> interest are of widely varying amplitudes in narrower bandwidths, the
> performance limit will usually be distortion from the strongest
> signal, not the thermal noise floor.  This usually limits dynamic
> range to less than 10 effective bits.
>
> Also transmitters are usually only required to suppress their adjacent
> channel noise to around -50dB below the transmit power, so a little
> over 8bits of dynamic range before the ADC is quantizing an interferer
> rather than the signal of interest.

Thanks for the more detailed information.

> I am surprised that 802.11 still uses the same spreading code for all
> stations.  I am no expert on cellular CDMA deployments, but I think
> they have been using different spreading codes for each station to
> increase capacity and improve the ability to mathematically remove the
> interference of other physically close stations for decades.

Cellular mostly works because they have hundreds/thousands of channels rather 
than tens.

> As complex as the 802.11 MAC is becoming, I do not understand why an approach 
> like MU-MIMO was chosen over negotiating a separate spreading code per 
> station.

compatibility and the fact that stations with different spreading algorithms 
still interfere with each other. Also, coordinating the 'right' spreading 
algorithm for each station with each AP (including ones with hidden SSIDs)

> My best guess is that it keeps the complexity (and therefore power) at
> the AP rather than in the (increasingly mobile, power-constrained)
> station.  Hopefully the rise of mesh / peer-to-peer networks in mobile
> stations will apply the right engineering pressure to re-think the
> idea of keeping all complexity in the AP.

Almost all the mesh work I see is using a mesh of APs, anything beyond that is 
wishful thinking.

Even mu-mimo requires some client support.

David Lang

Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 5102 bytes --]

On Mon, 27 Jun 2016, moeller0 wrote:

> Hi David,
>
>> On Jun 27, 2016, at 09:44 , David Lang <david@lang.hm> wrote:
>>
>> On Mon, 27 Jun 2016, Sebastian Moeller wrote:
>>
>>>> On a wireless network, with 'normal' omnidirctional antennas, the signal drops off with the square of the distance. So if you want to service clients from 1 ft to 100 ft away, your signal strength varies by 1000 (4 orders of magnatude), this is before you include effects of shielding, bounces, bad antenna alignment, etc (which can add several more orders of magnatude of variation)
>>>>
>>>> The receiver first normalized the strongest part of the signal to a constant value, and then digitizes the result, (usually with a 12-14 bit AD converter). Since 1000x is ~10 bits, the result of overlapping tranmissions can be one signal at 14 bits, and another at <4 bits. This is why digital processing isn't able to receive multiple stations at the same time.
>>>
>>>     But, I you add 10 Bits to your AD converter you basically solved this. Now, most likely this also needs to be of higher quality and of low internal noise, so probably expensive... Add to this the wide-band requirement of the sample the full band approach and we are looking at a price ad converter. On the bright side, mass-producing that might lower the price for nice oscilloscopes...
>>
>> well, TI only manufactures AD converters up to 16 bit at these speeds, so 24 bit converters are hardly something to just buy. They do make 24 and 32 bit ADCs, but only ones that could be used for signals <5MHz wide (and we are pushing to 160 MHz wide channels on wifi)
>
> 	But David’s idea was to sample the full 5GHz band simultaneously, so we 
> would need something like a down-mixer and an ADC system with around 2GHz 
> bandwidth (due to Nyquist), I believe multiplexing multiple slower ADC’s as 
> done in better oscilloscopes might work, but that will not help reduce the 
> price not solve the bit resolution question.

loosing track of the Davids here :-)

it's not just the super high-speed, high precision ADCs needed, it's also the 
filters to block out the other stuff that you don't want.

If you want to filter a 1 GHz chunk of bandwidth, you need to try and filer out 
signals outside of that 1GHz range. The wider the range that you receive, the 
harder it is to end up with filters that block the stuff outside of it. A strong 
signal outside of the band that you are trying to receive, but that partially 
makes it through the filter is as harmful to your range as a strong signal in 
band.

>> also note my comment about walls/etc providing shielding that can add a few 
>> more orders of magnatude on the signals.
>
> 	Well, yes, but in the end the normalizing amplifier really can be 
> considered a range adjustor that makes up for the ADC’s lack of dynamik 
> resolution. I would venture the guess not having to normalize might allow 
> speed up the “wifi pre-amble” since one amplifier less to stabilize…

not really, you are still going to have to amplify the signal a LOT before you 
can process it at all, and legacy compatibility wouldn't let you trim the 
beginning of the signal anyway.

>> And then when you start being able to detect signals at that level, the first 
>> ones you are going to hit are bounces from your strongest signal off of all 
>> sorts of things.
>
> 	But that is independent of whether you sample to whole 5GHz range in one 
> go or not? I would guess as long as the ADC/amplifier does not go into 
> saturation both should perform similarly.

if you currently require 8 bits of clean data to handle the data rate (out of 14 
bits sampled) and you move to needing 16 bits of clean data to handle the 
improved data rate out of 24 bits sampled, you haven't gained much ability to 
handle secondary, weak signals

>> You will also find that noise and distortion in the legitimate strong signal 
>> is going to be at strengths close to the strength of the weak signal you are 
>> trying to hear.
>
> 	But if that noise and distortion appear in the weak signals frequency 
> band we have issues already today?

no, because we aren't trying to decode the weak signal at the same time the 
strong signal is there. We only try to decode the weak signal in the absense of 
the strong signal.

>> As I said, I see things getting better, but it’s going to be a very hard 
>> thing to do, and I'd expect to see reverse mu-mimo (similarly strong signals 
>> from several directions) long before the ability to detect wildly weaker 
>> signals.
>
> 	You are probably right.
>
>>
>> I also expect that as the ability to more accurately digitize the signal 
>> grows, we will first take advantage of it for higher speeds.
>
> 	Yes, but higher speed currently means mostly wider bands, and the full 
> 4-5GHz range is sort of the logical end-point ;).

not at all. There is nothing magical about round decimal numbers :-)

And there are other users nearby. As systems get able to handle faster signals, 
we will move up in frequency (say the 10GHz band where police radar guns 
operate) or higher.

David Lang