From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 48C6E21F113 for ; Fri, 20 Dec 2013 16:34:16 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id m15so3090933wgh.25 for ; Fri, 20 Dec 2013 16:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tP3vCBmQRWzuC/9T2SfLOvroem2aHLGG009yNv8K/oU=; b=RGx+baySrcqlHiyd0h1x5hy+KkdVA+kNQVm3nA9z+HCOdeKpVWC6sB8wU8KofiFVpk uWc5zQx09K+acETey9B1KfwB3Gvlls2dERxps5ifZ/V1eMUoBHkDG5jVUSNslxMcgJwU q5BoBnpDO2q2jMFw03wItngnrMHH0CnsXslNB4jDZGCnYNG7TZj+083RHSqhoosKi0eC CwPoVDQcqtJpfe5J3PVWr+oO8S+8fto8jGmWWENXOEAMmfLXzmuCwj8+Y1EpMiUjByBE iZkRow8rlhGJNZjPC+KLK7PT5PAvHoAB4TjI1AhCLHh8dZ8O1vCPul259xIDzcF5MDWF wahg== MIME-Version: 1.0 X-Received: by 10.180.37.69 with SMTP id w5mr10096988wij.53.1387586054111; Fri, 20 Dec 2013 16:34:14 -0800 (PST) Received: by 10.217.123.69 with HTTP; Fri, 20 Dec 2013 16:34:14 -0800 (PST) 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> Date: Fri, 20 Dec 2013 16:34:14 -0800 Message-ID: From: Dave Taht To: Sebastian Moeller Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 00:34:17 -0000 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. >> >> 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= =85 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. > --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html