From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bifrost.lang.hm (mail.lang.hm [64.81.33.126]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id B39FD201240; Fri, 29 May 2015 13:26:18 -0700 (PDT) Received: from asgard.lang.hm (asgard.lang.hm [10.0.0.100]) by bifrost.lang.hm (8.13.4/8.13.4/Debian-3) with ESMTP id t4TKQ0XE031338; Fri, 29 May 2015 13:26:00 -0700 Date: Fri, 29 May 2015 13:26:00 -0700 (PDT) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Pedro Tumusok In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: cerowrt-devel , bloat Subject: Re: [Cerowrt-devel] [Bloat] sqm-scripts on WRT1900AC X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 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: Fri, 29 May 2015 20:27:00 -0000 I'm not sure what the difference bwtwen mimo and mu-mimo is, pointer please? David Lang On Fri, 29 May 2015, Pedro Tumusok wrote: > 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 >>>> >>>> >>>> >>> >>> >>> > > >