[Cerowrt-devel] Problems testing sqm

[Cerowrt-devel] Problems testing sqm

[Richard Smith]

I have a shiny new Linksys WRT1900ACS to test.

I thought it might be nice to start with some comparisons of factory 
firmware vs OpenWRT with sqm enabled.

So I built and installed an openwrt trunk but the results were very 
non-impressive.  Rrul test reported mulit-seconds of latency and it was 
equally non-impressive with sqm enabled or disabled.  So I assumed that 
sqm in trunk on this device must not work yet.  Then I wondered how well 
sqm in trunk was tested and that perhaps its broken for all devices.

So I tested openwrt trunk on my Netgear 3700v2 and saw the same results. 
Then I tried openwrt cc and got the same results.

Finally, I went to the reference implementation: cerowrt 3.10.50-1 on my 
3700v2.  Same results.

So at this point I'm thinking there's a PEBKAC issue and I'm not really 
turning it on.

Here's my enable procedure:

Go the sqm tab in the GUI and set egress and ingress to 10000, set the 
interface to the upstream interface,  click enable, click save and 
apply. Everything else is left at default. ie fq_codel and simple.qos.

I've also tried a reboot after enabling those settings and then gone 
back to the gui to verify they were still set.

My test setup:

Laptop<--1000BaseT-->DUT<--1000baseT-->Server

I run netperf-wrapper -H Server -l 30 rrul and look at the 'totals' or 
'all' plot.

If I run the above with this setup.

Laptop<--1000baseT-->Server

Then I get the expected 800-900Mbit/s with latencies < 15ms.  So I don't 
think there's a problem with my test infrastructure.

What am I missing and or what's the next step in figuring out whats wrong?

-- 
Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm

[Dave Taht]

you are most likely applying the qdisc to the wrong ethernet device or
ethernet vlan.
Dave Täht
I just lost five years of my life to making wifi better. And, now...
the FCC wants to make my work, illegal for people to install.
https://www.gofundme.com/savewifi


On Fri, Oct 23, 2015 at 6:10 PM, Richard Smith <smithbone@gmail.com> wrote:
> I have a shiny new Linksys WRT1900ACS to test.
>
> I thought it might be nice to start with some comparisons of factory
> firmware vs OpenWRT with sqm enabled.
>
> So I built and installed an openwrt trunk but the results were very
> non-impressive.  Rrul test reported mulit-seconds of latency and it was
> equally non-impressive with sqm enabled or disabled.  So I assumed that sqm
> in trunk on this device must not work yet.  Then I wondered how well sqm in
> trunk was tested and that perhaps its broken for all devices.
>
> So I tested openwrt trunk on my Netgear 3700v2 and saw the same results.
> Then I tried openwrt cc and got the same results.
>
> Finally, I went to the reference implementation: cerowrt 3.10.50-1 on my
> 3700v2.  Same results.
>
> So at this point I'm thinking there's a PEBKAC issue and I'm not really
> turning it on.
>
> Here's my enable procedure:
>
> Go the sqm tab in the GUI and set egress and ingress to 10000, set the
> interface to the upstream interface,  click enable, click save and apply.
> Everything else is left at default. ie fq_codel and simple.qos.
>
> I've also tried a reboot after enabling those settings and then gone back to
> the gui to verify they were still set.
>
> My test setup:
>
> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>
> I run netperf-wrapper -H Server -l 30 rrul and look at the 'totals' or 'all'
> plot.
>
> If I run the above with this setup.
>
> Laptop<--1000baseT-->Server
>
> Then I get the expected 800-900Mbit/s with latencies < 15ms.  So I don't
> think there's a problem with my test infrastructure.
>
> What am I missing and or what's the next step in figuring out whats wrong?
>
> --
> Richard A. Smith
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Problems testing sqm

[Rich Brown]

Two other thoughts:

1) The WNDR3700v2 will struggle to (well, it won't) keep up with a > 100 mbps uplink. 

2) The numbers in the SQM page are in kilobits, not megabits/sec.

Rich

> On Oct 23, 2015, at 12:13 PM, Dave Taht <dave.taht@gmail.com> wrote:
> 
> you are most likely applying the qdisc to the wrong ethernet device or
> ethernet vlan.
> Dave Täht
> I just lost five years of my life to making wifi better. And, now...
> the FCC wants to make my work, illegal for people to install.
> https://www.gofundme.com/savewifi
> 
> 
> On Fri, Oct 23, 2015 at 6:10 PM, Richard Smith <smithbone@gmail.com> wrote:
>> I have a shiny new Linksys WRT1900ACS to test.
>> 
>> I thought it might be nice to start with some comparisons of factory
>> firmware vs OpenWRT with sqm enabled.
>> 
>> So I built and installed an openwrt trunk but the results were very
>> non-impressive.  Rrul test reported mulit-seconds of latency and it was
>> equally non-impressive with sqm enabled or disabled.  So I assumed that sqm
>> in trunk on this device must not work yet.  Then I wondered how well sqm in
>> trunk was tested and that perhaps its broken for all devices.
>> 
>> So I tested openwrt trunk on my Netgear 3700v2 and saw the same results.
>> Then I tried openwrt cc and got the same results.
>> 
>> Finally, I went to the reference implementation: cerowrt 3.10.50-1 on my
>> 3700v2.  Same results.
>> 
>> So at this point I'm thinking there's a PEBKAC issue and I'm not really
>> turning it on.
>> 
>> Here's my enable procedure:
>> 
>> Go the sqm tab in the GUI and set egress and ingress to 10000, set the
>> interface to the upstream interface,  click enable, click save and apply.
>> Everything else is left at default. ie fq_codel and simple.qos.
>> 
>> I've also tried a reboot after enabling those settings and then gone back to
>> the gui to verify they were still set.
>> 
>> My test setup:
>> 
>> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>> 
>> I run netperf-wrapper -H Server -l 30 rrul and look at the 'totals' or 'all'
>> plot.
>> 
>> If I run the above with this setup.
>> 
>> Laptop<--1000baseT-->Server
>> 
>> Then I get the expected 800-900Mbit/s with latencies < 15ms.  So I don't
>> think there's a problem with my test infrastructure.
>> 
>> What am I missing and or what's the next step in figuring out whats wrong?
>> 
>> --
>> Richard A. Smith
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Problems testing sqm

[Richard Smith]

On 10/23/2015 12:13 PM, Dave Taht wrote:
> you are most likely applying the qdisc to the wrong ethernet device or
> ethernet vlan.

In the cerowrt case it was applied to ge00.  If that's not the correct 
device then which one should it be?

-- 
Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm

[Richard Smith]

On 10/23/2015 12:21 PM, Rich Brown wrote:
> Two other thoughts:
>
> 1) The WNDR3700v2 will struggle to (well, it won't) keep up with a > 100 mbps uplink.
> 2) The numbers in the SQM page are in kilobits, not megabits/sec.

Nod.  That's why egress/ingress was set to 10000.  Well within the range 
of the WNDR3700v2.

-- 
Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm

[Alan Jenkins]

On 23/10/2015, Richard Smith <smithbone@gmail.com> wrote:
> I have a shiny new Linksys WRT1900ACS to test.
>
> I thought it might be nice to start with some comparisons of factory
> firmware vs OpenWRT with sqm enabled.
>
> So I built and installed an openwrt trunk but the results were very
> non-impressive.  Rrul test reported mulit-seconds of latency and it was
> equally non-impressive with sqm enabled or disabled.  So I assumed that
> sqm in trunk on this device must not work yet.  Then I wondered how well
> sqm in trunk was tested and that perhaps its broken for all devices.
>
> So I tested openwrt trunk on my Netgear 3700v2 and saw the same results.
> Then I tried openwrt cc and got the same results.
>
> Finally, I went to the reference implementation: cerowrt 3.10.50-1 on my
> 3700v2.  Same results.
>
> So at this point I'm thinking there's a PEBKAC issue and I'm not really
> turning it on.
>
> Here's my enable procedure:
>
> Go the sqm tab in the GUI and set egress and ingress to 10000, set the
> interface to the upstream interface,  click enable, click save and
> apply. Everything else is left at default. ie fq_codel and simple.qos.

Your description misses at least one step from the official how-to.
May be worth checking:

 Start and Enable the SQM scripts. To do this, choose System → Startup
    Click Start to start the SQM process
    Click Enable to start the SQM process when the route reboots

The how-to is here: http://wiki.openwrt.org/doc/howto/sqm


The original qos-scripts definitely required that step.  IIRC, it's an
openwrt convention that installing a package doesn't automatically
enable its startup script.  However this wasn't strictly necessary for
at least some drafts of the sqm code.  I don't know if the current
version needs it or not.

> I've also tried a reboot after enabling those settings and then gone
> back to the gui to verify they were still set.
>
> My test setup:
>
> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>
> I run netperf-wrapper -H Server -l 30 rrul and look at the 'totals' or
> 'all' plot.
>
> If I run the above with this setup.
>
> Laptop<--1000baseT-->Server
>
> Then I get the expected 800-900Mbit/s with latencies < 15ms.  So I don't
> think there's a problem with my test infrastructure.
>
> What am I missing and or what's the next step in figuring out whats wrong?
>
> --
> Richard A. Smith
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>


-- 
A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
>> A: Top-posting.
>>> Q: What is the most annoying thing in e-mail?

Re: [Cerowrt-devel] Problems testing sqm

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2684 bytes --]

with the wrt1900ACS, the WAN ethernet is connected to a switch before connecting 
to the wire. I believe that this causes some issues with the sqm default setup 
(or is it with the fq_codel?)

David Lang

On Fri, 23 Oct 2015, Dave Taht wrote:

> you are most likely applying the qdisc to the wrong ethernet device or
> ethernet vlan.
> Dave Täht
> I just lost five years of my life to making wifi better. And, now...
> the FCC wants to make my work, illegal for people to install.
> https://www.gofundme.com/savewifi
>
>
> On Fri, Oct 23, 2015 at 6:10 PM, Richard Smith <smithbone@gmail.com> wrote:
>> I have a shiny new Linksys WRT1900ACS to test.
>>
>> I thought it might be nice to start with some comparisons of factory
>> firmware vs OpenWRT with sqm enabled.
>>
>> So I built and installed an openwrt trunk but the results were very
>> non-impressive.  Rrul test reported mulit-seconds of latency and it was
>> equally non-impressive with sqm enabled or disabled.  So I assumed that sqm
>> in trunk on this device must not work yet.  Then I wondered how well sqm in
>> trunk was tested and that perhaps its broken for all devices.
>>
>> So I tested openwrt trunk on my Netgear 3700v2 and saw the same results.
>> Then I tried openwrt cc and got the same results.
>>
>> Finally, I went to the reference implementation: cerowrt 3.10.50-1 on my
>> 3700v2.  Same results.
>>
>> So at this point I'm thinking there's a PEBKAC issue and I'm not really
>> turning it on.
>>
>> Here's my enable procedure:
>>
>> Go the sqm tab in the GUI and set egress and ingress to 10000, set the
>> interface to the upstream interface,  click enable, click save and apply.
>> Everything else is left at default. ie fq_codel and simple.qos.
>>
>> I've also tried a reboot after enabling those settings and then gone back to
>> the gui to verify they were still set.
>>
>> My test setup:
>>
>> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>>
>> I run netperf-wrapper -H Server -l 30 rrul and look at the 'totals' or 'all'
>> plot.
>>
>> If I run the above with this setup.
>>
>> Laptop<--1000baseT-->Server
>>
>> Then I get the expected 800-900Mbit/s with latencies < 15ms.  So I don't
>> think there's a problem with my test infrastructure.
>>
>> What am I missing and or what's the next step in figuring out whats wrong?
>>
>> --
>> Richard A. Smith
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Problems testing sqm

[Aaron Wood]

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

On Fri, Oct 23, 2015 at 9:10 AM, Richard Smith <smithbone@gmail.com> wrote:

> I have a shiny new Linksys WRT1900ACS to test.
>
> I thought it might be nice to start with some comparisons of factory
> firmware vs OpenWRT with sqm enabled.
>

Here are my results with the same router (unless the WRT1900ACS is
different from the WRT1900AC):
http://burntchrome.blogspot.com/2015/06/sqmscripts-before-and-after-at-160mbps.html



> So I built and installed an openwrt trunk but the results were very
> non-impressive.  Rrul test reported mulit-seconds of latency and it was
> equally non-impressive with sqm enabled or disabled.  So I assumed that sqm
> in trunk on this device must not work yet.  Then I wondered how well sqm in
> trunk was tested and that perhaps its broken for all devices.
>

Trunk or the Chaos Calmer release?  (I"m running CC RC1)


> My test setup:
>
> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>

Which ports on the DUT were you using?  are those local ports, or is one of
those the "internet" port?

-Aaron

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

Re: [Cerowrt-devel] Problems testing sqm

[Richard Smith]

On 10/23/2015 01:02 PM, Alan Jenkins wrote:

>> Go the sqm tab in the GUI and set egress and ingress to 10000, set the
>> interface to the upstream interface,  click enable, click save and
>> apply. Everything else is left at default. ie fq_codel and simple.qos.
>
> Your description misses at least one step from the official how-to.
> May be worth checking:
>
>   Start and Enable the SQM scripts. To do this, choose System → Startup
>      Click Start to start the SQM process
>      Click Enable to start the SQM process when the route reboots
>
> The how-to is here: http://wiki.openwrt.org/doc/howto/sqm

Ah... That would explain everything.  Indeed, I missed that part.  Thank 
you for noticing that.

> The original qos-scripts definitely required that step.  IIRC, it's an
> openwrt convention that installing a package doesn't automatically
> enable its startup script.

Is this also the case if build it in via make menuconfig instead of a 
package?

What about for cerowrt? It's not started by default there as well?

The box(s) are back at my apartment so I can't examine them at the moment.

-- 
Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm

[Sebastian Moeller]

Hi Richard,


On Oct 23, 2015, at 18:10 , Richard Smith <smithbone@gmail.com> wrote:

> I have a shiny new Linksys WRT1900ACS to test.

	Nice, I am quite curious how this performs...

> 
> I thought it might be nice to start with some comparisons of factory firmware vs OpenWRT with sqm enabled.

	Good thought.

> 
> So I built and installed an openwrt trunk but the results were very non-impressive.  Rrul test reported mulit-seconds of latency and it was equally non-impressive with sqm enabled or disabled.

	Less good result.

>  So I assumed that sqm in trunk on this device must not work yet.  Then I wondered how well sqm in trunk was tested and that perhaps its broken for all devices.

	I believe it works reasonable well, at least there are no reports about major failures known and only minor fixes outstanding.

> 
> So I tested openwrt trunk on my Netgear 3700v2 and saw the same results. Then I tried openwrt cc and got the same results.

	This is suspicious.

> 
> Finally, I went to the reference implementation: cerowrt 3.10.50-1 on my 3700v2.  Same results.

	Now the default sqm-scripts in cerowrt is ancient, but all the same looks weird...

> 
> So at this point I'm thinking there's a PEBKAC issue and I'm not really turning it on.

	Well, it might be lack of documentation… (on my todo list, but way way back there, sorry).

> 
> Here's my enable procedure:
> 
> Go the sqm tab in the GUI and set egress and ingress to 10000, set the interface to the upstream interface,  click enable, click save and apply. Everything else is left at default. ie fq_codel and simple.qos.
> 
> I've also tried a reboot after enabling those settings and then gone back to the gui to verify they were still set.

	The best test (for validity of the configuration) is to run the following on the router and preferably copy and post the output to this thread:

1) tc -d qdisc
2) /etc/init.d/sqm stop
3) tc -d qdisc
4) /etc/init.d/sqm start
5) tc -d qdisc

> 
> My test setup:
> 
> Laptop<--1000BaseT-->DUT<--1000baseT—>Server

	What does DUT expand to?

> 
> I run netperf-wrapper -H Server -l 30 rrul and look at the 'totals' or 'all' plot.

	I routinely look at the all_scaled plot as well as the totals, often the time course offers some explanation why the total looks bad, maybe you could post the plot here?

Best Regards
	Sebastian

> 
> If I run the above with this setup.
> 
> Laptop<--1000baseT-->Server
> 
> Then I get the expected 800-900Mbit/s with latencies < 15ms.  So I don't think there's a problem with my test infrastructure.
> 
> What am I missing and or what's the next step in figuring out whats wrong?
> 
> -- 
> Richard A. Smith
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Problems testing sqm

[Sebastian Moeller]

Hi Richard,

On Oct 23, 2015, at 18:43 , Richard Smith <smithbone@gmail.com> wrote:

> On 10/23/2015 12:13 PM, Dave Taht wrote:
>> you are most likely applying the qdisc to the wrong ethernet device or
>> ethernet vlan.
> 
> In the cerowrt case it was applied to ge00.  If that's not the correct device then which one should it be?

	That is the “WAN” port and hence the correct one, note you can set up sqm on non-wan ports as well (actually you can set it up on multiple ports concurrently, but that seems more relevant after it works correctly on one port first). In cease you ever set it up on a LAN port, plea note that download/ingress and upload/egress in the GUI are from the router perspective, or aligned with the view from machines on the internal network if sqm is set up on the wan port, if sqm is activated on a lan port the meaning go ingress and egress reverse from the user perspective. Not that this matters in your case as you set symmetric shaper rates…

Best Regards
	Sebastian

> 
> -- 
> Richard A. Smith
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Problems testing sqm

[Sebastian Moeller]

Hi Alan, hi Richard,

On Oct 23, 2015, at 19:02 , Alan Jenkins <alan.christopher.jenkins@gmail.com> wrote:

> On 23/10/2015, Richard Smith <smithbone@gmail.com> wrote:
>> I have a shiny new Linksys WRT1900ACS to test.
>> 
>> I thought it might be nice to start with some comparisons of factory
>> firmware vs OpenWRT with sqm enabled.
>> 
>> So I built and installed an openwrt trunk but the results were very
>> non-impressive.  Rrul test reported mulit-seconds of latency and it was
>> equally non-impressive with sqm enabled or disabled.  So I assumed that
>> sqm in trunk on this device must not work yet.  Then I wondered how well
>> sqm in trunk was tested and that perhaps its broken for all devices.
>> 
>> So I tested openwrt trunk on my Netgear 3700v2 and saw the same results.
>> Then I tried openwrt cc and got the same results.
>> 
>> Finally, I went to the reference implementation: cerowrt 3.10.50-1 on my
>> 3700v2.  Same results.
>> 
>> So at this point I'm thinking there's a PEBKAC issue and I'm not really
>> turning it on.
>> 
>> Here's my enable procedure:
>> 
>> Go the sqm tab in the GUI and set egress and ingress to 10000, set the
>> interface to the upstream interface,  click enable, click save and
>> apply. Everything else is left at default. ie fq_codel and simple.qos.
> 
> Your description misses at least one step from the official how-to.
> May be worth checking:
> 
> Start and Enable the SQM scripts. To do this, choose System → Startup
>    Click Start to start the SQM process
>    Click Enable to start the SQM process when the route reboots
> 
> The how-to is here: http://wiki.openwrt.org/doc/howto/sqm

	The version in trunk and in CC as far as I know will automatically enable the “initab” if at least one sqm instance is set to enabled and that state is saved or saved&apply’d.

> 
> 
> The original qos-scripts definitely required that step.  IIRC, it's an
> openwrt convention that installing a package doesn't automatically
> enable its startup script.  However this wasn't strictly necessary for
> at least some drafts of the sqm code.  I don't know if the current
> version needs it or not.

	The current code should do that for you, but it might fail to do so. I note currenty sqm is quite terse about success or failure (one more thing on the secret todo list).

Best Regards
	Sebastian

> 
>> I've also tried a reboot after enabling those settings and then gone
>> back to the gui to verify they were still set.
>> 
>> My test setup:
>> 
>> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>> 
>> I run netperf-wrapper -H Server -l 30 rrul and look at the 'totals' or
>> 'all' plot.
>> 
>> If I run the above with this setup.
>> 
>> Laptop<--1000baseT-->Server
>> 
>> Then I get the expected 800-900Mbit/s with latencies < 15ms.  So I don't
>> think there's a problem with my test infrastructure.
>> 
>> What am I missing and or what's the next step in figuring out whats wrong?
>> 
>> --
>> Richard A. Smith
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>> 
> 
> 
> -- 
> A: Because it messes up the order in which people normally read text.
>> Q: Why is top-posting such a bad thing?
>>> A: Top-posting.
>>>> Q: What is the most annoying thing in e-mail?
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Problems testing sqm

[Sebastian Moeller]

Hi Aaron,

On Oct 23, 2015, at 19:22 , Aaron Wood <woody77@gmail.com> wrote:

> 
> 
> On Fri, Oct 23, 2015 at 9:10 AM, Richard Smith <smithbone@gmail.com> wrote:
> I have a shiny new Linksys WRT1900ACS to test.
> 
> I thought it might be nice to start with some comparisons of factory firmware vs OpenWRT with sqm enabled.
> 
> Here are my results with the same router (unless the WRT1900ACS is different from the WRT1900AC):

	I believe the ACS is the success or the AC, basically using the same SoC @higher frequency as the 1200AC, which tested very well in Mikael’s tests recently.

> http://burntchrome.blogspot.com/2015/06/sqmscripts-before-and-after-at-160mbps.html

	But that looks quite nice…

Best Regards
	Sebastian

> 
>  
> So I built and installed an openwrt trunk but the results were very non-impressive.  Rrul test reported mulit-seconds of latency and it was equally non-impressive with sqm enabled or disabled.  So I assumed that sqm in trunk on this device must not work yet.  Then I wondered how well sqm in trunk was tested and that perhaps its broken for all devices.
> 
> Trunk or the Chaos Calmer release?  (I"m running CC RC1)
>  
> My test setup:
> 
> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
> 
> Which ports on the DUT were you using?  are those local ports, or is one of those the "internet" port?
>  
> -Aaron
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Problems testing sqm

[Richard Smith]

On 10/23/2015 01:22 PM, Aaron Wood wrote:

>
>
> On Fri, Oct 23, 2015 at 9:10 AM, Richard Smith <smithbone@gmail.com
> <mailto:smithbone@gmail.com>> wrote:
>
>     I have a shiny new Linksys WRT1900ACS to test.
>
>     I thought it might be nice to start with some comparisons of factory
>     firmware vs OpenWRT with sqm enabled.
>
>
> Here are my results with the same router (unless the WRT1900ACS is
> different from the WRT1900AC):
> http://burntchrome.blogspot.com/2015/06/sqmscripts-before-and-after-at-160mbps.html
>
>     So I built and installed an openwrt trunk but the results were very
>     non-impressive.  Rrul test reported mulit-seconds of latency and it
>     was equally non-impressive with sqm enabled or disabled.  So I
>     assumed that sqm in trunk on this device must not work yet.  Then I
>     wondered how well sqm in trunk was tested and that perhaps its
>     broken for all devices.
>
>
> Trunk or the Chaos Calmer release?  (I"m running CC RC1)

If I understand your question correctly I did both.  I built trunk (for 
both WRT1900ACS and WNDR700v2. Then downloaded the current CC from 
openwrt.org and installed sqm.

>     My test setup:
>
> Which ports on the DUT were you using?  are those local ports, or is one
> of those the "internet" port?

I was using both WAN & LAN.

Laptop<--1000BaseT-->DUT LAN<-->DUT WAN<--1000baseT-->Server

-- 
Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm

[Sebastian Moeller]

Hi Richard,

On Oct 23, 2015, at 19:30 , Richard Smith <smithbone@gmail.com> wrote:

> On 10/23/2015 01:02 PM, Alan Jenkins wrote:
> 
>>> Go the sqm tab in the GUI and set egress and ingress to 10000, set the
>>> interface to the upstream interface,  click enable, click save and
>>> apply. Everything else is left at default. ie fq_codel and simple.qos.
>> 
>> Your description misses at least one step from the official how-to.
>> May be worth checking:
>> 
>>  Start and Enable the SQM scripts. To do this, choose System → Startup
>>     Click Start to start the SQM process
>>     Click Enable to start the SQM process when the route reboots
>> 
>> The how-to is here: http://wiki.openwrt.org/doc/howto/sqm
> 
> Ah... That would explain everything.  Indeed, I missed that part.  Thank you for noticing that.

	I believe at least the version in trunk should handle hat for you, but that might be broken, so please help me figuring this out, so I can fix up sqm-scripts.

> 
>> The original qos-scripts definitely required that step.  IIRC, it's an
>> openwrt convention that installing a package doesn't automatically
>> enable its startup script.
> 
> Is this also the case if build it in via make menuconfig instead of a package?

	I believe if you set a package to install automatically the build system does that for you automatically, but I have never tested that myself...

> 
> What about for cerowrt? It's not started by default there as well?

	In cerowrt we have a number of issues, but I forgot whether it starts automatically or not...

> 
> The box(s) are back at my apartment so I can't examine them at the moment.

	Take your time ;) 

Best Regards
	Sebastian

> 
> -- 
> Richard A. Smith
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Problems testing sqm

[David Lang]

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

On Fri, 23 Oct 2015, Aaron Wood wrote:

> On Fri, Oct 23, 2015 at 9:10 AM, Richard Smith <smithbone@gmail.com> wrote:
>
>> I have a shiny new Linksys WRT1900ACS to test.
>>
>> I thought it might be nice to start with some comparisons of factory
>> firmware vs OpenWRT with sqm enabled.
>>
>
> Here are my results with the same router (unless the WRT1900ACS is
> different from the WRT1900AC):
> http://burntchrome.blogspot.com/2015/06/sqmscripts-before-and-after-at-160mbps.html

the ACS has more flash (and ram IIRC) and is 1.6GHz instead of 1.2GHz

David Lang

>
>
>
>> So I built and installed an openwrt trunk but the results were very
>> non-impressive.  Rrul test reported mulit-seconds of latency and it was
>> equally non-impressive with sqm enabled or disabled.  So I assumed that sqm
>> in trunk on this device must not work yet.  Then I wondered how well sqm in
>> trunk was tested and that perhaps its broken for all devices.
>>
>
> Trunk or the Chaos Calmer release?  (I"m running CC RC1)
>
>
>> My test setup:
>>
>> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>>
>
> Which ports on the DUT were you using?  are those local ports, or is one of
> those the "internet" port?
>
> -Aaron
>

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

_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Problems testing sqm

[Richard Smith]

On 10/23/2015 01:38 PM, Sebastian Moeller wrote:

>> So at this point I'm thinking there's a PEBKAC issue and I'm not
>> really turning it on.
>
> Well, it might be lack of documentation… (on my todo list, but way
> way back there, sorry).

:)  No worries.

> The best test (for validity of the configuration) is to run the
> following on the router and preferably copy and post the output to
> this thread:
>
> 1) tc -d qdisc 2) /etc/init.d/sqm stop 3) tc -d qdisc 4)
> /etc/init.d/sqm start 5) tc -d qdisc

Thank you.  I'll verify things with that.

>> My test setup:
>>
>> Laptop<--1000BaseT-->DUT<--1000baseT—>Server
>
> What does DUT expand to?

Device Under Test. ie the 1900ACS or 3700v2

>> I run netperf-wrapper -H Server -l 30 rrul and look at the
>> 'totals' or 'all' plot.
>
> I routinely look at the all_scaled plot as well as the totals, often
> the time course offers some explanation why the total looks bad,
> maybe you could post the plot here?

Certainly.  I thought about sending one along but wanted to wait and
verify I wasn't doing something stupid first.  I can just send up the 
rrul log file.  Probably don't want to send it to the list though.
I'll include a download link via google drive.

>> Ah... That would explain everything.  Indeed, I missed that part.
>> Thank you for noticing that.
>
> I believe at least the version in trunk should handle hat for you,
> but that might be broken, so please help me figuring this out, so I
> can fix up sqm-scripts.

Thank you for the confirmation.  I'll verify yes/no on trunk this weekend.

Thanks everyone for the helpful suggestions and stuff to look at.

-- 
Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm

[Michael Richardson]

Richard Smith <smithbone@gmail.com> wrote:
    > My test setup:

    > Laptop<--1000BaseT-->DUT<--1000baseT-->Server

So, given that the DUT is the only real constraint in the network, what
do you expect to see from this setup?

Given that the probably DUT can't forward at Gb/s, and it certainly can't
shape anything, it's gonna drop packets, and it's probably gonna drop them in
Rx, having overrun the Rx-queue (so tail-drop).  If there is too much ram
(bufferbloated), then you'll see different results...

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [

Re: [Cerowrt-devel] Problems testing sqm

[Sebastian Moeller]

Hi David,

On Oct 23, 2015, at 19:57 , David Lang <david@lang.hm> wrote:

> On Fri, 23 Oct 2015, Aaron Wood wrote:
> 
>> On Fri, Oct 23, 2015 at 9:10 AM, Richard Smith <smithbone@gmail.com> wrote:
>> 
>>> I have a shiny new Linksys WRT1900ACS to test.
>>> 
>>> I thought it might be nice to start with some comparisons of factory
>>> firmware vs OpenWRT with sqm enabled.
>>> 
>> 
>> Here are my results with the same router (unless the WRT1900ACS is
>> different from the WRT1900AC):
>> http://burntchrome.blogspot.com/2015/06/sqmscripts-before-and-after-at-160mbps.html
> 
> the ACS has more flash (and ram IIRC) and is 1.6GHz instead of 1.2GHz
> 
> David Lang

	According to https://wikidevi.com/wiki/Marvell the wrt1900AC has an older marvell  MV78230 or armada XP SoC while both the wrt1200AC and the wrt1900ACS sport a newer 88F6820 or armada 385 SoC. I believe Mikael Abrahamsson tested the wrt1200AC to be quite competent as CPU based router and shaper, so I am puzzled with Richards results. Hopefully we will figure out the cause and fix/improve sqm…

Best Regards
	Sebastian

> 
>> 
>> 
>> 
>>> So I built and installed an openwrt trunk but the results were very
>>> non-impressive.  Rrul test reported mulit-seconds of latency and it was
>>> equally non-impressive with sqm enabled or disabled.  So I assumed that sqm
>>> in trunk on this device must not work yet.  Then I wondered how well sqm in
>>> trunk was tested and that perhaps its broken for all devices.
>>> 
>> 
>> Trunk or the Chaos Calmer release?  (I"m running CC RC1)
>> 
>> 
>>> My test setup:
>>> 
>>> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>>> 
>> 
>> Which ports on the DUT were you using?  are those local ports, or is one of
>> those the "internet" port?
>> 
>> -Aaron
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Problems testing sqm

[Richard Smith]

On 10/23/2015 02:41 PM, Michael Richardson wrote:
> Richard Smith <smithbone@gmail.com> wrote:
>      > My test setup:
>
>      > Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>
> So, given that the DUT is the only real constraint in the network, what
> do you expect to see from this setup?
>
> Given that the probably DUT can't forward at Gb/s, and it certainly can't
> shape anything, it's gonna drop packets, and it's probably gonna drop them in
> Rx, having overrun the Rx-queue (so tail-drop).  If there is too much ram
> (bufferbloated), then you'll see different results...

Setting ingress/egress to 10Mbit/s I expected to see the speed 
measurements bounce around those limits with the ping times staying in 
the low double digits of ms.  What I saw however, was the data rates 
going well past 10Mbit limit and pings up to 2000 ms.

This is what I've seen in prior rrul testing using a the 50/10 cable 
link at our office and my 25(ish)/6 link at my apartment and a well 
connected server on the net.  That however was using QoS and not SQM.

Its that a reasonable expectation?

-- 
Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm

[David P. Reed]

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

Sqm is a way to deal with the dsl or cable modem having bufferbloat. In the configuration described neither end is the problem ... the DUT itself may have bufferbloat. That would be terrible.

On Oct 23, 2015, Richard Smith <smithbone@gmail.com> wrote:
>On 10/23/2015 02:41 PM, Michael Richardson wrote:
>> Richard Smith <smithbone@gmail.com> wrote:
>>      > My test setup:
>>
>>      > Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>>
>> So, given that the DUT is the only real constraint in the network,
>what
>> do you expect to see from this setup?
>>
>> Given that the probably DUT can't forward at Gb/s, and it certainly
>can't
>> shape anything, it's gonna drop packets, and it's probably gonna drop
>them in
>> Rx, having overrun the Rx-queue (so tail-drop).  If there is too much
>ram
>> (bufferbloated), then you'll see different results...
>
>Setting ingress/egress to 10Mbit/s I expected to see the speed
>measurements bounce around those limits with the ping times staying in
>the low double digits of ms.  What I saw however, was the data rates
>going well past 10Mbit limit and pings up to 2000 ms.
>
>This is what I've seen in prior rrul testing using a the 50/10 cable
>link at our office and my 25(ish)/6 link at my apartment and a well
>connected server on the net.  That however was using QoS and not SQM.
>
>Its that a reasonable expectation?

-- Sent with K-@ Mail - the evolution of emailing.

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

Re: [Cerowrt-devel] Problems testing sqm

[Aaron Wood]

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

On Fri, Oct 23, 2015 at 1:18 PM, Richard Smith <smithbone@gmail.com> wrote:

> On 10/23/2015 02:41 PM, Michael Richardson wrote:
>
>> Richard Smith <smithbone@gmail.com> wrote:
>>      > My test setup:
>>
>>      > Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>>
>> So, given that the DUT is the only real constraint in the network, what
>> do you expect to see from this setup?
>>
>
>

> Setting ingress/egress to 10Mbit/s I expected to see the speed
>> measurements bounce around those limits with the ping times staying in the
>> low double digits of ms.  What I saw however, was the data rates going well
>> past 10Mbit limit and pings up to 2000 ms.
>>
>
> This is what I've seen in prior rrul testing using a the 50/10 cable link
> at our office and my 25(ish)/6 link at my apartment and a well connected
> server on the net.  That however was using QoS and not SQM.
>
> Its that a reasonable expectation?


It is, and it's what you should have seen, so I think that it wasn't
_actually_ running.  I don't remember if I had to reboot or not after
installing both sqm_scripts and luci_sqm_scripts on my WRT1900AC.

But the request earlier to run "tc" to show the qdiscs will tell you if
it's really setup right or not.

-Aaron

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

Re: [Cerowrt-devel] Problems testing sqm

[David P. Reed]

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

In particular,  the DUT should probably have no more than 2 packets of outbound queueing given the very small RTT. 2xRTT is the most buffering you want in the loop.

On Oct 23, 2015, Richard Smith <smithbone@gmail.com> wrote:
>On 10/23/2015 02:41 PM, Michael Richardson wrote:
>> Richard Smith <smithbone@gmail.com> wrote:
>>      > My test setup:
>>
>>      > Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>>
>> So, given that the DUT is the only real constraint in the network,
>what
>> do you expect to see from this setup?
>>
>> Given that the probably DUT can't forward at Gb/s, and it certainly
>can't
>> shape anything, it's gonna drop packets, and it's probably gonna drop
>them in
>> Rx, having overrun the Rx-queue (so tail-drop).  If there is too much
>ram
>> (bufferbloated), then you'll see different results...
>
>Setting ingress/egress to 10Mbit/s I expected to see the speed
>measurements bounce around those limits with the ping times staying in
>the low double digits of ms.  What I saw however, was the data rates
>going well past 10Mbit limit and pings up to 2000 ms.
>
>This is what I've seen in prior rrul testing using a the 50/10 cable
>link at our office and my 25(ish)/6 link at my apartment and a well
>connected server on the net.  That however was using QoS and not SQM.
>
>Its that a reasonable expectation?

-- Sent with K-@ Mail - the evolution of emailing.

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

Re: [Cerowrt-devel] Problems testing sqm

[Sebastian Moeller]

Hi David,

On Oct 24, 2015, at 00:48 , David P. Reed <dpreed@reed.com> wrote:

> Sqm is a way to deal with the dsl or cable modem having bufferbloat. In the configuration described neither end is the problem ... the DUT itself may have bufferbloat.

	But our claim is that we “solved” (at least wired) buffer bloat. And in his case the failure of even our reference platform wndr3700v2 to keep sane latency under load hints at issues; with a configuration issue, or some yet un-solved corner issue with our solution.


> That would be terrible.

	I agree, so let’s try to figure out what is happening here..

Best Regards
	Sebastian


> 
> On Oct 23, 2015, Richard Smith <smithbone@gmail.com> wrote:
> On 10/23/2015 02:41 PM, Michael Richardson wrote:
> Richard Smith <smithbone@gmail.com> wrote:
> My test setup:
> 
> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
> 
> So, given that the DUT is the only real constraint in the network, what
> do you expect to see from this setup?
> 
> Given that the probably DUT can't forward at Gb/s, and it certainly can't
> shape anything, it's gonna drop packets, and it's probably gonna drop them in
> Rx, having overrun the Rx-queue (so tail-drop). If there is too much ram
> (bufferbloated), then you'll see different results...
> 
> Setting ingress/egress to 10Mbit/s I expected to see the speed 
> measurements bounce around those limits with the ping times staying in 
> the low double digits of ms. What I saw however, was the data rates 
> going well past 10Mbit limit and pings up to 2000 ms.
> 
> This is what I've seen in prior rrul testing using a the 50/10 cable 
> link at our office and my 25(ish)/6 link at my apartment and a well 
> connected server on the net. That however was using QoS and not SQM.
> 
> Its that a reasonable expectation?
> 
> -- Sent with K-@ Mail - the evolution of emailing. _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Problems testing sqm

[Sebastian Moeller]

Hi David,

On Oct 24, 2015, at 00:53 , David P. Reed <dpreed@reed.com> wrote:

> In particular,  the DUT should probably have no more than 2 packets of outbound queueing given the very small RTT. 2xRTT is the most buffering you want in the loop.

	Let’s not haggle about the precise amount of queueing we deem acceptable, as long as we all agree that >= 2 seconds is simply not acceptable ;) (the default sqm will approximately limit the latency under load increase (LULI) to roughly twice the target or typically 10 ms; note that this LULI only applies to unrelated flows). The exact number of queued packets seems to correlate with the beefiness of the DUT, the beefier the fewer packets should work, wimpier devices might need to batch some processing up, resulting in  higher LULI…

Best Regards
	Sebastian

> 
> On Oct 23, 2015, Richard Smith <smithbone@gmail.com> wrote:
> On 10/23/2015 02:41 PM, Michael Richardson wrote:
> Richard Smith <smithbone@gmail.com> wrote:
> My test setup:
> 
> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
> 
> So, given that the DUT is the only real constraint in the network, what
> do you expect to see from this setup?
> 
> Given that the probably DUT can't forward at Gb/s, and it certainly can't
> shape anything, it's gonna drop packets, and it's probably gonna drop them in
> Rx, having overrun the Rx-queue (so tail-drop). If there is too much ram
> (bufferbloated), then you'll see different results...
> 
> Setting ingress/egress to 10Mbit/s I expected to see the speed 
> measurements bounce around those limits with the ping times staying in 
> the low double digits of ms. What I saw however, was the data rates 
> going well past 10Mbit limit and pings up to 2000 ms.
> 
> This is what I've seen in prior rrul testing using a the 50/10 cable 
> link at our office and my 25(ish)/6 link at my apartment and a well 
> connected server on the net. That however was using QoS and not SQM.
> 
> Its that a reasonable expectation?
> 
> -- Sent with K-@ Mail - the evolution of emailing. _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Problems testing sqm

[Dave Taht]

Another thought is that this hardware agressively does GRO - 64k
"packets"really messes up htb. We already showed that problem in the
previous generation.

which we fixed in cake... Turn off all ethernet offloads and try again?

I have no idea what else is going wrong.
Dave Täht
I just lost five years of my life to making wifi better. And, now...
the FCC wants to make my work, illegal for people to install.
https://www.gofundme.com/savewifi


On Fri, Oct 23, 2015 at 6:10 PM, Richard Smith <smithbone@gmail.com> wrote:
> I have a shiny new Linksys WRT1900ACS to test.
>
> I thought it might be nice to start with some comparisons of factory
> firmware vs OpenWRT with sqm enabled.
>
> So I built and installed an openwrt trunk but the results were very
> non-impressive.  Rrul test reported mulit-seconds of latency and it was
> equally non-impressive with sqm enabled or disabled.  So I assumed that sqm
> in trunk on this device must not work yet.  Then I wondered how well sqm in
> trunk was tested and that perhaps its broken for all devices.
>
> So I tested openwrt trunk on my Netgear 3700v2 and saw the same results.
> Then I tried openwrt cc and got the same results.
>
> Finally, I went to the reference implementation: cerowrt 3.10.50-1 on my
> 3700v2.  Same results.
>
> So at this point I'm thinking there's a PEBKAC issue and I'm not really
> turning it on.
>
> Here's my enable procedure:
>
> Go the sqm tab in the GUI and set egress and ingress to 10000, set the
> interface to the upstream interface,  click enable, click save and apply.
> Everything else is left at default. ie fq_codel and simple.qos.
>
> I've also tried a reboot after enabling those settings and then gone back to
> the gui to verify they were still set.
>
> My test setup:
>
> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>
> I run netperf-wrapper -H Server -l 30 rrul and look at the 'totals' or 'all'
> plot.
>
> If I run the above with this setup.
>
> Laptop<--1000baseT-->Server
>
> Then I get the expected 800-900Mbit/s with latencies < 15ms.  So I don't
> think there's a problem with my test infrastructure.
>
> What am I missing and or what's the next step in figuring out whats wrong?
>
> --
> Richard A. Smith
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Problems testing sqm

[David P. Reed]

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

Not trying to haggle. Just pointing out that this test configuration has a very short RTT. maybe too short for our SQM to adjust to.

On Oct 24, 2015, Sebastian Moeller <moeller0@gmx.de> wrote:
>Hi David,
>
>On Oct 24, 2015, at 00:53 , David P. Reed <dpreed@reed.com> wrote:
>
>> In particular,  the DUT should probably have no more than 2 packets
>of outbound queueing given the very small RTT. 2xRTT is the most
>buffering you want in the loop.
>
>	Let’s not haggle about the precise amount of queueing we deem
>acceptable, as long as we all agree that >= 2 seconds is simply not
>acceptable ;) (the default sqm will approximately limit the latency
>under load increase (LULI) to roughly twice the target or typically 10
>ms; note that this LULI only applies to unrelated flows). The exact
>number of queued packets seems to correlate with the beefiness of the
>DUT, the beefier the fewer packets should work, wimpier devices might
>need to batch some processing up, resulting in  higher LULI…
>
>Best Regards
>	Sebastian
>
>>
>> On Oct 23, 2015, Richard Smith <smithbone@gmail.com> wrote:
>> On 10/23/2015 02:41 PM, Michael Richardson wrote:
>> Richard Smith <smithbone@gmail.com> wrote:
>> My test setup:
>>
>> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>>
>> So, given that the DUT is the only real constraint in the network,
>what
>> do you expect to see from this setup?
>>
>> Given that the probably DUT can't forward at Gb/s, and it certainly
>can't
>> shape anything, it's gonna drop packets, and it's probably gonna drop
>them in
>> Rx, having overrun the Rx-queue (so tail-drop). If there is too much
>ram
>> (bufferbloated), then you'll see different results...
>>
>> Setting ingress/egress to 10Mbit/s I expected to see the speed
>> measurements bounce around those limits with the ping times staying
>in
>> the low double digits of ms. What I saw however, was the data rates
>> going well past 10Mbit limit and pings up to 2000 ms.
>>
>> This is what I've seen in prior rrul testing using a the 50/10 cable
>> link at our office and my 25(ish)/6 link at my apartment and a well
>> connected server on the net. That however was using QoS and not SQM.
>>
>> Its that a reasonable expectation?
>>
>> -- Sent with K-@ Mail - the evolution of emailing.
>_______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel

-- Sent with K-@ Mail - the evolution of emailing.

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

Re: [Cerowrt-devel] Problems testing sqm

[Jonathan Morton]

> On 24 Oct, 2015, at 19:34, David P. Reed <dpreed@reed.com> wrote:
> 
> Not trying to haggle. Just pointing out that this test configuration has a very short RTT. maybe too short for our SQM to adjust to.

It should still get the bandwidth right.  When it does, we’ll know that the setup is correct.

 - Jonathan Morton

Re: [Cerowrt-devel] Problems testing sqm

[Sebastian Moeller]

Hi Dave,

On Oct 24, 2015, at 12:20 , Dave Taht <dave.taht@gmail.com> wrote:

> Another thought is that this hardware agressively does GRO - 64k
> "packets"really messes up htb. We already showed that problem in the
> previous generation.

	Good point. To disable the offloads one needs to disable offloads for all interfaces. The following shell function should do the trick, just run it for all interfaces:

eth_setup() {
    ethtool -K $IFACE gso off
    ethtool -K $IFACE tso off
    ethtool -K $IFACE ufo off
    ethtool -K $IFACE gro off
                    
    if [ -e /sys/class/net/$IFACE/queues/tx-0/byte_queue_limits ]
    then
       for i in /sys/class/net/$IFACE/queues/tx-*/byte_queue_limits
       do
          echo $(( 4 * $( get_mtu ${IFACE} ) )) > $i/limit_max
       done 
    fi
}

Save this into a shell file, say my_func.sh, source it from the router’s shell “. ./my_func.sh”, and call “IFACE=eth0 eth_setup” for all interfaces to tackle. I guess we should expose this under luci-app-sqm in a nicer fashion.

But since cerowrt automatically disabled all off-loads and Richard saw his issues also with cerowrt, I am not sure whether this is his issue…

Best Regards
	Sebastian



> 
> which we fixed in cake... Turn off all ethernet offloads and try again?
> 
> I have no idea what else is going wrong.
> Dave Täht
> I just lost five years of my life to making wifi better. And, now...
> the FCC wants to make my work, illegal for people to install.
> https://www.gofundme.com/savewifi
> 
> 
> On Fri, Oct 23, 2015 at 6:10 PM, Richard Smith <smithbone@gmail.com> wrote:
>> I have a shiny new Linksys WRT1900ACS to test.
>> 
>> I thought it might be nice to start with some comparisons of factory
>> firmware vs OpenWRT with sqm enabled.
>> 
>> So I built and installed an openwrt trunk but the results were very
>> non-impressive.  Rrul test reported mulit-seconds of latency and it was
>> equally non-impressive with sqm enabled or disabled.  So I assumed that sqm
>> in trunk on this device must not work yet.  Then I wondered how well sqm in
>> trunk was tested and that perhaps its broken for all devices.
>> 
>> So I tested openwrt trunk on my Netgear 3700v2 and saw the same results.
>> Then I tried openwrt cc and got the same results.
>> 
>> Finally, I went to the reference implementation: cerowrt 3.10.50-1 on my
>> 3700v2.  Same results.
>> 
>> So at this point I'm thinking there's a PEBKAC issue and I'm not really
>> turning it on.
>> 
>> Here's my enable procedure:
>> 
>> Go the sqm tab in the GUI and set egress and ingress to 10000, set the
>> interface to the upstream interface,  click enable, click save and apply.
>> Everything else is left at default. ie fq_codel and simple.qos.
>> 
>> I've also tried a reboot after enabling those settings and then gone back to
>> the gui to verify they were still set.
>> 
>> My test setup:
>> 
>> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>> 
>> I run netperf-wrapper -H Server -l 30 rrul and look at the 'totals' or 'all'
>> plot.
>> 
>> If I run the above with this setup.
>> 
>> Laptop<--1000baseT-->Server
>> 
>> Then I get the expected 800-900Mbit/s with latencies < 15ms.  So I don't
>> think there's a problem with my test infrastructure.
>> 
>> What am I missing and or what's the next step in figuring out whats wrong?
>> 
>> --
>> Richard A. Smith
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] Problems testing sqm

[Sebastian Moeller]

Hi David,


On Oct 24, 2015, at 18:34 , David P. Reed <dpreed@reed.com> wrote:

> Not trying to haggle.

	Sorry, I was a bit to grumpy for unrelated reasons.

> Just pointing out that this test configuration has a very short RTT. maybe too short for our SQM to adjust to.

	That could be, but I believe people have tested fq_codel and sqm with similar setups and generally got dozens of milliseconds induced delay, not multiple seconds. So sure sqm might not for the best thing but it should deliver a reasonable compromise. Now, I believe Toke has a test bed where he can vary the transmission delay so he might know already whether sqm has issues with 1GE lans.

Best Regards
	Sebastian

> 
> On Oct 24, 2015, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi David,
> 
> On Oct 24, 2015, at 00:53 , David P. Reed <dpreed@reed.com> wrote:
> 
> In particular, the DUT should probably have no more than 2 packets of outbound queueing given the very small RTT. 2xRTT is the most buffering you want in the loop.
> 
> Let’s not haggle about the precise amount of queueing we deem acceptable, as long as we all agree that >= 2 seconds is simply not acceptable ;) (the default sqm will approximately limit the latency under load increase (LULI) to roughly twice the target or typically 10 ms; note that this LULI only applies to unrelated flows). The exact number of queued packets seems to correlate with the beefiness of the DUT, the beefier the fewer packets should work, wimpier devices might need to batch some processing up, resulting in higher LULI…
> 
> Best Regards
> Sebastian
> 
> 
> On Oct 23, 2015, Richard Smith <smithbone@gmail.com> wrote:
> On 10/23/2015 02:41 PM, Michael Richardson wrote:
> Richard Smith <smithbone@gmail.com> wrote:
> My test setup:
> 
> Laptop<--1000BaseT-->DUT<--1000baseT-->Server
> 
> So, given that the DUT is the only real constraint in the network, what
> do you expect to see from this setup?
> 
> Given that the probably DUT can't forward at Gb/s, and it certainly can't
> shape anything, it's gonna drop packets, and it's probably gonna drop them in
> Rx, having overrun the Rx-queue (so tail-drop). If there is too much ram
> (bufferbloated), then you'll see different results...
> 
> Setting ingress/egress to 10Mbit/s I expected to see the speed 
> measurements bounce around those limits with the ping times staying in 
> the low double digits of ms. What I saw however, was the data rates 
> going well past 10Mbit limit and pings up to 2000 ms.
> 
> This is what I've seen in prior rrul testing using a the 50/10 cable 
> link at our office and my 25(ish)/6 link at my apartment and a well 
> connected server on the net. That however was using QoS and not SQM.
> 
> Its that a reasonable expectation?
> 
> -- Sent with K-@ Mail - the evolution of emailing.
> 
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 
> 
> -- Sent with K-@ Mail - the evolution of emailing.

Re: [Cerowrt-devel] Problems testing sqm

[Aaron Wood]

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

I've done the same setup in the past with my 3800, and htb limits just fine
to 10Mbps even when used with gigabit lab links.

So I think that, for whatever reason, htb just isn't functioning.

Dumping the qdiscs setup and stats using tc should make it clearer as to
what the state of things actually is.

-Aaron
On Sat, Oct 24, 2015 at 10:25 Sebastian Moeller <moeller0@gmx.de> wrote:

> Hi David,
>
>
> On Oct 24, 2015, at 18:34 , David P. Reed <dpreed@reed.com> wrote:
>
> > Not trying to haggle.
>
>         Sorry, I was a bit to grumpy for unrelated reasons.
>
> > Just pointing out that this test configuration has a very short RTT.
> maybe too short for our SQM to adjust to.
>
>         That could be, but I believe people have tested fq_codel and sqm
> with similar setups and generally got dozens of milliseconds induced delay,
> not multiple seconds. So sure sqm might not for the best thing but it
> should deliver a reasonable compromise. Now, I believe Toke has a test bed
> where he can vary the transmission delay so he might know already whether
> sqm has issues with 1GE lans.
>
> Best Regards
>         Sebastian
>
> >
> > On Oct 24, 2015, Sebastian Moeller <moeller0@gmx.de> wrote:
> > Hi David,
> >
> > On Oct 24, 2015, at 00:53 , David P. Reed <dpreed@reed.com> wrote:
> >
> > In particular, the DUT should probably have no more than 2 packets of
> outbound queueing given the very small RTT. 2xRTT is the most buffering you
> want in the loop.
> >
> > Let’s not haggle about the precise amount of queueing we deem
> acceptable, as long as we all agree that >= 2 seconds is simply not
> acceptable ;) (the default sqm will approximately limit the latency under
> load increase (LULI) to roughly twice the target or typically 10 ms; note
> that this LULI only applies to unrelated flows). The exact number of queued
> packets seems to correlate with the beefiness of the DUT, the beefier the
> fewer packets should work, wimpier devices might need to batch some
> processing up, resulting in higher LULI…
> >
> > Best Regards
> > Sebastian
> >
> >
> > On Oct 23, 2015, Richard Smith <smithbone@gmail.com> wrote:
> > On 10/23/2015 02:41 PM, Michael Richardson wrote:
> > Richard Smith <smithbone@gmail.com> wrote:
> > My test setup:
> >
> > Laptop<--1000BaseT-->DUT<--1000baseT-->Server
> >
> > So, given that the DUT is the only real constraint in the network, what
> > do you expect to see from this setup?
> >
> > Given that the probably DUT can't forward at Gb/s, and it certainly can't
> > shape anything, it's gonna drop packets, and it's probably gonna drop
> them in
> > Rx, having overrun the Rx-queue (so tail-drop). If there is too much ram
> > (bufferbloated), then you'll see different results...
> >
> > Setting ingress/egress to 10Mbit/s I expected to see the speed
> > measurements bounce around those limits with the ping times staying in
> > the low double digits of ms. What I saw however, was the data rates
> > going well past 10Mbit limit and pings up to 2000 ms.
> >
> > This is what I've seen in prior rrul testing using a the 50/10 cable
> > link at our office and my 25(ish)/6 link at my apartment and a well
> > connected server on the net. That however was using QoS and not SQM.
> >
> > Its that a reasonable expectation?
> >
> > -- Sent with K-@ Mail - the evolution of emailing.
> >
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
> >
> > -- Sent with K-@ Mail - the evolution of emailing.
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>

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

Re: [Cerowrt-devel] Problems testing sqm

[David P. Reed]

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

Understand.

On Oct 24, 2015, Jonathan Morton <chromatix99@gmail.com> wrote:
>
>> On 24 Oct, 2015, at 19:34, David P. Reed <dpreed@reed.com> wrote:
>>
>> Not trying to haggle. Just pointing out that this test configuration
>has a very short RTT. maybe too short for our SQM to adjust to.
>
>It should still get the bandwidth right.  When it does, we’ll know that
>the setup is correct.
>
> - Jonathan Morton

-- Sent with K-@ Mail - the evolution of emailing.

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

Re: [Cerowrt-devel] Problems testing sqm

[Richard Smith]

On 10/24/2015 01:21 PM, Sebastian Moeller wrote:

> But since cerowrt automatically disabled all off-loads and Richard
> saw his issues also with cerowrt, I am not sure whether this is his
> issue…

Here's an update:

I've been doing a lot of testing off and on over the weekend as time 
allows and currently I believe this problem is something in my network.

When I got home Friday night and started grabbing the tc -d qdisc info 
and re-running tests. Everything Just Worked both on the 3700v2 and on 
the 1900acs  Same device and no configuration changes.  Only difference 
is that I powered them off before I went to work.

So I started to try and re-create my steps for failure..  I _am_ able to 
duplicate the problem but I'm not able to figure out how.  It seems to 
just come and go irrespective of what I'm doing with the DUT.  I'm 
mostly in then bad state but every so often things work as expected.

So far I've played with routing the test(s) though a different 
10/100/1000 switch and using a different machine for the server.  Still 
using the same laptop but I've rebooted.  It's odd because I don't see 
the issue when I go direct from my laptop to the server.

Next going to try and set up an isolated test with just my laptop, DUT 
and a server and nothing else connected but I'm not sure if I'll get to 
that today.

Just for reference here's the requested tc -d qdisc on the 1900acs 
running my openwrt trunk build:

OpenWrt Designated Driver r47240 / LuCI Branch (git-15.294.53305-79383f5)

root@OpenWrt:~# tc -d qdisc
qdisc htb 1: dev eth0 root refcnt 9 r2q 10 default 12 
direct_packets_stat 0 ver 3.17 direct_qlen 532
qdisc fq_codel 110: dev eth0 parent 1:11 limit 1001p flows 1024 quantum 
300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 120: dev eth0 parent 1:12 limit 1001p flows 1024 quantum 
300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 130: dev eth0 parent 1:13 limit 1001p flows 1024 quantum 
300 target 5.0ms interval 100.0ms ecn
qdisc ingress ffff: dev eth0 parent ffff:fff1 ----------------
qdisc mq 0: dev eth1 root
qdisc fq_codel 0: dev eth1 parent :1 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :2 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :3 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :4 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :5 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :6 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :7 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :8 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc htb 1: dev ifb4eth0 root refcnt 2 r2q 10 default 10 
direct_packets_stat 0 ver 3.17 direct_qlen 32
qdisc fq_codel 110: dev ifb4eth0 parent 1:10 limit 1001p flows 1024 
quantum 300 target 5.0ms interval 100.0ms ecn

root@OpenWrt:~# /etc/init.d/sqm stop
SQM: /usr/lib/sqm/stop-sqm: Stopping eth0
SQM: ifb associated with interface eth0: ifb4eth0
SQM: /usr/lib/sqm/stop-sqm: ifb4eth0 shaper deleted
SQM: /usr/lib/sqm/stop-sqm: ifb4eth0 interface deleted
root@OpenWrt:~# tc -d qdisc
qdisc mq 0: dev eth0 root
qdisc fq_codel 0: dev eth0 parent :1 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth0 parent :2 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth0 parent :3 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth0 parent :4 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth0 parent :5 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth0 parent :6 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth0 parent :7 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth0 parent :8 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc mq 0: dev eth1 root
qdisc fq_codel 0: dev eth1 parent :1 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :2 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :3 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :4 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :5 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :6 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :7 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :8 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn

root@OpenWrt:~# /etc/init.d/sqm start
SQM: /usr/lib/sqm/start-sqm: Starting eth0
SQM: /usr/lib/sqm/start-sqm: Queue Setup Script: simple.qos
SQM: QDISC htb is useable.
SQM: QDISC fq_codel is useable.
SQM: Starting simple.qos
SQM: ifb associated with interface eth0:
SQM: Currently no ifb is associated with eth0, this is normal during 
starting of the sqm system.
SQM: Squashing differentiated services code points (DSCP) from ingress.
SQM: get_limit:  CURLIMIT: 1001
SQM: get_target defaulting to auto.
SQM: get_limit:  CURLIMIT: 1001
SQM: get_target defaulting to auto.
SQM: get_limit:  CURLIMIT: 1001
SQM: get_target defaulting to auto.
SQM: egress shaping activated
SQM: QDISC ingress is useable.
SQM: Do not perform DSCP based filtering on ingress. (1-tier classification)
SQM: get_limit:  CURLIMIT: 1001
SQM: get_target defaulting to auto.
SQM: ingress shaping activated
root@OpenWrt:~# tc -d qdisc
qdisc htb 1: dev eth0 root refcnt 9 r2q 10 default 12 
direct_packets_stat 0 ver 3.17 direct_qlen 532
qdisc fq_codel 110: dev eth0 parent 1:11 limit 1001p flows 1024 quantum 
300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 120: dev eth0 parent 1:12 limit 1001p flows 1024 quantum 
300 target 5.0ms interval 100.0ms ecn
qdisc fq_codel 130: dev eth0 parent 1:13 limit 1001p flows 1024 quantum 
300 target 5.0ms interval 100.0ms ecn
qdisc ingress ffff: dev eth0 parent ffff:fff1 ----------------
qdisc mq 0: dev eth1 root
qdisc fq_codel 0: dev eth1 parent :1 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :2 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :3 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :4 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :5 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :6 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :7 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc fq_codel 0: dev eth1 parent :8 limit 1024p flows 1024 quantum 300 
target 5.0ms interval 100.0ms ecn
qdisc htb 1: dev ifb4eth0 root refcnt 2 r2q 10 default 10 
direct_packets_stat 0 ver 3.17 direct_qlen 32
qdisc fq_codel 110: dev ifb4eth0 parent 1:10 limit 1001p flows 1024 
quantum 300 target 5.0ms interval 100.0ms ecn


Here's good/bad test files.

https://drive.google.com/folderview?id=0B-P0wCbNmKvAWnl6dUc1bVhMaU0&usp=sharing

Bad was run immediately after the above /etc/init.d/sqm start and tc -d 
qdisc commands. Good was something I got on Friday.

> Save this into a shell file, say my_func.sh, source it from the
> router’s shell “. ./my_func.sh”, and call “IFACE=eth0 eth_setup” for
> all interfaces to tackle.

I don't seem to have the necessary things in my openwrt build to run this:
root@OpenWrt:~# IFACE=eth0 eth_setup
-ash: ethtool: not found
-ash: ethtool: not found
-ash: ethtool: not found
-ash: ethtool: not found
-ash: get_mtu: not found
-ash: arithmetic syntax error

I'll make a new 1900acs build that includes that stuff.  In the meantime 
I'll switch back to cerowrt and 3700v2 for testing so I'm using a known 
working configuration.

-- 
Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Richard Smith]

On 10/25/2015 11:10 AM, Richard Smith wrote:

> So I started to try and re-create my steps for failure..  I _am_ able to
> duplicate the problem but I'm not able to figure out how.  It seems to
> just come and go irrespective of what I'm doing with the DUT.  I'm
> mostly in then bad state but every so often things work as expected.

I figured it out and now I feel _really_ stupid.  The problem was having 
WiFi enabled on my laptop.

The netperf server is running on a machine which sits on my 192.168.11.x 
network.  I've been testing things by connecting up the DUT WAN to that 
network and then using 192.168.1.x (or 172.30.42.x) as the DUT LAN side.

My wireless network is bridged to 192.168.11.x.. Yes, Yes, I know this 
is bad but I haven't put in the time to figure out how to configure 
things such that all the broadcast stuff like printers and chromecast 
Just Work in a routed world.  The SO gets unhappy with me when they are 
broken and it's difficult to explain the reasoning.  It's on the TODO.

network-manager automatically connects wlan0 to that network.

When I plug up the ethernet cable network-manager sets up eth0 as the 
default route but, doesn't shutdown existing wlan0 connections.  So 
talking to the DUT via ssh or http: works as expected. However, when I run:

netperf-wrapper -H server -l 15 --disable-log -p all rrul

If I forgot to turn off WiFi then I'm completely bypassing the DUT and 
testing my WiFi network instead. "This is not the network you are 
looking for."

Sigh.  Sorry for all the noise.  Thanks for everyones help. Now I'll get 
back to the original task of comparing the performance of the 1900acs 
factory firmware vs openwrt trunk with sqm.

-- 
Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Rich Brown]

Hi Richard,

> On Oct 25, 2015, at 12:07 PM, Richard Smith <smithbone@gmail.com> wrote:
> 
> Sigh.  Sorry for all the noise.  Thanks for everyones help. Now I'll get back to the original task of comparing the performance of the 1900acs factory firmware vs openwrt trunk with sqm.

Actually, this is a great relief to me (and, I imagine, the others on the list).

We really do believe in this stuff. We've seen it work. But each of us is enough of a scientist to believe that *we could be wrong*. (I suspect that's why you really got everyone's attention)

But, what a relief! Science Triumphs again! And now that we have a sound basis for understanding what was wrong, a) we have one more item for our troubleshooting questionnaire, and b) we can go back to feeling just a little bit smug :-)

Thanks for sticking with us. 

Rich

PS We'd love to hear the results of the experiment you really were trying to perform.

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Richard Smith]

On 10/25/2015 01:36 PM, Rich Brown wrote:

> We really do believe in this stuff. We've seen it work. But each of
> us is enough of a scientist to believe that *we could be wrong*. (I
> suspect that's why you really got everyone's attention)

Indeed.  An earlier version of the effort is running nicely on our 
gateway at work and that's what keeps the VoIP working.   I was pretty 
certain I was the source of the problem I just didn't know where.

> But, what a relief! Science Triumphs again! And now that we have a
> sound basis for understanding what was wrong, a) we have one more
> item for our troubleshooting questionnaire, and b) we can go back to
> feeling just a little bit smug :-)
>
> Thanks for sticking with us.

Absolutely, Thanks for being patient.

> Rich
>
> PS We'd love to hear the results of the experiment you really were
> trying to perform.

Working on it...  I've run into a small snag in that I can't seem to
return back to Linksys stock.  For some reason the flash upload goes
really, really, slow (I verified I'm using wired) and the upload times 
out before it completes.

scping the linksys image to /tmp and trying with sysupgrade doesn't work
either.  I thought being sort of based on openwrt it might work...

In the mean time I have some rrul logs running under designated driver. 
  I've put them here:

https://drive.google.com/folderview?id=0B-P0wCbNmKvANUY4bmZteGw5Wlk&usp=sharing

*nosqm* is with sqm disabled.

*sqm-<N>-<N>* is with the ingress/egress set to N in MBits/s.  using the
simple.qos discipline.

I'm happy to run any other tests if there is something specific desired.

Note: I deleted the previous files I shared since they were bogus.

I'm going to start playing wire wireless next.  There's noise in the 
forms that it may not be working very well but its mixed in with 
1200/1900AC so its hard to know how much applies to the ACS.

-- 
Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Sebastian Moeller]

Hi Richard,


On Oct 25, 2015, at 17:07 , Richard Smith <smithbone@gmail.com> wrote:

> On 10/25/2015 11:10 AM, Richard Smith wrote:
> 
>> So I started to try and re-create my steps for failure..  I _am_ able to
>> duplicate the problem but I'm not able to figure out how.  It seems to
>> just come and go irrespective of what I'm doing with the DUT.  I'm
>> mostly in then bad state but every so often things work as expected.
> 
> I figured it out and now I feel _really_ stupid.

	Why, the “I figured it out” part heavily argues against the stupid hypothesis, (it might not account for the feeling though ;) )

>  The problem was having WiFi enabled on my laptop.

	Ah, I guess wifi needs to be made fast ;)

> 
> The netperf server is running on a machine which sits on my 192.168.11.x network.  I've been testing things by connecting up the DUT WAN to that network and then using 192.168.1.x (or 172.30.42.x) as the DUT LAN side.
> 
> My wireless network is bridged to 192.168.11.x.. Yes, Yes, I know this is bad but I haven't put in the time to figure out how to configure things such that all the broadcast stuff like printers and chromecast Just Work in a routed world.  The SO gets unhappy with me when they are broken and it's difficult to explain the reasoning.  It's on the TODO.

	I fully understand that at a family home there is only so much experimentation that is tolerable, maybe unless the whole family is involved in CS or network engineering. I am lucky enough that we started without any network attached services so we went all routed with cerowrt and so far have not turned back (knock on wood), but once I switch to openwrt (which defaults to bridged) I will have to revisit this again...

> 
> network-manager automatically connects wlan0 to that network.

	I guess we can not even blame it for doing this, often people would be furious if it did not...

> 
> When I plug up the ethernet cable network-manager sets up eth0 as the default route but, doesn't shutdown existing wlan0 connections.  So talking to the DUT via ssh or http: works as expected. However, when I run:
> 
> netperf-wrapper -H server -l 15 --disable-log -p all rrul
> 
> If I forgot to turn off WiFi then I'm completely bypassing the DUT and testing my WiFi network instead.

	Simple in retrospect but tough to diagnose. I had a similar weir wifi issue: the 2.4GHz wlan in my proprietary ISP-supplied modem router, that I had left active as an emergency way to get into the modem and read the stats (which felt simpler at the time then teaching cerowrt to pass the traffic to the modem over the wan port as well; by then I had figured out the proper way, but had not disabled the AP, thinking this lives on a different band than my cerowrt router, so could not hurt and redundancy is good). But that radio has a “glitch” and roughly every 56 seconds it caused havoc on the modems traffic on all interfaces (wired and wlan) showing up as periodic spikes of bad induced latency under RRUL, took me ages to realize the root cause. The solution was quite simple, since the 5GHz radio in that unit behaves sanely and it is a one-out-of-two bands device I just switched the radio to 5GHz permanently...

> "This is not the network you are looking for.”

	You’d wish jedi mind tricks did not work on openwrt or sqm-scripts.

> 
> Sigh.  Sorry for all the noise.  Thanks for everyones help.

	This has been quite interesting. It also reminds me that “tc -s qdisc” is a thing to test early, looking at the statistics it should have been relatively easy to spot that there was too little traffic on the interfaces. Sidenote, I use if top on my laptop during similar tests, as it also allows to easily monitor different devices sequentially (I also like it as I believe that it also shows ACK traffic in the reverse direction which netperf unfortunately does not see).

> Now I'll get back to the original task of comparing the performance of the 1900acs factory firmware vs openwrt trunk with sqm.

	I am quite curious about the worst case performance, or the ingress+egress rate combination that keeps the latency increase under load sane with minimal packet size traffic. Mikael Abrahamsson did a lot of relevant testing in the following thread https://lists.bufferbloat.net/pipermail/cerowrt-devel/2015-June/004726.html . I believe he used iperf to allow manipulating the packet size, though I believe it should be possible to use the DUT’s MSS clamping function to achieve the same with netperf (which is a bit nicer in that it allows bidirectional saturating traffic with flent’s RRUL test easily). Since your unit uses the same/a similar SoC to the turris omni a that I want to get I am quite curious about the performance numbers you come up with. Especially with regards to offload functions and the relation between shaper rates and achieved transfer rates (see Aaron Wood’s posts about that at http://burntchrome.blogspot.de/2015/06/htb-rate-limiting-not-quite-lining-up.html )


Best Regards
	Sebastian

> 
> -- 
> Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Sebastian Moeller]

Hi Richard,

On Oct 25, 2015, at 21:02 , Richard Smith <smithbone@gmail.com> wrote:

> On 10/25/2015 01:36 PM, Rich Brown wrote:
> 
>> We really do believe in this stuff. We've seen it work. But each of
>> us is enough of a scientist to believe that *we could be wrong*. (I
>> suspect that's why you really got everyone's attention)
> 
> Indeed.  An earlier version of the effort is running nicely on our gateway at work and that's what keeps the VoIP working.   I was pretty certain I was the source of the problem I just didn't know where.
> 
>> But, what a relief! Science Triumphs again! And now that we have a
>> sound basis for understanding what was wrong, a) we have one more
>> item for our troubleshooting questionnaire, and b) we can go back to
>> feeling just a little bit smug :-)
>> 
>> Thanks for sticking with us.
> 
> Absolutely, Thanks for being patient.

	I believe we are a rather friendly bunch (but who does not have that self image) and will put observed data before theory any day ;)

> 
>> Rich
>> 
>> PS We'd love to hear the results of the experiment you really were
>> trying to perform.
> 
> Working on it...  I've run into a small snag in that I can't seem to
> return back to Linksys stock.  For some reason the flash upload goes
> really, really, slow (I verified I'm using wired) and the upload times out before it completes.

	Ihink I read in the openwrt forum people use the serial/jtag port for such things, but the memory is dim and the thread by now has reached like 900 pages or so...

> 
> scping the linksys image to /tmp and trying with sysupgrade doesn't work
> either.  I thought being sort of based on openwrt it might work...
> 
> In the mean time I have some rrul logs running under designated driver.  I've put them here:
> 
> https://drive.google.com/folderview?id=0B-P0wCbNmKvANUY4bmZteGw5Wlk&usp=sharing
> 
> *nosqm* is with sqm disabled.
> 
> *sqm-<N>-<N>* is with the ingress/egress set to N in MBits/s.  using the
> simple.qos discipline.

	Cool! I note it seems you are running an older flent version (or maybe even before the big rename, so netperf-wrapper). I think current flent includes enough improvements to merit a switch; I especially like “--remote-metadata=root@gw.home.lan” option to collect some data from the DUT automatically and save these into the output file, making it easy to answer a few question about the configuration used a few days/hours after the fact). 
	Also I want to note that if you shape ethernet you should use the link layer adaptation built into sqm (configurable via the GUI): Select Ethernet with overhead and specify the overhead to be: 24 Bytes (ethernet pre-amble & interframe gap & FCS,  Linux will have already accounted for MACs & frame type 14 bytes, you may need to add vlan tag (4 additional bytes)).

> 
> I'm happy to run any other tests if there is something specific desired.
> 
> Note: I deleted the previous files I shared since they were bogus.

	Ah, that got me confused, I see the new files just fine.

Best Regards
	Sebastian


> 
> I'm going to start playing wire wireless next.  There's noise in the forms that it may not be working very well but its mixed in with 1200/1900AC so its hard to know how much applies to the ACS.
> 
> -- 
> Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Richard Smith]

On 10/25/2015 04:33 PM, Sebastian Moeller wrote:

>>
>> Working on it...  I've run into a small snag in that I can't seem
>> to return back to Linksys stock.  For some reason the flash upload
>> goes really, really, slow (I verified I'm using wired) and the
>> upload times out before it completes.

> Ihink I read in the openwrt forum people use the serial/jtag port for
> such things, but the memory is dim and the thread by now has reached
> like 900 pages or so...

Well I was hoping to not have to crack open this router (for a change) 
I'll dig around more to see what I can find.

> Cool! I note it seems you are running an older flent version (or
> maybe even before the big rename, so netperf-wrapper). I think
> current flent includes enough improvements to merit a switch; I
> especially like “--remote-metadata=root@gw.home.lan” option to
> collect some data from the DUT automatically and save these into the
> output file, making it easy to answer a few question about the
> configuration used a few days/hours after the fact).

I am. Thats because new flent throws an exception on my laptop when I 
try to plot. My laptio is a hybird Ubuntu LTS 12.04.5. Hybrid in that I 
have lots of backports on it.

Traceback (most recent call last):
   File "/usr/local/bin/flent", line 9, in <module>
     load_entry_point('flent==0.12.4-git-31aed5e', 'console_scripts', 
'flent')()
   File 
"/usr/local/lib/python2.7/dist-packages/flent-0.12.4_git_31aed5e-py2.7.egg/flent/__init__.py", 
line 50, in run_flent
     b.run()
   File 
"/usr/local/lib/python2.7/dist-packages/flent-0.12.4_git_31aed5e-py2.7.egg/flent/batch.py", 
line 491, in run
     return self.run_test(self.settings, self.settings.DATA_DIR, True)
   File 
"/usr/local/lib/python2.7/dist-packages/flent-0.12.4_git_31aed5e-py2.7.egg/flent/batch.py", 
line 424, in run_test
     formatter.format([res])
   File 
"/usr/local/lib/python2.7/dist-packages/flent-0.12.4_git_31aed5e-py2.7.egg/flent/formatters.py", 
line 282, in format
     self.plotter.plot(results)
   File 
"/usr/local/lib/python2.7/dist-packages/flent-0.12.4_git_31aed5e-py2.7.egg/flent/plotters.py", 
line 297, in plot
     self.connect_interactive()
   File 
"/usr/local/lib/python2.7/dist-packages/flent-0.12.4_git_31aed5e-py2.7.egg/flent/plotters.py", 
line 347, in connect_interactive
     if self.interactive_callback or not self.can_highlight or not 
self.figure.canvas.supports_blit:
AttributeError: 'FigureCanvasQTAgg' object has no attribute 'supports_blit'

I've been meaning to file a bug, but just haven't gotten around to it yet.


> Also I want to
> note that if you shape ethernet you should use the link layer
> adaptation built into sqm (configurable via the GUI): Select Ethernet
> with overhead and specify the overhead to be: 24 Bytes (ethernet
> pre-amble & interframe gap & FCS,  Linux will have already accounted
> for MACs & frame type 14 bytes, you may need to add vlan tag (4
> additional bytes)).

Thanks.  I'll keep that in mind for future tests.


-- 
Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Jonathan Morton]

> On 25 Oct, 2015, at 18:07, Richard Smith <smithbone@gmail.com> wrote:
> 
> If I forgot to turn off WiFi then I'm completely bypassing the DUT and testing my WiFi network instead. "This is not the network you are looking for."

Yet another great argument for having proper blinkenlights on technical equipment - even at the consumer level.  By watching the lights, you might have noticed sooner that traffic wasn’t going the way you expected.

 - Jonathan Morton

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Richard Smith]

On 10/25/2015 05:50 PM, Jonathan Morton wrote:
>
>> On 25 Oct, 2015, at 18:07, Richard Smith <smithbone@gmail.com>
>> wrote:
>>
>> If I forgot to turn off WiFi then I'm completely bypassing the DUT
>> and testing my WiFi network instead. "This is not the network you
>> are looking for."
>
> Yet another great argument for having proper blinkenlights on
> technical equipment - even at the consumer level.  By watching the
> lights, you might have noticed sooner that traffic wasn’t going the
> way you expected.

Funny you should say that..  The blinking lights, or lack thereof, was 
the major clue that led to figuring it out.

While running one of the tests on the 3700 I happened to be staring at 
the router and noticed that the lights were not blinking as expected. 
"It's like there's no traffic...Oh crap, no way... " /me Facepalms.

-- 
Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm

[David Lang]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 483 bytes --]

On Sat, 24 Oct 2015, Jonathan Morton wrote:

>> On 24 Oct, 2015, at 19:34, David P. Reed <dpreed@reed.com> wrote:
>> 
>> Not trying to haggle. Just pointing out that this test configuration has a very short RTT. maybe too short for our SQM to adjust to.
>
> It should still get the bandwidth right.  When it does, we’ll know that the setup is correct.

bandwidth throttling is actually a much harder thing to do well under all 
conditiions than eliminating bufferbloat.

David Lang

Re: [Cerowrt-devel] Problems testing sqm

[Jonathan Morton]

> On 26 Oct, 2015, at 01:21, David Lang <david@lang.hm> wrote:
> 
> bandwidth throttling is actually a much harder thing to do well under all conditiions than eliminating bufferbloat.

That’s arguable, but when it goes wrong it usually results in underperformance rather than a firehose, assuming it’s working at all.

 - Jonathan Morton

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Toke Høiland-Jørgensen]

Richard Smith <smithbone@gmail.com> writes:

> I am. Thats because new flent throws an exception on my laptop when I try to
> plot. My laptio is a hybird Ubuntu LTS 12.04.5. Hybrid in that I have lots of
> backports on it.
>
> Traceback (most recent call last):
>   File "/usr/local/bin/flent", line 9, in <module>
>     load_entry_point('flent==0.12.4-git-31aed5e', 'console_scripts', 'flent')()
>   File
> "/usr/local/lib/python2.7/dist-packages/flent-0.12.4_git_31aed5e-py2.7.egg/flent/__init__.py",
> line 50, in run_flent
>     b.run()
>   File
> "/usr/local/lib/python2.7/dist-packages/flent-0.12.4_git_31aed5e-py2.7.egg/flent/batch.py",
> line 491, in run
>     return self.run_test(self.settings, self.settings.DATA_DIR, True)
>   File
> "/usr/local/lib/python2.7/dist-packages/flent-0.12.4_git_31aed5e-py2.7.egg/flent/batch.py",
> line 424, in run_test
>     formatter.format([res])
>   File
> "/usr/local/lib/python2.7/dist-packages/flent-0.12.4_git_31aed5e-py2.7.egg/flent/formatters.py",
> line 282, in format
>     self.plotter.plot(results)
>   File
> "/usr/local/lib/python2.7/dist-packages/flent-0.12.4_git_31aed5e-py2.7.egg/flent/plotters.py",
> line 297, in plot
>     self.connect_interactive()
>   File
> "/usr/local/lib/python2.7/dist-packages/flent-0.12.4_git_31aed5e-py2.7.egg/flent/plotters.py",
> line 347, in connect_interactive
>     if self.interactive_callback or not self.can_highlight or not
> self.figure.canvas.supports_blit:
> AttributeError: 'FigureCanvasQTAgg' object has no attribute 'supports_blit'
>
> I've been meaning to file a bug, but just haven't gotten around to it
> yet.

I'll save you the trouble: Try the newest git and see if that works
better :)

Ah, the joy of supporting multiple matplotlib versions...

-Toke

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Dave Taht]

I am extremely disappointed you deleted your (admittedly inadvertent)
wifi results.

Did you keep them anywhere? Now that we know what was wrong they
become way more interesting in the context of make-wifi-fast.
Dave Täht
I just invested five years of my life to making wifi better. And,
now... the FCC wants to make my work, illegal for people to install.
https://www.gofundme.com/savewifi


On Sun, Oct 25, 2015 at 9:02 PM, Richard Smith <smithbone@gmail.com> wrote:
> On 10/25/2015 01:36 PM, Rich Brown wrote:
>
>> We really do believe in this stuff. We've seen it work. But each of
>> us is enough of a scientist to believe that *we could be wrong*. (I
>> suspect that's why you really got everyone's attention)
>
>
> Indeed.  An earlier version of the effort is running nicely on our gateway
> at work and that's what keeps the VoIP working.   I was pretty certain I was
> the source of the problem I just didn't know where.
>
>> But, what a relief! Science Triumphs again! And now that we have a
>> sound basis for understanding what was wrong, a) we have one more
>> item for our troubleshooting questionnaire, and b) we can go back to
>> feeling just a little bit smug :-)
>>
>> Thanks for sticking with us.
>
>
> Absolutely, Thanks for being patient.
>
>> Rich
>>
>> PS We'd love to hear the results of the experiment you really were
>> trying to perform.
>
>
> Working on it...  I've run into a small snag in that I can't seem to
> return back to Linksys stock.  For some reason the flash upload goes
> really, really, slow (I verified I'm using wired) and the upload times out
> before it completes.
>
> scping the linksys image to /tmp and trying with sysupgrade doesn't work
> either.  I thought being sort of based on openwrt it might work...
>
> In the mean time I have some rrul logs running under designated driver.
> I've put them here:
>
> https://drive.google.com/folderview?id=0B-P0wCbNmKvANUY4bmZteGw5Wlk&usp=sharing
>
> *nosqm* is with sqm disabled.
>
> *sqm-<N>-<N>* is with the ingress/egress set to N in MBits/s.  using the
> simple.qos discipline.
>
> I'm happy to run any other tests if there is something specific desired.
>
> Note: I deleted the previous files I shared since they were bogus.
>
> I'm going to start playing wire wireless next.  There's noise in the forms
> that it may not be working very well but its mixed in with 1200/1900AC so
> its hard to know how much applies to the ACS.
>
> --
> Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Richard Smith]

On 10/26/2015 07:50 AM, Dave Taht wrote:
> I am extremely disappointed you deleted your (admittedly inadvertent)
> wifi results.

Oops, sorry. Trying to prevent confusion since they were misleading.

> Did you keep them anywhere? Now that we know what was wrong they
> become way more interesting in the context of make-wifi-fast.

It's google so they are never really gone. :) Restored.

https://drive.google.com/folderview?id=0B-P0wCbNmKvAWnl6dUc1bVhMaU0&usp=sharing

Note: They are apples to oranges.  What was marked as 1900acs "bad" was 
actually a WNDR3800 running OpenWrt Barrier Breaker r40727 / LuCI Trunk 
(svn-r10180).

If you want more WiFi traces with latency I can give you _loads_ of 
those. :)  From both here in my apt and at work.  Just tell me what you 
want.  I've got wndr3700v2's, Archer C7v2's, and now the Linksys 1900acs.

What I don't have is a laptop with an AC chipset only N.  I've got acess 
to a Mac Air with AC to test with, but so far its thwarted me on getting 
flent to work.  I need to research how to compile the netperf package 
with options using homebrew.  I'm still a total noob when using a Mac.

-- 
Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Richard Smith]

On 10/26/2015 07:17 AM, Toke Høiland-Jørgensen wrote:

>> I've been meaning to file a bug, but just haven't gotten around to it
>> yet.
>
> I'll save you the trouble: Try the newest git and see if that works
> better :)
>
> Ah, the joy of supporting multiple matplotlib versions...

As a matplotlib user myself I feel your pain.

Thank you.  Works now.

-- 
Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Sebastian Moeller]

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

Hi Richard,


On Oct 26, 2015, at 13:27 , Richard Smith <smithbone@gmail.com> wrote:

> On 10/26/2015 07:50 AM, Dave Taht wrote:
>> I am extremely disappointed you deleted your (admittedly inadvertent)
>> wifi results.
> 
> Oops, sorry. Trying to prevent confusion since they were misleading.
> 
>> Did you keep them anywhere? Now that we know what was wrong they
>> become way more interesting in the context of make-wifi-fast.
> 
> It's google so they are never really gone. :) Restored.
> 
> https://drive.google.com/folderview?id=0B-P0wCbNmKvAWnl6dUc1bVhMaU0&usp=sharing
> 
> Note: They are apples to oranges.  What was marked as 1900acs "bad" was actually a WNDR3800 running OpenWrt Barrier Breaker r40727 / LuCI Trunk (svn-r10180).
> 
> If you want more WiFi traces with latency I can give you _loads_ of those. :)  From both here in my apt and at work.  Just tell me what you want.  I've got wndr3700v2's, Archer C7v2's, and now the Linksys 1900acs.
> 
> What I don't have is a laptop with an AC chipset only N.  I've got acess to a Mac Air with AC to test with, but so far its thwarted me on getting flent to work.  I need to research how to compile the netperf package with options using homebrew.  I'm still a total noob when using a Mac.

	So, I have no recipe for home-brew, but I use the attached as local ports collection under macports to get flent to run:


[-- Attachment #2: macports.tar.gz --]
[-- Type: application/x-gzip, Size: 268695 bytes --]

[-- Attachment #3: Type: text/plain, Size: 2900 bytes --]



1) Unpack the archive into your home directory (it should net up in ~/macports or whatever name you choose).

2.a) Install macports (see https://www.macports.org/install.php ).

2.b) Edit /opt/local/etc/macports/sources.conf to contain:
	file:///Users/$USERNAME/macports
	make sure to replace $USERNAME with your real user name.

3) run the following command (to make sure you have all the current recipes):
	sudo port selfupdate

4) Cd into /Users/$USERNAME/macports and run (to add your local port definitions to the ):
	sudo portindex

5) install the prerequisites:
	sudo port install -cu git netperf fping py35-matplotlib-basemap qt4-mac
	These should drag in all the required dependencies, git is needed to clone flent itself, fping is needed as the bad ping in macosx (at least up to 10.9) does not have high-resolution timestamps IIRC, qt4-mac is required by the GUI, and py35-matplotlib-basemap is the shortest way to get python 3.5 with all required packages installed (short on the command line, this drags in quite a lot and will take a while, I hope you have something better than the current macbook to compile ;) )

6) Get flent, cd into the intended parent directory and call (or if you did already, call “git pull” in the flent directory to get Toke’s most recent in):
	git clone https://github.com/tohojo/flent

7) edit run-flent in the flent directory to point to the just installed python:
	#!/usr/bin/env python3.5
	You need to see where the just installed python 3.5 actually lives but I assume the above should work, just “#!/usr/bin/env python” will point to the system supplied python for which I have no clue how to install additional packages like the qt4 one required for the GUI. I have not tested whether this is required for 10.10 or 10.11, in any way installing all under macports is nice because to clean up afterwards all you need to do is remove /opt/local...

8) run it from the flent directory, e.g.:
	date ; ping -c 10 netperf-eu.bufferbloat.net ; ./run-flent --ipv4 -l 150 -H netperf-eu.bufferbloat.net rrul --remote-metadata=root@gw.home.lan -p all_scaled --disable-log -D . -t IPv4_test; date
and:
	date ; ping6 -c 10 netperf-eu.bufferbloat.net ; ./run-flent --ipv6 -l 150 -H netperf-eu.bufferbloat.net rrul --remote-metadata=root@gw.home.lan -p all_scaled --disable-log -D . -t IPv6_test: date

Just replace netperf-eu.bufferbloat.net with your netserver name or IP, with the ssh login to the DUT (I guess you need to set up passwordless login for this to work). But since you know flent this is just to keep the instruction complete enough to share with other mac users…

9) In case you routinely use macports remember to accasionally run:
	date ; sudo port selfupdate ; port outdated ; sudo port install outdated
	To get all the newest versions in...


Best Regards
	Sebastian


> 
> -- 
> Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Dave Taht]

in terms of testing wifi, the most useful series of tests to conduct
at the moment - since we plan to fix per station queuing soon - are
the rtt_fair tests, against multiple wifi stations. Run it all against
one station, then 2, then 4.
Dave Täht
I just invested five years of my life to making wifi better. And,
now... the FCC wants to make my work, illegal for people to install.
https://www.gofundme.com/savewifi


On Mon, Oct 26, 2015 at 2:41 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Richard,
>
>
> On Oct 26, 2015, at 13:27 , Richard Smith <smithbone@gmail.com> wrote:
>
>> On 10/26/2015 07:50 AM, Dave Taht wrote:
>>> I am extremely disappointed you deleted your (admittedly inadvertent)
>>> wifi results.
>>
>> Oops, sorry. Trying to prevent confusion since they were misleading.
>>
>>> Did you keep them anywhere? Now that we know what was wrong they
>>> become way more interesting in the context of make-wifi-fast.
>>
>> It's google so they are never really gone. :) Restored.
>>
>> https://drive.google.com/folderview?id=0B-P0wCbNmKvAWnl6dUc1bVhMaU0&usp=sharing
>>
>> Note: They are apples to oranges.  What was marked as 1900acs "bad" was actually a WNDR3800 running OpenWrt Barrier Breaker r40727 / LuCI Trunk (svn-r10180).
>>
>> If you want more WiFi traces with latency I can give you _loads_ of those. :)  From both here in my apt and at work.  Just tell me what you want.  I've got wndr3700v2's, Archer C7v2's, and now the Linksys 1900acs.
>>
>> What I don't have is a laptop with an AC chipset only N.  I've got acess to a Mac Air with AC to test with, but so far its thwarted me on getting flent to work.  I need to research how to compile the netperf package with options using homebrew.  I'm still a total noob when using a Mac.
>
>         So, I have no recipe for home-brew, but I use the attached as local ports collection under macports to get flent to run:
>
>
>
>
> 1) Unpack the archive into your home directory (it should net up in ~/macports or whatever name you choose).
>
> 2.a) Install macports (see https://www.macports.org/install.php ).
>
> 2.b) Edit /opt/local/etc/macports/sources.conf to contain:
>         file:///Users/$USERNAME/macports
>         make sure to replace $USERNAME with your real user name.
>
> 3) run the following command (to make sure you have all the current recipes):
>         sudo port selfupdate
>
> 4) Cd into /Users/$USERNAME/macports and run (to add your local port definitions to the ):
>         sudo portindex
>
> 5) install the prerequisites:
>         sudo port install -cu git netperf fping py35-matplotlib-basemap qt4-mac
>         These should drag in all the required dependencies, git is needed to clone flent itself, fping is needed as the bad ping in macosx (at least up to 10.9) does not have high-resolution timestamps IIRC, qt4-mac is required by the GUI, and py35-matplotlib-basemap is the shortest way to get python 3.5 with all required packages installed (short on the command line, this drags in quite a lot and will take a while, I hope you have something better than the current macbook to compile ;) )
>
> 6) Get flent, cd into the intended parent directory and call (or if you did already, call “git pull” in the flent directory to get Toke’s most recent in):
>         git clone https://github.com/tohojo/flent
>
> 7) edit run-flent in the flent directory to point to the just installed python:
>         #!/usr/bin/env python3.5
>         You need to see where the just installed python 3.5 actually lives but I assume the above should work, just “#!/usr/bin/env python” will point to the system supplied python for which I have no clue how to install additional packages like the qt4 one required for the GUI. I have not tested whether this is required for 10.10 or 10.11, in any way installing all under macports is nice because to clean up afterwards all you need to do is remove /opt/local...
>
> 8) run it from the flent directory, e.g.:
>         date ; ping -c 10 netperf-eu.bufferbloat.net ; ./run-flent --ipv4 -l 150 -H netperf-eu.bufferbloat.net rrul --remote-metadata=root@gw.home.lan -p all_scaled --disable-log -D . -t IPv4_test; date
> and:
>         date ; ping6 -c 10 netperf-eu.bufferbloat.net ; ./run-flent --ipv6 -l 150 -H netperf-eu.bufferbloat.net rrul --remote-metadata=root@gw.home.lan -p all_scaled --disable-log -D . -t IPv6_test: date
>
> Just replace netperf-eu.bufferbloat.net with your netserver name or IP, with the ssh login to the DUT (I guess you need to set up passwordless login for this to work). But since you know flent this is just to keep the instruction complete enough to share with other mac users…
>
> 9) In case you routinely use macports remember to accasionally run:
>         date ; sudo port selfupdate ; port outdated ; sudo port install outdated
>         To get all the newest versions in...
>
>
> Best Regards
>         Sebastian
>
>
>>
>> --
>> Richard A. Smith
>
>

Re: [Cerowrt-devel] ***UNCHECKED*** Re: Problems testing sqm (solved)

[Toke Høiland-Jørgensen]

Sebastian Moeller <moeller0@gmx.de> writes:

> 	So, I have no recipe for home-brew, but I use the attached as
> 	local ports collection under macports to get flent to run:

You mind if I put this tutorial into the Flent docs? Or I can link to
them if you want to post it somewhere yourself :)

-Toke

Re: [Cerowrt-devel] ***UNCHECKED*** Re: Problems testing sqm (solved)

[Sebastian Moeller]

Hi Toke,

On Oct 26, 2015, at 14:50 , Toke Høiland-Jørgensen <toke@toke.dk> wrote:

> Sebastian Moeller <moeller0@gmx.de> writes:
> 
>> 	So, I have no recipe for home-brew, but I use the attached as
>> 	local ports collection under macports to get flent to run:
> 
> You mind if I put this tutorial into the Flent docs?

	Not at all; I am not sure whether a) this is the minimal set and b) whether it fully works as advertised, so maybe waiting for Richards potential success/failure report might be prudent? I basically recreated that from memory and that is a leaky resource… I just did check “sudo port install -cu py35-matplotlib-basemap”, and the edit to run-flent, and it turns out I missed a dependency on py35-pyqt4, so step 5) should be:

sudo port install -cu git netperf fping py35-matplotlib-basemap qt4-mac py35-pyqt4

That seems to work okay (well I just loaded an old data file and looked at two plots, so it still might be broken, but at least not fully...)

Then again as a starting point this might be better than nothing...

> Or I can link to
> them if you want to post it somewhere yourself :)

	Oh, if at all this belongs to flent, I have no platform established to post anything anywhere, so please, if you are willing to host it on flent.org go for it.

Best Regards
	Sebastian

> 
> -Toke

Re: [Cerowrt-devel] Problems testing sqm (solved)

[David Lang]

On Mon, 26 Oct 2015, Dave Taht wrote:

> in terms of testing wifi, the most useful series of tests to conduct
> at the moment - since we plan to fix per station queuing soon

how soon is 'soon'? I'm going to be building my image for Scale in the next few 
weeks, any chance of having this available to put in it?

David Lang

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Sebastian Moeller]

Hi David,

On Oct 26, 2015, at 19:15 , David Lang <david@lang.hm> wrote:

> On Mon, 26 Oct 2015, Dave Taht wrote:
> 
>> in terms of testing wifi, the most useful series of tests to conduct
>> at the moment - since we plan to fix per station queuing soon
> 
> how soon is 'soon'? I'm going to be building my image for Scale in the next few weeks, any chance of having this available to put in it?

	Oh, interesting, slightly related question, do you typically disable offloads for your scale deployed APs, or do you run with them enabled? (I am pondering whether to expose a n offload toggle in luci-ap-sqm, but that only makes sense if there are users willing to test the functionality more often than once off). (Then again you probably do not use the GUI in the first place in your deployment ;) or?)

Best Regards
	Sebastian

> 
> David Lang

Re: [Cerowrt-devel] Problems testing sqm (solved)

[David Lang]

On Mon, 26 Oct 2015, Sebastian Moeller wrote:

> Hi David,
>
> On Oct 26, 2015, at 19:15 , David Lang <david@lang.hm> wrote:
>
>> On Mon, 26 Oct 2015, Dave Taht wrote:
>>
>>> in terms of testing wifi, the most useful series of tests to conduct
>>> at the moment - since we plan to fix per station queuing soon
>>
>> how soon is 'soon'? I'm going to be building my image for Scale in the next 
>> few weeks, any chance of having this available to put in it?
>
> 	Oh, interesting, slightly related question, do you typically disable 
> offloads for your scale deployed APs, or do you run with them enabled? (I am 
> pondering whether to expose a n offload toggle in luci-ap-sqm, but that only 
> makes sense if there are users willing to test the functionality more often 
> than once off). (Then again you probably do not use the GUI in the first place 
> in your deployment ;) or?)

I'm using WNDR3800's again this year (~120 of them). I don't believe that it 
uses offloads in the first place.

The APs operate in bridged mode connecting to the local wired network. A 
separate firewall/DHCP/etc server provides the Internet connectivity.

see 
https://www.usenix.org/conference/lisa12/technical-sessions/presentation/lang_david_wireless 
for details on what I did a few years ago. This year we are moving to a new, 
larger location, but the same strategy is going to be used.

David Lang

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Richard Smith]

On 10/26/2015 09:48 AM, Dave Taht wrote:
> in terms of testing wifi, the most useful series of tests to conduct
> at the moment - since we plan to fix per station queuing soon - are
> the rtt_fair tests, against multiple wifi stations. Run it all against
> one station, then 2, then 4.

In that scenario are you flipping the roles?  ie what I've been thinking 
of as a the wired "server" becomes the client talking to netperf servers 
running on each station? or is it station to station(s)?

Involving more stations is a bit more difficult.  I don't have that many 
at my apt and using more stations at work is tricky since people are 
using them. :)  I might be able to recruit a few machines though.

-- 
Richard A. Smith

Re: [Cerowrt-devel] ***UNCHECKED*** Re: Problems testing sqm (solved)

[Richard Smith]

On 10/26/2015 10:30 AM, Sebastian Moeller wrote:
> Hi Toke,
>
> On Oct 26, 2015, at 14:50 , Toke Høiland-Jørgensen <toke@toke.dk>
> wrote:
>
>> Sebastian Moeller <moeller0@gmx.de> writes:
>>
>>> So, I have no recipe for home-brew, but I use the attached as
>>> local ports collection under macports to get flent to run:
>>
>> You mind if I put this tutorial into the Flent docs?
>
> Not at all; I am not sure whether a) this is the minimal set and b)
> whether it fully works as advertised, so maybe waiting for Richards
> potential success/failure report might be prudent?

The homebrew part turned out to be pretty easy.

Edit the netperf.rb file to include --enable-demo

Then:

brew install netperf.rb --build-from-source

What was much more involved was getting the Mac to a place where you 
could actually build programs.  Have to update Xcode, agree to license 
agreements, and then install command line tools.

'brew doctor'

Is super helpful in sorting all that out.  I see why they had to create it.

BUT, The netperf compile will fail when using --enable-demo.  See here:

http://www.netperf.org/pipermail/netperf-talk/2013-December/001160.html

So in the end I had to resort to extracting the tarball and editing the 
source to remove the inline on the problematic functions and then good 
ol' ./configure; make; sudo make install;  Which surprisingly worked.  I 
think thats because 'brew doctor' sorted out all the stuff that would 
have otherwise been broken.

And then finally 'brew install fping'

So now I've got flent working now on the Mac Air.

I should also mention that 'brew install qt' is necessary if you want to 
show plots.

-- 
Richard A. Smith

Re: [Cerowrt-devel] ***UNCHECKED*** Re: Problems testing sqm (solved)

[Richard Smith]

On 10/26/2015 05:54 PM, Richard Smith wrote:

> So now I've got flent working now on the Mac Air.
>
> I should also mention that 'brew install qt' is necessary if you want to
> show plots.

correction that should be 'brew install pyqt' which will also install qt 
as a dependency.

-- 
Richard A. Smith

Re: [Cerowrt-devel] Problems testing sqm (solved)

[Richard Smith]

On 10/26/2015 05:01 PM, Richard Smith wrote:

> On 10/26/2015 09:48 AM, Dave Taht wrote:
>> in terms of testing wifi, the most useful series of tests to conduct
>> at the moment - since we plan to fix per station queuing soon - are
>> the rtt_fair tests, against multiple wifi stations. Run it all against
>> one station, then 2, then 4.

rtt_fair appears to try and contact snapon which isn't working.

Is there a testing recipe up anywhere?


-- 
Richard A. Smith