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

[Sebastian Moeller <moeller0@gmx.de>]

Dave Taht <dave.taht@gmail.com> wrote:
>On Fri, Dec 20, 2013 at 1:01 PM, Sebastian Moeller <moeller0@gmx.de>
>wrote:
>> Hi Dave,
>>
>>
>> On Dec 20, 2013, at 19:01 , Dave Taht <dave.taht@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....

       Sorry, my bad. I do not really care that much, except I want expressive variable names which tend to be longish. And longish names do need some sort of separation of the parts INGRESSECN is harder to parse for than INGRESS_ECN and like wise for ingressecn and ingress_ecn, and camelcase serves the same purpose just uglier. But from now on I will follow your wishes.

Best
       Sebastian

>
>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.
>>

Hi Dave,
-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.