From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 97E9D3B2B3; Mon, 27 Jun 2016 02:34:57 -0400 (EDT) Received: from [10.39.190.42] ([80.187.110.104]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LyWAQ-1bNJwz04By-015pyz; Mon, 27 Jun 2016 08:34:41 +0200 User-Agent: K-9 Mail for Android In-Reply-To: References: <1466803464.927322699@mobile.rackspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Sebastian Moeller Date: Mon, 27 Jun 2016 08:34:26 +0200 To: David Lang , Bob McMahon , David Lang , Bob McMahon CC: make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" , make-wifi-fast@lists.bufferbloat.net, "cerowrt-devel@lists.bufferbloat.net" Message-ID: <2D664EFF-A25C-46FA-A8F9-46CD7B8C2ECE@gmx.de> X-Provags-ID: V03:K0:XiH8PCIdfKKWKt3jaJbSMpYAlHQMz46JuojyJ070O5wqOF5ISqL Gem6UdhUGEEubTaZA4kkJOet2nU3TLfFE03zFw94iO/eSXMcJdDNlBJMayRU8leL5JCM3ft fpvY6EtSpk/E5nPi0z+gQc9cukqNFIl0nwsRW/CV7nzRG8VcfufSXgJW0yqjOmK0Q0hb3Vy GppEZ6pi4jL9Tmg1PVObg== X-UI-Out-Filterresults: notjunk:1;V01:K0:tBW+beFqsvI=:83Jn7x5fSXYtTRFx+qOdO2 UnR84c4fotoC6q5PtfdOFXYncLagW9iAot20lSBFFfThk6fD9LJ6wzyM5u/HyG7on9RIXuhOx xJvXtdFdEe1TbU7D4zStMyp4DpUa7Ek5ol5nSg8CGoch6ZapEy0W+QcUVYyq9dqYWADYsMeAJ 9c5delMHxdL3eVwiVjBHlz3k2nzgotalA6fMvf0LvghIuNe2+z7CUgRUl8gVhu5N7XJQD/Tq3 ko960PbCkP0TSRcwznWIPIH4bItF4T6eMaPeYos3ZZ8dxwMP/XCqm6WlvGzbPq/tBRO4WozlB MHPDnyQ9GWkFN67twICIZ+r+vCSbvLWMAP3soFoAzgYHAnon54DOv2QzCvOTMq1JCzefxoluU bbCvGu3ZtbOVGcE6YtLOX83lIE6Rnwix9xh/4xCqGX5sriWgQVL9i/+IzjJRaeFg+Y0Pszpee DGRcUqbMc3HZD7s1Rf7A4oGgnJgyVtL2Ay6NZ2ZtAMZhgQpzXMg+RxNnGc+eqj9FZmww8CzyM Dswhhpdg66zoirxxheJc53eKXO4SkvdNjVNqepKOc4PG8A4Cgd1TV2ESDv0fo2ESsKp35gInm BcmxtQjD9SwJxwYw3MjzMdbd0aFGsinVziuqEDbob1ZudG7YHgyyZTO/PHBtwex2amN+EFv8r JjEsu4DYwQVuKoznumyZQKUK7h9zyczvKBy3XTyL+DZfYcnlkuG8e3j9kR3kx+5TfisBnNsxU dZc0u+9zczPL0Dsuvf/9QDA6kSmS5AfUnzUERTlDyHVYZ//UL4Np7FzbJgmWcJLaCQDfW9WRS N8/VtOCuGntEaOsAGC21/mvlmApiA== Subject: Re: [Cerowrt-devel] [Make-wifi-fast] more well funded attempts showing market demandfor better wifi X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 06:34:57 -0000 Hi Dave,=20 On June 27, 2016 2:00:55 AM GMT+02:00, David Lang wrote: >I don't think anyone is trying to do simultanious receive of different >stations=2E=20 >That is an incredibly difficult thing to do right=2E > >MU-MIMO is aimed at haivng the AP transmit to multiple stations at the >same=20 >time=2E For the typical browser/streaming use, this traffic is FAR larger >than the=20 >traffic from the stations to the AP=2E As such, it is worth focusing on >optimizing=20 >this direction=2E > >While an ideal network may resemble a wired network without guides, I >don't=20 >think it's a good idea to think about wifi networks that way=2E > >The reality is that no matter how good you get, a wireless network is >going to=20 >have lots of things that are just not going to happen with wired >networks=2E > >1=2E drastic variations in signal strength=2E > >On a wired network with a shared buss, the signal strength from all >stations=20 >on the network is going to be very close to the same (a difference of >2x would=20 >be extreme) > >On a wireless network, with 'normal' omnidirctional antennas, the >signal drops=20 >off with the square of the distance=2E So if you want to service clients >from 1 ft=20 >to 100 ft away, your signal strength varies by 1000 (4 orders of >magnatude),=20 >this is before you include effects of shielding, bounces, bad antenna >alignment,=20 >etc (which can add several more orders of magnatude of variation) > >The receiver first normalized the strongest part of the signal to a >constant=20 >value, and then digitizes the result, (usually with a 12-14 bit AD >converter)=2E=20 >Since 1000x is ~10 bits, the result of overlapping tranmissions can be >one=20 >signal at 14 bits, and another at <4 bits=2E This is why digital >processing isn't=20 >able to receive multiple stations at the same time=2E But, I you add 10 Bits to your AD converter you basically solved thi= s=2E Now, most likely this also needs to be of higher quality and of low in= ternal noise, so probably expensive=2E=2E=2E Add to this the wide-band requ= irement of the sample the full band approach and we are looking at a price = ad converter=2E On the bright side, mass-producing that might lower the pri= ce for nice oscilloscopes=2E=2E=2E Best Regards Sebastian=20 > >2=2E 'hidden transmitters' > >On modern wired networks, every link has exactly two stations on it, >and both=20 >can transmit at the same time=2E > >On wireless networks, it's drastically different=2E You have an unknown >number=20 >of stations (which can come and go without notice)=2E > >Not every station can hear every other station=2E This means that they >can't=20 >avoid colliding with each other=2E In theory you can work around this by >having=20 >some central system coordinate all the clients (either by them being >told when=20 >to transmit, or by being given a schedule and having very precise >clocks)=2E But=20 >in practice the central system doesn't know when the clients have >something to=20 >say and so in practice this doesn't work as well (except for special >cases like=20 >voice where there is a constant amount of data to transmit) > >3=2E variable transmit rates and aggregation > >Depending on how strong the signal is between two stations, you have >different=20 >limits to how fast you can transmit data=2E There are many different >standard=20 >modulations that you can use, but if you use one that's too fast for >the signal=20 >conditions, the receiver isn't going to be able to decode it=2E If you >use one=20 >that's too slow, you increase the probability that another station will >step on=20 >your signal, scrambling it as far as the receiver is concerned=2E We now >have=20 >stations on the network that can vary in speed by 100x, and are nearing >1000x=20 >(1Mb/sec to 1Gb/sec) > >Because there is so much variation in transmit rates, and older >stations will=20 >not be able to understand the newest rates, each transmission starts >off with=20 >some data being transmitted at the slowest available rate, telling any >stations=20 >that are listening that there is data being transmitted for X amount of >time,=20 >even if they can't tell what's going on as the data is being >transmitted=2E > >The combination of this header being transmitted inefficiently, and the >fact=20 >that stations are waiting for a clear window to transmit, means that >when you do=20 >get a chance to transmit, you should send more than one packet at a >time=2E This=20 >is something Linux is currently not doing well, qdiscs tend to >round-robin=20 >packets without regard to where they are headed=2E The current work being >done=20 >here with the queues is improving both throughput and latency by fixing >this=20 >problem=2E > > >You really need to think differently when dealing with wireless >network=2E The=20 >early wifi drivers tried to make them look just like a wired network, >and we=20 >have found that we just needed too much other stuff to be successful >whith that=20 >mindset=2E > >The Analog/Radio side of things really is important, and can't just be=20 >abstracted away=2E > >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=2E I'm also curious as why >not >> scale in spatial domain vs the frequency domain, i=2Ee=2E AP and STAs c= an >also >> scale using MiMO=2E Why not just do that? So many phones today are >1x1, some >> 2x2 and few 3x3=2E Yet APs are moving to 4x4 and I think the standard >> supports 8x8=2E (I'm not sure the marginal transistor count increase >per >> each approach=2E) On the AP tx side, MuMIMO is also there which I >think is >> similar to the DAC proposal=2E >> >> 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=2E Each of >the >> mobile device energies is affected per inverse square law (unless >some form >> of wave guide is used=2E) Hence wi-fi use of time domain slots prior >to >> transmit (no longer simultaneous in time=2E) Particularly needed for >devices >> that communicate with one another=2E Unfortunately, "collocated" >> energy/information sources must honor this TDM even when not >communication >> with one another per tragedy of the commons=2E (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=2E I don't know what drives the limits to DSP decode that >could >> minimize or eliminate this tragedy=2E) >> >> 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=2E (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=2E=2Eg 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=2E Note: Atomic batteries not allowed per humans being >involved=2E >> 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=2E Please do comment and >correct=2E >> Thanks in advance for the discussion=2E >> >> 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=2E >>> >>> David Lang's explanation was the essence of what I meant=2E the >transmission >>> from access point on multiple channels is just digital addition if >the DACs >>> have enough bits per sample=2E to make sure that the signals to the AP >are >>> equalized, just transmit at a power that makes that approximately >true=2E=2E=2E >>> which means a power amp with at most 30 dB of dynamic gain setting=2E >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=2E-----Original Message----- >>> From: "David Lang" >>> Sent: Fri, Jun 24, 2016 at 1:19 am >>> To: "Bob McMahon" >>> Cc: "Bob McMahon" , >>> make-wifi-fast@lists=2Ebufferbloat=2Enet, >"cerowrt-devel@lists=2Ebufferbloat=2Enet" >>> >>> 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=2E >>> >>> 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=2Ecom, make-wifi-fast@lists=2Ebufferbloat=2Enet, >>>> "cerowrt-devel@lists=2Ebufferbloat=2Enet" >>>> >>>> Subject: Re: [Make-wifi-fast] more well funded attempts showing >market >>> demand >>>> for better wifi >>>> >>>> Thanks for the clarification=2E 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=2E) >>>> >>>> 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=2E Which is probably fairly >true=2E >>>>> >>>>> >>>>> 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=2Eg=2E deltas range from 0 dBm - 50 dBm) and per >different >>>>>> channel conditions=2E This includes power variability within the >spatial >>>>>> streams' MiMO transmission=2E It would be helpful to have some >physics >>>>>> combined with engineering to produce some pragmatic limits to >this=2E >>>>>> >>>>>> 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=2E) Power per bit usually trumps most other >>> design >>>>>> goals=2E There market for battery powered wi-fi devices drives a >>>>>> semi-conductor mfg's revenue so my information come with that >bias=2E >>>>>> >>>>>> 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)=2E >>> 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)=2E >>> No RF >>>>>>> problem=2E >>>>>>> >>>>>>> Receiving multiple transmissions in different channels is pretty >much >>> the >>>>>>> same problem - just digitize (ADC) a wider bandwidth and >separate in >>> the >>>>>>> digital domain=2E 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=2E >>>>>>> >>>>>>> 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=2E >>>>>>> >>>>>>> Equalization at transmit works very well when there is a central >AP >>> (as >>>>>>> in >>>>>>> cellular or normal WiFi systems)=2E >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Thursday, June 23, 2016 4:28pm, "Bob McMahon" >>> >>> bob=2Emcmahon@broadcom=2Ecom> >>>>>>> said: >>>>>>> >>>>>>> _______________________________________________ >>>>>>>> Make-wifi-fast mailing list >>>>>>>> Make-wifi-fast@lists=2Ebufferbloat=2Enet >>>>>>>> https://lists=2Ebufferbloat=2Enet/listinfo/make-wifi-fast >>>>>>>> An AP per room/area, reducing the tx power (beacon range) has >been my >>>>>>>> approach and has scaled very well=2E 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=2E >>>>>>>> >>>>>>>> just my $0=2E02, >>>>>>>> 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=2E If >everything is >>>>>>>>> within a good range of the AP, this would work pretty well=2E 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=2E >>>>>>>>> >>>>>>>>> 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=2Ebufferbloat=2Enet, >>>>>>>>>> "cerowrt-devel@lists=2Ebufferbloat=2Enet" >>>>>>>>>> >>>>>>>>>> Subject: Re: [Make-wifi-fast] more well funded attempts >showing >>> market >>>>>>>>>> demand >>>>>>>>>> for better wifi >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> hmm, I'm skeptical=2E To use multiple carriers simultaneously >is >>>>>>>>>> >>>>>>>>> difficult >>>>>>> >>>>>>>> per RF issues=2E Even if that is somehow resolved, to increase >>>>>>>>>> >>>>>>>>> throughput >>>>>>> >>>>>>>> usually requires some form of channel bonding, i=2Ee=2E needed on >both >>>>>>>>>> >>>>>>>>> sides, >>>>>>> >>>>>>>> and brings in issues with preserving frame ordering=2E If this >is just >>>>>>>>>> channel hopping, that needs coordination between both sides >(and >>> isn't >>>>>>>>>> simultaneous, possibly costing more than any potential gain=2E) > An >>> AP >>>>>>>>>> >>>>>>>>> only >>>>>>> >>>>>>>> solution can use channel switch announcements (CSA) but there >is a >>>>>>>>>> >>>>>>>>> cost to >>>>>>> >>>>>>>> those as well=2E >>>>>>>>>> >>>>>>>>>> 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=2E Always willing to learn and be corrected if I'm >>>>>>>>>> misunderstanding things=2E >>>>>>>>>> >>>>>>>>>> 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=2Ekickstarter=2Ecom/projects/portalwifi/portal-turbocharged-w= ifi?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=2E >>>>>>>>>>>> >>>>>>>>>>>> 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=2E >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> It's not clear what chipset they are using (they are >claiming >>> wave2) >>>>>>>>>>> - >>>>>>>>>>> but they are at least publicly claiming to be using openwrt=2E >So I >>>>>>>>>>> threw in enough to order one for september, just so I could >>> comment >>>>>>>>>>> on >>>>>>>>>>> their kickstarter page=2E :) >>>>>>>>>>> >>>>>>>>>>> I'd have loved to have got in earlier (early shipments are >this >>> month >>>>>>>>>>> apparently), but those were sold out=2E >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>> >>> >https://www=2Ekickstarter=2Ecom/projects/portalwifi/portal-turbocharged-w= ifi/comments >>>>>>> >>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>>> Dave T=C3=83=C2=A4ht >>>>>>>>>>>> Let's go make home routers and wifi faster! With better >software! >>>>>>>>>>>> http://blog=2Ecerowrt=2Eorg >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Dave T=C3=83=C2=A4ht >>>>>>>>>>> Let's go make home routers and wifi faster! With better >software! >>>>>>>>>>> http://blog=2Ecerowrt=2Eorg >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Make-wifi-fast mailing list >>>>>>>>>>> Make-wifi-fast@lists=2Ebufferbloat=2Enet >>>>>>>>>>> https://lists=2Ebufferbloat=2Enet/listinfo/make-wifi-fast >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>> Make-wifi-fast mailing list >>>>>>>>> Make-wifi-fast@lists=2Ebufferbloat=2Enet >>>>>>>>> https://lists=2Ebufferbloat=2Enet/listinfo/make-wifi-fast >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>> >>> >>> >> > >------------------------------------------------------------------------ > >_______________________________________________ >Cerowrt-devel mailing list >Cerowrt-devel@lists=2Ebufferbloat=2Enet >https://lists=2Ebufferbloat=2Enet/listinfo/cerowrt-devel --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E