From my understanding you need an AP that supports mu-mimo and then you have different scenarios of of how to support clients. If the client supports mu-mimo then you get the "full" mi-mimo experience. If the client does not support it, you do not get the "full" mu-mimo experience for that or those clients. Example if you got an 8x8 mu-mimo ap, then you can for instance use 4 of those 8 for a mu-mimo setup and the last 4 can be used for 4 groups of single stream connections or one 3x3 and 1x1. And probably many more combinations like that. But I might be way off on this, do not have any wave 2 products to play with yet. Pedro On Fri, May 29, 2015 at 11:09 AM, David Lang wrote: > Ok, I think I'm understanding that unless the client is mimo enabled, mimo > on the the AP doesn't do any good. I'm focused on the high density > conference type setup and was wondering if going to these models would > result in any mor effective airtime. It sounds like the answer is no. > > David Lang > > > On Fri, 29 May 2015, Pedro Tumusok wrote: > > Is the 1900AC MU-Mimo? If not then its still normal Airtime limitations, >> unless you consider concurrent 2x2 2.4GHz and 3x3 5GHz as a MU setup. >> Also there are very few devices with builtin 3x3 ac client. From the top >> of my head I can not think of one. >> >> Pedro >> >> On Tue, May 26, 2015 at 1:55 AM, David Lang wrote: >> >> looking at the 1900ac vs the 1200ac, one question. what is needed to >>> benefit from the 3x3 vs the 2x2? >>> >>> In theory the 3x3 can transmit to three clients at the same time while >>> the >>> 2x2 can transmit to two clients at the same time. >>> >>> But does the client need specific support for this? (mimo or -ac) Or will >>> this work for 802.11n clients as well? >>> >>> David Lang >>> >>> >>> On Sat, 23 May 2015, Aaron Wood wrote: >>> >>> Date: Sat, 23 May 2015 23:19:19 -0700 >>> >>>> From: Aaron Wood >>>> To: bloat , >>>> cerowrt-devel , >>>> Dave Taht >>>> Subject: Re: [Bloat] sqm-scripts on WRT1900AC >>>> >>>> >>>> After more tweaking, and after Comcast's network settled down some, I >>>> have >>>> some rather quite nice results: >>>> >>>> >>>> >>>> http://burntchrome.blogspot.com/2015/05/sqm-scripts-on-linksys-wrt1900ac-part-1.html >>>> >>>> >>>> >>>> So it looks like the WRT1900AC is a definite contender for our faster >>>> cable >>>> services. I'm not sure if it will hold out to the 300Mbps that you >>>> want, >>>> Dave, but it's got plenty for what Comcast is selling right now. >>>> >>>> -Aaron >>>> >>>> P.S. Broken wifi to the MacBook was a MacBook issue, not a router issue >>>> (sorted itself out after I put the laptop into monitor mode to capture >>>> packets). >>>> >>>> On Sat, May 23, 2015 at 10:17 PM, Aaron Wood wrote: >>>> >>>> All, >>>> >>>>> >>>>> I've been lurking on the OpenWRT forum, looking to see when the CC >>>>> builds >>>>> for the WRT1900AC stabilized, and they seem to be so (for a very >>>>> "beta"-ish >>>>> version of stable). >>>>> >>>>> So I went ahead and loaded up the daily ( CHAOS CALMER (Bleeding Edge, >>>>> r45715)). >>>>> >>>>> After getting Luci and sqm-scripts installed, I did a few baseline >>>>> tests. >>>>> Wifi to the MacBook Pro is... broken. 30Mbps vs. 90+ on the stock >>>>> firmware. iPhone is fine (80-90Mbps download speed from the internet). >>>>> >>>>> After some rrul runs, this is what I ended up with: >>>>> http://www.dslreports.com/speedtest/538967 >>>>> >>>>> sqm-scripts are set for: >>>>> 100Mbps download >>>>> 10Mbps upload >>>>> fq_codel >>>>> ECN >>>>> no-squash >>>>> don't ignore >>>>> >>>>> Here's a before run, with the stock firmware: >>>>> http://www.dslreports.com/speedtest/337392 >>>>> >>>>> So, unfortunately, it's still leaving 50Mbps on the table. >>>>> >>>>> However, if I set the ingress limit higher (130Mbps), buffering is >>>>> still >>>>> controlled. Not as well, though. from +5ms to +10ms, with lots of >>>>> jitter. But it still looks great to the dslreports test: >>>>> http://www.dslreports.com/speedtest/538990 >>>>> >>>>> But the upside? load is practically nil. The WRT1900AC, with it's >>>>> dual-core processor is more than enough to keep up with this (from a >>>>> load >>>>> point of view), but it seems like the bottleneck isn't the raw CPU >>>>> power >>>>> (cache?). >>>>> >>>>> I'll get a writeup with graphs on the blog tomorrow (I hope). >>>>> >>>>> -Aaron >>>>> >>>>> >>>>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >>> >>> _______________________________________________ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >>> >>> >>> >> >> >> -- Best regards / Mvh Jan Pedro Tumusok