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

Sebastian Moeller moeller0 at gmx.de
Mon Jun 27 02:34:26 EDT 2016 

Hi Dave, 

On June 27, 2016 2:00:55 AM GMT+02:00, David Lang <david at 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 at 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 at lang.hm>
>>> Sent: Fri, Jun 24, 2016 at 1:19 am
>>> To: "Bob McMahon" <bob.mcmahon at broadcom.com>
>>> Cc: "Bob McMahon" <bob.mcmahon at broadcom.com>,
>>> make-wifi-fast at lists.bufferbloat.net,
>"cerowrt-devel at lists.bufferbloat.net"
>>> <cerowrt-devel at 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 at reed.com, make-wifi-fast at lists.bufferbloat.net,
>>>>     "cerowrt-devel at 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 at broadcom.com>
>>>>>>> said:
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>>> Make-wifi-fast mailing list
>>>>>>>> Make-wifi-fast at 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 at lists.bufferbloat.net,
>>>>>>>>>>     "cerowrt-devel at 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 at lists.bufferbloat.net
>>>>>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>> Make-wifi-fast mailing list
>>>>>>>>> Make-wifi-fast at lists.bufferbloat.net
>>>>>>>>> https://lists.bufferbloat.net/listinfo/make-wifi-fast
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>
>>>
>>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Cerowrt-devel mailing list
>Cerowrt-devel at lists.bufferbloat.net
>https://lists.bufferbloat.net/listinfo/cerowrt-devel

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

More information about the Cerowrt-devel mailing list