Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: David Lang <david@lang.hm>
To: Pedro Tumusok <pedro.tumusok@gmail.com>
Cc: cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Cerowrt-devel] [Bloat] sqm-scripts on WRT1900AC
Date: Fri, 29 May 2015 02:09:20 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.02.1505290203200.3147@nftneq.ynat.uz> (raw)
In-Reply-To: <CACQiMXbDBrR7TQ4H0CqLzrZGwsW1PwHPxZH2qmo4Ss86dLHx9A@mail.gmail.com>

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
>>
>>
>
>
>

  reply	other threads:[~2015-05-29  9:09 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-24  5:17 [Cerowrt-devel] " Aaron Wood
2015-05-24  6:19 ` Aaron Wood
2015-05-25 23:55   ` [Cerowrt-devel] [Bloat] " David Lang
2015-05-29  8:34     ` Pedro Tumusok
2015-05-29  9:09       ` David Lang [this message]
2015-05-29 10:04         ` Pedro Tumusok
2015-05-29 20:26           ` David Lang
2015-06-01  8:47             ` Pedro Tumusok
2015-05-24  6:44 ` Dave Taht
2015-05-24  6:51   ` Aaron Wood

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.02.1505290203200.3147@nftneq.ynat.uz \
    --to=david@lang.hm \
    --cc=bloat@lists.bufferbloat.net \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=pedro.tumusok@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox