[Cerowrt-devel] 3.3rc7-5 is out

[Cerowrt-devel] 3.3rc7-5 is out

[Dave Taht]

I had some issues in getting this build done. It won't be buildable by
others, either. There was some churn in the related patch sets. In
particular some xtables stuff broke that I'm not going to check my
hacks for into the repo.

I needed something stable enough for ietf next week and I hope this is
it. If it isn't, well... we'll see.

Notes:

0) this has the latest and greatest dnsmasq in it, which has
increasing amounts of dhcpv6 and ra support in it.

1) The configuration for 6to4 is now disabled by default. About the
only place it ever worked well was on comcast. Recently a new bug
cropped up where it was only distributing one interface address...

And it irked me in the lab, where I have native ipv6, and am working on PD...

(it can still be enabled via the gui or by uncommenting the stuff)

2) As noted in a previous missive the default ipv6 firewall rules need work.


-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: [Cerowrt-devel] 3.3rc7-5 is out

[Dave Taht]

On Fri, Mar 16, 2012 at 7:32 PM, Sebastian Moeller <moeller0@gmx.de> wrote:
> Hi Dave,
>
>
> On Mar 16, 2012, at 6:45 PM, Dave Taht wrote:
>
>> heh. Leave AQM undocumented for now. It's got issues on ingress.
>
>        Pooh, and I thought I had fudged my instance of AQM so ingress broke :). BTW is there an easy way to get the most recent debloat script directly from cerowrt?

sure, but it won't help. You can just slam the debloat script from the
deBloat repo on github on there...

0) In most asymmetric situations ingress control doesn't matter
anywhere near as much as egress.

1) Ingress issue is pesky. I don't get what's going wrong. It's
something v6 related, I think.

2) There are not 1, but 4 out-of-tree versions of the debloat script
now - one each for 4Mbit comcast, 9Mbit comcast, 26Mbit FIOS, and
15Mbit DSL.

all with pretty widely different configurations.

The data points collected thus far are quite resistant to algorithmic
analysis, and are very kernel and workload dependent. Worse, at higher
speeds (60Mbit and above) running tests on the router itself
heisenbugs the results.

Here are the variables:

tx ring size. Presently 4 by default. Last year, at really low speed
uplinks, 2 was better than 4. Above 60Mbit, 4 is not enough.

bql seems to do the job without fiddling with this anymore, I tend to
use 16 or 32 these days for tx ring.

bql size. Depending on the script involved this varies from automatic
(which is usually about 8x bigger than what
seems 'right'), to 3k (which is good up to about 110Mbit), to about
18k (up to 260Mbit)

sfqred related stuff

limit - range of 200-300 seems to work up to about 80-120Mbit. I'll
argue based on the data in point 4, below, that in the real world it
needs to be more kleinrock-like, with a large estimate for flows.

min =3k
max =18k
probability ranges of .12 to .2
redflowlimit - presently very small, not suitable for much more than 60Mbit/sec

Tuning all the above is tricky, and sfq changes how you have to think
about how red works...

htb and htb quantum size - at low rates, you want a minimal quantum,
at higher rates... don't know...

ecn works GREAT. And most of my data is with ecn on. ecn off changes matters....

It's a hell of a few data points to extrapolate from...

3) a portion of sfqred I depended upon was just pulled out of the
mainline patch set due to some starvation issues observed. I just
plain don't see these issues with any test I come up with with sfq+red
enabled, but it was easy for the reporter to mess up sfq itself...

http://www.spinics.net/lists/netdev/msg191682.html

I'm gonna hate losing this in the general case, and unless I can make
it happen with sfqred, I'm going to keep this feature in cerowrt 3.3.

So... I'm still trying to get the lab built up...

>
> Best
>        Sebastian
>
>>
>> On Fri, Mar 16, 2012 at 6:40 PM, Richard Brown
>> <richard.e.brown@dartware.com> wrote:
>>> I just installed 3.3-rc7-5 and all seems fine in my limited testing.
>>>
>>> I see there's a Network -> AQM tab in the GUI. It seems similar to the QoS tab.
>>>
>>> Should the doc's tell people to use the same procedure as the QoS? That is, should people
>>>
>>> - Disable QoS (the default is disabled)
>>> - Run a speed test, say on http://speedtest.net
>>> - Enable QoS, and set the download and upload speeds to a few percent less than the speedtest indicates.
>>>
>>> Thanks.
>>>
>>>
>>> _______________________________________________
>>> Cerowrt-devel mailing list
>>> Cerowrt-devel@lists.bufferbloat.net
>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>>
>>
>>
>> --
>> Dave Täht
>> SKYPE: davetaht
>> US Tel: 1-239-829-5608
>> http://www.bufferbloat.net
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: [Cerowrt-devel] 3.3rc7-5 is out

[Sebastian Moeller]

Hi Dave,


On Mar 16, 2012, at 6:45 PM, Dave Taht wrote:

> heh. Leave AQM undocumented for now. It's got issues on ingress.

	Pooh, and I thought I had fudged my instance of AQM so ingress broke :). BTW is there an easy way to get the most recent debloat script directly from cerowrt?

Best
	Sebastian

> 
> On Fri, Mar 16, 2012 at 6:40 PM, Richard Brown
> <richard.e.brown@dartware.com> wrote:
>> I just installed 3.3-rc7-5 and all seems fine in my limited testing.
>> 
>> I see there's a Network -> AQM tab in the GUI. It seems similar to the QoS tab.
>> 
>> Should the doc's tell people to use the same procedure as the QoS? That is, should people
>> 
>> - Disable QoS (the default is disabled)
>> - Run a speed test, say on http://speedtest.net
>> - Enable QoS, and set the download and upload speeds to a few percent less than the speedtest indicates.
>> 
>> Thanks.
>> 
>> 
>> _______________________________________________
>> Cerowrt-devel mailing list
>> Cerowrt-devel@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/cerowrt-devel
> 
> 
> 
> -- 
> Dave Täht
> SKYPE: davetaht
> US Tel: 1-239-829-5608
> http://www.bufferbloat.net
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel

Re: [Cerowrt-devel] 3.3rc7-5 is out

[Dave Taht]

heh. Leave AQM undocumented for now. It's got issues on ingress.

On Fri, Mar 16, 2012 at 6:40 PM, Richard Brown
<richard.e.brown@dartware.com> wrote:
> I just installed 3.3-rc7-5 and all seems fine in my limited testing.
>
> I see there's a Network -> AQM tab in the GUI. It seems similar to the QoS tab.
>
> Should the doc's tell people to use the same procedure as the QoS? That is, should people
>
> - Disable QoS (the default is disabled)
> - Run a speed test, say on http://speedtest.net
> - Enable QoS, and set the download and upload speeds to a few percent less than the speedtest indicates.
>
> Thanks.
>
>
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel



-- 
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
http://www.bufferbloat.net

Re: [Cerowrt-devel] 3.3rc7-5 is out

[Richard Brown]

I just installed 3.3-rc7-5 and all seems fine in my limited testing. 

I see there's a Network -> AQM tab in the GUI. It seems similar to the QoS tab. 

Should the doc's tell people to use the same procedure as the QoS? That is, should people

- Disable QoS (the default is disabled)
- Run a speed test, say on http://speedtest.net
- Enable QoS, and set the download and upload speeds to a few percent less than the speedtest indicates.

Thanks.