From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id F2F4121F1BC for ; Sat, 21 Dec 2013 01:37:07 -0800 (PST) Received: from [10.17.151.121] ([80.187.96.24]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MMCFR-1VqlA53EWz-007z6A for ; Sat, 21 Dec 2013 10:37:05 +0100 User-Agent: K-9 Mail for Android In-Reply-To: References: <34E77F64-739C-49E4-B8A4-6ABBEAE4174B@gmail.com> <8DB84101-C942-49C4-99F0-6C9319961297@gmail.com> <22176178-A50F-48F2-A3A1-D3853764AD0E@gmail.com> <0E267F91-3CC8-48F4-92C0-AD8BACA98FCC@gmail.com> <1FA2FD44-D715-4B50-BB5A-BAF61070970B@gmx.de> <31B5B61B-4E58-4C5E-8F33-710CCE0918F4@gmail.com> <52B2D917.6080006@imap.cc> <52B2D93B.6050501@imap.cc> <52B2F63B.7060506@imap.cc> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable From: Sebastian Moeller Date: Sat, 21 Dec 2013 10:36:58 +0100 To: Dave Taht Message-ID: <03276602-4412-40e5-abd6-16fdc9cdfbe5@email.android.com> X-Provags-ID: V03:K0:bcNIieM9g1A3nuIGUdfVDRkAFRBZNNkAdZlnkmj3n0HHGnoZwq7 FxPZhmHlpMguAufMjh58Iejtu6iMCB5EFcbao0KzZ/Ab52yHvlTbqSPQ6j+x8Dq1NYEwOc5 O70k1nyKyl1Z2TkItcou6kvXG8nBthCT7g6qO9+eYzeXUbbrz6mSnerDwWoOixoAO+IxeVM RzjngharEJVNCSTN+rBhw== Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] cerowrt-3.10.24-5 dev build released X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Dec 2013 09:37:09 -0000 Dave Taht wrote: >On Fri, Dec 20, 2013 at 1:01 PM, Sebastian Moeller >wrote: >> Hi Dave, >> >> >> On Dec 20, 2013, at 19:01 , Dave Taht wrote: >> >>> I wanted to say how much I was enjoying catching up on this thread=2E >>> >>> 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=2E Byte limits are >>> very common for cable and dsl technologies and doing tests with >>> 64k,128k,256k, and 512k bfifos is quite revealing=2E (I have a ton of >>> plots lying about for this, I should put them up somewhere) >>> >>> Sooo=2E=2E=2E I just checked in the limit stuff (untested) into >aqm-scripts=2E >>> 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=2E >>> There needs to be sane values for limit clamped somehow, as 1000 >bytes >>> would be bad, and 512000 packets would be bad also=2E >>> >> >> I just noticed we probably should go for ingress_Limit and >egress_Limit as there are different in simple_qos=2Esh, I assume for a >good reason=E2=80=A6 > > >I am not huge on CamelCase or HungarianNotation, or iThinkThis, btw=2E >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=2E 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=2E There are now several different styles running through the >aqm-scripts=2E=2E=2E=2E Sorry, my bad=2E I do not really care that much, except I want expr= essive variable names which tend to be longish=2E And longish names do need= some sort of separation of the parts INGRESSECN is harder to parse for tha= n INGRESS_ECN and like wise for ingressecn and ingress_ecn, and camelcase s= erves the same purpose just uglier=2E But from now on I will follow your wi= shes=2E 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=2E > >Elsewhere, prior to now, the limits were there merely to keep memory >usage under control=2E There is no need for 10k packets worth of >buffering=2E 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=2E > >I really do hate having more knobs that can be messed up=2E > >> >> 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=2E Certainly I can imagine many a researcher wanting the >>> gui=2E >>> >>> While I'm at it, there are some statistics like drops, and backlog, >>> etc, that a gui-ish interface might help=2E >>> >>> 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=2E10=2E24-5? I >have >>> one box that has now been up 4=2E4 days with no errors, but I haven't >>> pushed it=2E I'll be beating it up through the weekend and taking a >look >>> at the gui work so far=2E >> Hi Dave, --=20 Sent from my Android phone with K-9 Mail=2E Please excuse my brevity=2E