[Cerowrt-devel] 3.3rc7-5 is out

[Dave Taht]

On Fri, Mar 16, 2012 at 7:32 PM, Sebastian Moeller <moeller0 at 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 at 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 at 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 at 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