[Cerowrt-devel] cerowrt-3.10.24-5 dev build released

[Dave Taht]

On Fri, Dec 20, 2013 at 1:01 PM, Sebastian Moeller <moeller0 at gmx.de> wrote:
> Hi Dave,
>
>
> On Dec 20, 2013, at 19:01 , Dave Taht <dave.taht at gmail.com> wrote:
>
>> I wanted to say how much I was enjoying catching up on this thread.
>>
>> I think only one question came up for me during it, which is support
>> for a bfifo and pfifo qdisc? (if I missed something let me know )
>> Support for these are darn useful for the research and I have long
>> meant to fold in the modified code I use for that. Byte limits are
>> very common for cable and dsl technologies and doing tests with
>> 64k,128k,256k, and 512k bfifos is quite revealing. (I have a ton of
>> plots lying about for this, I should put them up somewhere)
>>
>> Sooo... I just checked in the limit stuff (untested) into aqm-scripts.
>> It requires that the limit option be dynamic and exposed to the gui,
>> and in the case of a bfifo is a byte limit rather than a packet limit.
>> There needs to be sane values for limit clamped somehow, as 1000 bytes
>> would be bad, and 512000 packets would be bad also.
>>
>
>         I just noticed we probably should go for ingress_Limit and egress_Limit as there are different in simple_qos.sh, I assume for a good reason…


I am not huge on CamelCase or HungarianNotation, or iThinkThis, btw.
The way I tend to think about things is that shell environment
variables tend to be ALLCAPS, and that C and openwrt uci variables
tend to be lowercase. I'm not big on under_scores as they are somewhat
hard to see, and I'm not really sure what luci's PreferredSyntax (?)
is. There are now several different styles running through the
aqm-scripts....

But that said, yes, breaking apart the two limits for egress and
ingress makes sense particularly for the byte limits, where you might
be be emulating a dslam (64k bytes) on one side, and a dumb modem
(256k bytes) on the other.

Elsewhere, prior to now, the limits were there merely to keep memory
usage under control. There is no need for 10k packets worth of
buffering. There is not much need for more than 600 packets ever at
the speeds we are running at today, and usually are in the dozens, so
I'd defaulted to 600 packets on egress and 1000 on ingress as being
big enough limits to nearly never hit on pie and fq_codel.

I really do hate having more knobs that can be messed up.

>
> best
>         sebastian
>
>
>> As for folding the selection of bfifo or pfifo into the gui, it's not
>> clear that we are doing "researcher mode", vs "mom mode" in a suitably
>> abstract way. Certainly I can imagine many a researcher wanting the
>> gui.
>>
>> While I'm at it, there are some statistics like drops, and backlog,
>> etc, that a gui-ish interface might help.
>>
>> polling tc -s qdisc show dev ge00 # and/or class show dev ge00
>>
>> I am curious if anyone is seeing the DMA tx error in 3.10.24-5? I have
>> one box that has now been up 4.4 days with no errors, but I haven't
>> pushed it. I'll be beating it up through the weekend and taking a look
>> at the gui work so far.
>



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html