[Cerowrt-devel] sqm-scripts on WRT1900AC

[Cerowrt-devel] sqm-scripts on WRT1900AC

[Aaron Wood]

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

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

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

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

[Aaron Wood]

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

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
>

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

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

[David Lang]

[-- Attachment #1: Type: TEXT/Plain, Size: 2818 bytes --]

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

[-- Attachment #2: Type: TEXT/PLAIN, Size: 140 bytes --]

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

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

[Pedro Tumusok]

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

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: 5410 bytes --]

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

[David Lang]

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

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

[Pedro Tumusok]

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

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

[David Lang]

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

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

[Pedro Tumusok]

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

Again, my take on it.

Mimo is using multipath to enhance signal and date rate. Basically multiple
antennas for tx and rx to leverage multipath propogation. But its always
between one ap and one client at the time, standard wifi stuff.
Mu-mimo is the same mimo effect, but it can talk to multiple clients at the
same time. Current wave 1 802.11ac chips only supports mimo and mu-mimo
will come in wave 2, I guess this autumn will see releases from the OEMs.

And Wikipedia does a much better job explaining it, than I can :)

http://en.wikipedia.org/wiki/Multi-user_MIMO

Pedro

On Fri, May 29, 2015 at 10:26 PM, David Lang <david@lang.hm> wrote:

> 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 <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: 8418 bytes --]

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

[Dave Taht]

yes, as it turned out I too was watching even linksys's unannounced
products enter the openwrt mainline with great joy (a core dev (imre)
does some work for them). I had fiddled with it a few months back...

... and I had tried to do a build w/cake+pie+fq_pie for it a few days
ago but the toolchain broke on my increasingly out of date main build
box (snapon). The right answer there is to get that stuff built out of
the main openwrt build system...

The marvell wifi driver for that box was dramatically improved last
christmas with fresh code from marvell, but I have not looked at it
closely to see how well the structure of the driver or the hardware
could align with the goals of make-wifi-fast. (has anyone? I am still
in pain from the ath10k work...)

the mvneta ethernet driver lacked bql when last I looked and was
really agressive about GRO offloads in particular. Both are easily
fixable.

And it has a fan. Hate fans. Amusingly (I guess), I had this same
chipset to fiddle with in the "mirabox" and it ran waaaay too hot.

It is not clear why you are getting an inaccurate rate out of it, either.

It is a leading candidate, but I would prefer to find a hardware
partner that cared about our issues enough to work with us, rather
than ignore us as netgear did.

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

[Aaron Wood]

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

On Sat, May 23, 2015 at 11:44 PM, Dave Taht <dave.taht@gmail.com> wrote:

>
> And it has a fan. Hate fans. Amusingly (I guess), I had this same
> chipset to fiddle with in the "mirabox" and it ran waaaay too hot.
>

I haven't hit the fan, yet....


> It is not clear why you are getting an inaccurate rate out of it, either.
>

I feel like the rate has never been really accurate, or perhaps it's just
that we're jut not properly accounting in our measurement tools (netperf),
for the ACK bandwidth.  But my current "limited" rate is set higher than
anything I've ever measured, and it's clearly still working.  Part of my
next rounds of testing are to keep pushing that up until it's clear that
I've tripped over the "real" rate.


It is a leading candidate, but I would prefer to find a hardware
> partner that cared about our issues enough to work with us, rather
> than ignore us as netgear did.
>

I fear that's going to be a continual issue while we ask for things that
most people don't understand that they want/need.  But I think that we'll
have an easier time if we're talking with a chipset vendor (like Marvell)
vs an OEM (like Netgear), given the relative distance each has from the
kernel drivers...

-Aaron

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