From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 9E2ED3B2B3 for ; Sun, 26 Jun 2016 22:23:20 -0400 (EDT) Received: by mail-wm0-x235.google.com with SMTP id a66so94915483wme.0 for ; Sun, 26 Jun 2016 19:23:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadcom.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Rh/W5ilq9l2SQK6s1M39ydYsJB+X1P98elasasSUbKM=; b=Ig+aBhG78myy5VfHEus/Zizo6U3qPNQisQTCRDPIRZF/HBw3BszBFxKyaSKneZOSn8 /BmslWRfBGi3+69j5ErZd93SdMc8odmqVvgrGBDYF2RnF+bLmvey3tjASGa4rsge/jx1 ZtDS+MBiloPdkezQBcYAHYNwFqJiwOSaSgxSM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Rh/W5ilq9l2SQK6s1M39ydYsJB+X1P98elasasSUbKM=; b=IaYdJXKu0SGhZ3rNZXTV8p48CsH5uapDKW6LECZKsSaaFNdbTfCekQICP9Mzr0qZJJ IKvz7csSXjyshFU/ns70p7i0EK3KYRN9+WQ6o0ijpTG81btUOP8ByQjAQhTPM/CYEr6C Kg9RS4Qme/K+VKTEw+1WCy4vyMF86MP+OcWGFhnxU466jCm+lvXYESe1DHzW0Muf7ZWy NtfwKELDTnc2zCVkHEEOg/YLjg0uBuQ67anbtu+/QN9lZQcgd1NwPhTYbIr0wSz+ZQpS RKLDrwGGHrlv1Z82ZNrEWfklRrrjmQKCW0kgBYtHc/e+sM/QdcHtO1B4PXqQhrd3ZVO8 YdBg== X-Gm-Message-State: ALyK8tKLqJBcrotF1DBrFmDGwscLJIqRn+T+EuIuejj54ww9hA3nG6xv5bjSQNamkLNWKr8V8bRmOmmam3PZ6Qr6 X-Received: by 10.194.113.104 with SMTP id ix8mr14809845wjb.2.1466994199197; Sun, 26 Jun 2016 19:23:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.239.202 with HTTP; Sun, 26 Jun 2016 19:23:17 -0700 (PDT) In-Reply-To: References: <1466803464.927322699@mobile.rackspace.com> From: Bob McMahon Date: Sun, 26 Jun 2016 19:23:17 -0700 Message-ID: To: David Lang Cc: David Reed , make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" Content-Type: multipart/alternative; boundary=001a1130d1822231530536393411 Subject: Re: [Make-wifi-fast] more well funded attempts showing market demandfor better wifi X-BeenThere: make-wifi-fast@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 02:23:21 -0000 --001a1130d1822231530536393411 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 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 differen= ce > of 2x would be extreme) > > On a wireless network, with 'normal' omnidirctional antennas, the signa= l > 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 tranmissio= ns > 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, an= d > 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 wel= l > (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 t= o > 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 th= e > 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 station= s > will not be able to understand the newest rates, each transmission starts > off with some data being transmitted at the slowest available rate, telli= ng > 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 packe= t > at a time. This is something Linux is currently not doing well, qdiscs te= nd > to round-robin packets without regard to where they are headed. The curre= nt > 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 successf= ul > 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 al= so >> 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 i= s >> 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 goa= ls >> >> 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) drive= n >> to zero >> o) Support of different encodings (e..g phy rates) pushes towards virtu= al >> output queueing prior (queuing at the transmitter) >> o) Power per bit xfered towards zero or driven per cost & energy densit= y >> 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 ze= ro >> >> Just some thoughts off the top of my head. Please do comment and correc= t. >> Thanks in advance for the discussion. >> >> Bob >> >> >> >> >> On Fri, Jun 24, 2016 at 2:24 PM, 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 ar= e >>> 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" >>> Sent: Fri, Jun 24, 2016 at 1:19 am >>> To: "Bob McMahon" >>> Cc: "Bob McMahon" , >>> make-wifi-fast@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 sam= e) >>> >>> 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 tru= e. >>>>> >>>>> >>>>> 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 specif= ic >>>>>> power numbers here? We test with many combinations of "signal streng= th >>>>>> 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 physi= cs >>>>>> 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 mu= ch >>>>>>> >>>>>> 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 A= P >>>>>>> >>>>>> 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 yo= u >>>>>>>>> >>>>>>>> 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 ju= st >>>>>>>> >>>>>>>>> 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-wif= i?ref=3Dbackerkit >>> >>>> >>>>>>> >>>>>>>> >>>>>>>>>>> "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 acce= ss >>>>>>>>>>>> >>>>>>>>>>> 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-wif= i/comments >>> >>>> >>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> >>>>>>>>>>>> Dave T=C3=A4ht >>>>>>>>>>>> Let's go make home routers and wifi faster! With better >>>>>>>>>>>> software! >>>>>>>>>>>> http://blog.cerowrt.org >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Dave T=C3=A4ht >>>>>>>>>>> Let's go make home routers and wifi faster! With better softwar= e! >>>>>>>>>>> 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 >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> >>> >>> --001a1130d1822231530536393411 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I appreciate and agree with what you posted, includin= g that a wired network without guides is not the same as a guide-less mobil= e network.=C2=A0 I do think the thought experiment can help set some goal p= osts and, where the goalposts don't make sense, some can be thrown out.= =C2=A0 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? =C2=A0 Did a mathematician discover some new math or d= id a physicist =C2=A0find a better way to explain energy as a means for mov= ing information?" =C2=A0Superposition 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 i= nto products useful to humans.=C2=A0 I suspect the future of wi-fi is more = of the same - hence the desire to set some engineering goal posts.=C2=A0=C2= =A0

So to your points (and in the thought experime= nt context:)

1) Drastic variation in signal streng= th.=C2=A0 Reality of physics?=C2=A0 Seems yes.=C2=A0 Solvable by math?=C2= =A0 I suspect so but could be wrong.=C2=A0 Solvable by engineering now? Not= sure.=C2=A0 In ten years?=C2=A0 Not sure.
2) Hidden transmitters= .=C2=A0 Does it really matter? =C2=A0 Superposition applies hidden or not s= o 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.)=C2=A0
= =C2=A0 =C2=A0 b) Aggregation: =C2=A0Artifact of media access latency that m= akes the transport network incredibly difficult for things like TCP.=C2=A0 = Possibly another eng. design flaw.

Trying to learn= from experts so thanks again for including me in these discussions.
<= div>
Bob

On Sun, Jun 26, 2016 at 5:00 PM, David Lang <david@lang.= hm> wrote:
I don't thin= k anyone is trying to do simultanious receive of different stations. That i= s 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 th= an the traffic from the stations to the AP. As such, it is worth focusing o= n optimizing this direction.

While an ideal network may resemble a wired network without guides, I don&#= 39;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 networ= ks.

1. drastic variations in signal strength.

=C2=A0 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)

=C2=A0 On a wireless network, with 'normal' omnidirctional antennas= , the signal drops off with the square of the distance. So if you want to s= ervice clients from 1 ft to 100 ft away, your signal strength varies by 100= 0 (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)

=C2=A0 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 tranmission= s can be one signal at 14 bits, and another at <4 bits. This is why digi= tal processing isn't able to receive multiple stations at the same time= .

2. 'hidden transmitters'

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

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

=C2=A0 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 t= his by having some central system coordinate all the clients (either by the= m 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 amou= nt of data to transmit)

3. variable transmit rates and aggregation

=C2=A0 Depending on how strong the signal is between two stations, you have= different limits to how fast you can transmit data. There are many differe= nt 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 probabilit= y that another station will step on your signal, scrambling it as far as th= e 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)

=C2=A0 Because there is so much variation in transmit rates, and older stat= ions will not be able to understand the newest rates, each transmission sta= rts off with some data being transmitted at the slowest available rate, tel= ling any stations that are listening that there is data being transmitted f= or X amount of time, even if they can't tell what's going on as the= data is being transmitted.

=C2=A0 The combination of this header being transmitted inefficiently, and = the fact that stations are waiting for a clear window to transmit, means th= at when you do get a chance to transmit, you should send more than one pack= et at a time. This is something Linux is currently not doing well, qdiscs t= end to round-robin packets without regard to where they are headed. The cur= rent 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. Th= e 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 wh= ith 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?=C2=A0 This seems an AP tx centric proposa= l,
though I may not be fully understanding it.=C2=A0 I'm also curious as w= hy not
scale in spatial domain vs the frequency domain, i.e. AP and STAs can also<= br> scale using MiMO.=C2=A0 Why not just do that? So many phones today are 1x1,= some
2x2 and few 3x3.=C2=A0 =C2=A0Yet APs are moving to 4x4 and I think the stan= dard
supports 8x8.=C2=A0 (I'm not sure the marginal transistor count increas= e per
each approach.)=C2=A0 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 re= ceive is
the most difficult issue per the power variations, aka SNR.=C2=A0 Each of t= he
mobile device energies is affected per inverse square law (unless some form=
of wave guide is used.)=C2=A0 Hence wi-fi use of time domain slots prior to=
transmit (no longer simultaneous in time.)=C2=A0 Particularly needed for de= vices
that communicate with one another.=C2=A0 Unfortunately, "collocated&qu= ot;
energy/information sources must honor this TDM=C2=A0 even when not communic= ation
with one another per tragedy of the commons.=C2=A0 (Agreed there is no such=
thing as a collision so let's redefine it to mean that the receiver is<= br> unable to receive per RF energy "confusion", still a tragedy of t= he
commons.=C2=A0 I don't know what drives the limits to DSP decode that c= ould
minimize or eliminate=C2=A0 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)?=C2=A0 From that perspective, here are some thoughts to the g= oals

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

Just some thoughts off the top of my head.=C2=A0 Please do comment and corr= ect.
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 transmiss= ion
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<= br> 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>,
m= ake-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloa= t.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 sam= e)

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,
=C2=A0 =C2=A0 "cerowrt-devel@lists.bufferbloat.net"

Subject: Re: [Make-wifi-fast] more well funded attempts showing market
demand
=C2=A0 =C2=A0 for better wifi

Thanks for the clarification.=C2=A0 =C2=A0Though 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=C2=A0 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]<= br>
signal strength is likely small enough" assertion come?=C2=A0 =C2=A0An= y specific
power numbers here? We test with many combinations of "signal strength=
variability" (e.g. deltas range from 0 dBm -=C2=A0 50 dBm) and per dif= ferent
channel conditions.=C2=A0 This includes power variability within the spatia= l
streams' MiMO transmission.=C2=A0 =C2=A0It would be helpful to have som= e 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.)=C2=A0 Power per bit usually trumps most other
design
goals.=C2=A0 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,=C2=A0 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.=C2=A0 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@b= roadcom.com>
said:

_______________________________________________
Make-wifi-fast mailing list
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast
An AP per room/area, reducing the tx power (beacon range) has been my
approach and has scaled very well.=C2=A0 =C2=A0It does require some wires t= o
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=C2=A0 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,
=C2=A0 =C2=A0 "cerowrt-devel@lists.bufferbloat.net"

Subject: Re: [Make-wifi-fast] more well funded attempts showing
market
demand
=C2=A0 =C2=A0 for better wifi


hmm, I'm skeptical.=C2=A0 =C2=A0To use multiple carriers simultaneously= is

difficult

per RF issues.=C2=A0 =C2=A0Even 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.=C2=A0 If this is just<= br>
channel hopping, that needs coordination between both sides (and
isn't
simultaneous, possibly costing more than any potential gain.)=C2=A0 =C2=A0A= n
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.=C2=A0 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=3Dbackerki= t



"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.kicksta= rter.com/projects/portalwifi/portal-turbocharged-wifi/comments
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">




--
Dave T=C3=A4ht
Let's go make home routers and wifi faster! With better software!
ht= tp://blog.cerowrt.org




--
Dave T=C3=A4ht
Let's go make home routers and wifi faster! With better software!
ht= tp://blog.cerowrt.org
_______________________________________________
Make-wifi-fast mailing list
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast


_______________________________________________
Make-wifi-fast mailing list
M= ake-wifi-fast@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/make-wif= i-fast











--001a1130d1822231530536393411--