Re: [Cerowrt-devel] [Bloat] sqm-scripts on WRT1900AC

[Pedro Tumusok <pedro.tumusok@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4953 bytes --]

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 <david@lang.hm> 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 <david@lang.hm> 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 <woody77@gmail.com>
>>>> To: bloat <bloat@lists.bufferbloat.net>,
>>>>     cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>,
>>>>     Dave Taht <dave.taht@gmail.com>
>>>> 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 <woody77@gmail.com> 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

[-- Attachment #2: Type: text/html, Size: 7082 bytes --]