Dave Taht <dave.t...@gmail.com> wrote: >On Fri, Dec 20, 2013 at 1:01 PM, Sebastian Moeller <moell...@gmx.de> >wrote: >> Hi Dave, >> >> >> On Dec 20, 2013, at 19:01 , Dave Taht <dave.t...@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. _______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel