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
o
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
On Mon, 26 Oct 2015, Sebastian Moeller wrote:
Hi David,
On Oct 26, 2015, at 19:15 , David Lang 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
Hi David,
On Oct 26, 2015, at 19:15 , David Lang 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 f
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 t
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
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 mysel
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
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
Richard Smith 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
> load_en
> On 26 Oct, 2015, at 01:21, David Lang 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
On Sat, 24 Oct 2015, Jonathan Morton wrote:
On 24 Oct, 2015, at 19:34, David P. Reed 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
On 10/25/2015 05:50 PM, Jonathan Morton wrote:
On 25 Oct, 2015, at 18:07, Richard Smith
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
> On 25 Oct, 2015, at 18:07, Richard Smith 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 -
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 r
Hi Richard,
On Oct 25, 2015, at 21:02 , Richard Smith 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'
Hi Richard,
On Oct 25, 2015, at 17:07 , Richard Smith 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 o
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
Hi Richard,
> On Oct 25, 2015, at 12:07 PM, Richard Smith 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
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 of
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 cur
Understand.
On Oct 24, 2015, Jonathan Morton wrote:
>
>> On 24 Oct, 2015, at 19:34, David P. Reed 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 i
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
Hi David,
On Oct 24, 2015, at 18:34 , David P. Reed 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 beli
Hi Dave,
On Oct 24, 2015, at 12:20 , Dave Taht 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
a
> On 24 Oct, 2015, at 19:34, David P. Reed 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.
- Jonath
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 wrote:
>Hi David,
>
>On Oct 24, 2015, at 00:53 , David P. Reed wrote:
>
>> In particular, the DUT should probably have no more
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 ye
Hi David,
On Oct 24, 2015, at 00:53 , David P. Reed 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 w
Hi David,
On Oct 24, 2015, at 00:48 , David P. Reed 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) b
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 wrote:
>On 10/23/2015 02:41 PM, Michael Richardson wrote:
>> Richard Smith wrote:
>> > My tes
On Fri, Oct 23, 2015 at 1:18 PM, Richard Smith wrote:
> On 10/23/2015 02:41 PM, Michael Richardson wrote:
>
>> Richard Smith wrote:
>> > My test setup:
>>
>> > Laptop<--1000BaseT-->DUT<--1000baseT-->Server
>>
>> So, given that the DUT is the only real constraint in the network, what
>>
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 wrote:
>On 10/23/2015 02:41 PM, Michael Richardson wrote:
>> Richard Smi
On 10/23/2015 02:41 PM, Michael Richardson wrote:
Richard Smith 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 for
Hi David,
On Oct 23, 2015, at 19:57 , David Lang wrote:
> On Fri, 23 Oct 2015, Aaron Wood wrote:
>
>> On Fri, Oct 23, 2015 at 9:10 AM, Richard Smith wrote:
>>
>>> I have a shiny new Linksys WRT1900ACS to test.
>>>
>>> I thought it might be nice to start with some comparisons of factory
>>> f
Richard Smith 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,
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 configuratio
On Fri, 23 Oct 2015, Aaron Wood wrote:
On Fri, Oct 23, 2015 at 9:10 AM, Richard Smith 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 (
Hi Richard,
On Oct 23, 2015, at 19:30 , Richard Smith wrote:
> On 10/23/2015 01:02 PM, Alan Jenkins wrote:
>
>>> Go the sqm tab in the GUI and set egress and ingress to 1, set the
>>> interface to the upstream interface, click enable, click save and
>>> apply. Everything else is left at de
On 10/23/2015 01:22 PM, Aaron Wood wrote:
On Fri, Oct 23, 2015 at 9:10 AM, Richard Smith mailto:smithb...@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.
Hi Aaron,
On Oct 23, 2015, at 19:22 , Aaron Wood wrote:
>
>
> On Fri, Oct 23, 2015 at 9:10 AM, Richard Smith 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
Hi Alan, hi Richard,
On Oct 23, 2015, at 19:02 , Alan Jenkins
wrote:
> On 23/10/2015, Richard Smith 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 an
Hi Richard,
On Oct 23, 2015, at 18:43 , Richard Smith 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
Hi Richard,
On Oct 23, 2015, at 18:10 , Richard Smith 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
On 10/23/2015 01:02 PM, Alan Jenkins wrote:
Go the sqm tab in the GUI and set egress and ingress to 1, 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
On Fri, Oct 23, 2015 at 9:10 AM, Richard Smith 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 f
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 e
On 23/10/2015, Richard Smith 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
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 1. Well within the range
of th
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
__
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 wrote:
>
> you are most likely applying the qdisc to the wrong ethernet
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, Ric
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
53 matches
Mail list logo
