[Cerowrt-devel] question regarding OpenWrt vs. CeroWrt

[Dave Taht]

On Fri, Feb 10, 2012 at 4:31 PM, Tobias Wolf <towolf at gmail.com> wrote:
> Salve,
>
> I’m just a random user of Openwrt that is not convinced that its
> qos-scripts is doing a good job. I have a quick question.

qos-scripts is fouling up pretty badly.

>
> I’ve built OpenWrt trunk today and there was a commit mentioning your
> name, so I googled you. I found the CeroWrt feature tracker where you
> point out the defects of qos-scripts ("We can do better").


>
> My question is, do you see possible medium-term fixes to qos-scripts to
> be made to OpenWrt trunk, or does all this stuff have to cook for longer
> in CeroWrt?

I am not quite at the point to where I can effectively simulate or measure
various workloads. I have to completely rebuild bloatlab #1, to do so,
and that's in california. I'm trying to pull together enough spare cash
to make that trip at a time that all the pieces now in loose formation
have stablized enough for wider scale testing.

I'm really reluctant to make any fixes at all to the qos-scripts until
I can measure what they do currently effectively.

Certainly I look at what they do for a 4Mbit upload system, and
shudder, with 16000 buffers for one htb tier and a setting for
red that looks to be utterly ineffective.

http://www.bufferbloat.net/issues/331

> That is, do you see yourself fixing qos-scripts itself to at
> least get a little better, or would an interested user have have to

I do plan to improve qos-scripts in the form they are currently in.

I am also building an alternate package (aqm-scripts) in
the ceropackages repo and the cerowrt-luci repo that I
hope one day could supplant it entirely.

Regrettably the above requires patches to the 3.2 kernel (or 3.3)
and an update to iproute2.

So it is possible to move a version of openwrt ahead to take
advantage of this stuff by applying several of the patches here:

http://huchra.bufferbloat.net/~cero1/openwrt-bql-patches/

(some of which just landed in opewrt head this morning)

But I note the 3.2 backport of BQL and related is currently
specific to the ar71xx hardware (although it needent be)

Is there a specific platform you'd like to be playing with?

> adopt the full experimental bufferbloat stack? i.e. are there quick
> fixes on the horizon (given Openwrt trunk)?

There are multiple fixes on the horizon for openwrt trunk.

3.2 based kernels have an actually working version of RED in them.
3.3 based kernels have a version of SFQ that enqueues new flows
at queue head (and also sfqred, and a few other cool things)

Both of these features qos-scripts will take advantage automatically

I have a grave concern that the new SFQ is actually 'too good'

http://www.bufferbloat.net/issues/332

And hope to resolve that with eric, jesper, etc before 3.3

All that said, the calculations that qos-scripts perform result in really
overlong buffer lengths, and don't appear to deal with ipv6 properly.

The latter is easy to fix, the former is rather resistant to formuliac
analysis. And there are side effects from both BQL and HTB that
need to be accounted for, notably manipulating tx queue and tx ring
depth 'right'.

I have good values for 'Too D*** Big', and 'Too D*** small', but 'Just right',
or merely,  'Not horrible', are thus far elusive.


>
> thanks,
> Tobias
>
>
>



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