From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp89.iad3a.emailsrvr.com (smtp89.iad3a.emailsrvr.com [173.203.187.89]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 1D84C21F21F for ; Tue, 25 Feb 2014 13:27:34 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp12.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 33D6CF00A2; Tue, 25 Feb 2014 16:27:26 -0500 (EST) X-Virus-Scanned: OK Received: from app41.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp12.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 1781FF008B; Tue, 25 Feb 2014 16:27:26 -0500 (EST) Received: from reed.com (localhost.localdomain [127.0.0.1]) by app41.wa-webapps.iad3a (Postfix) with ESMTP id F1E35280149; Tue, 25 Feb 2014 16:27:25 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Tue, 25 Feb 2014 16:27:25 -0500 (EST) Date: Tue, 25 Feb 2014 16:27:25 -0500 (EST) From: dpreed@reed.com To: "Jim Gettys" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain In-Reply-To: References: <530C7AFA.2070101@gmail.com> Message-ID: <1393363645.988523284@apps.rackspace.com> X-Mailer: webmail7.0 Cc: Nicholas Weaver , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] =?utf-8?q?uplink=5Fbuffer=5Fadjustment?= 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: Tue, 25 Feb 2014 21:27:34 -0000 I've measured buffer size with TCP, when there is no fq_codel or whatever d= oing drops. After all, this is what caused me to get concerned.=0A=0AAnd a= ctually, since UDP packets are dropped by fq_codel the same as TCP packets,= it's easy to see how big fq_codel lets the buffers get.=0A=0AIf the buffer= gets to be 1200 msec. long with UDP, that's a problem with fq_codel - just= think about it. Someone's tuning fq_codel to allow excess buildup of queu= eing, if that's observed.=0A=0ASo I doubt this is a netalyzr bug at all. O= perator error more likely, in tuning fq_codel.=0A=0A=0A=0A=0AOn Tuesday, Fe= bruary 25, 2014 11:46am, "Jim Gettys" said:=0A=0A> ___= ____________________________________________=0A> Cerowrt-devel mailing list= =0A> Cerowrt-devel@lists.bufferbloat.net=0A> https://lists.bufferbloat.net/= listinfo/cerowrt-devel=0A> On Tue, Feb 25, 2014 at 11:02 AM, Nicholas Weave= r > wrote:=0A> =0A>>=0A>> On Feb 25, 2014, at= 7:59 AM, Jim Gettys wrote:=0A>> > So it is arguably a= "bug" in netalyzr. It is certainly extremely=0A>> misleading.=0A>> >=0A>>= > Nick?=0A>>=0A>> Rewriting it as a TCP-based stresser is definatly on our= to-do list.=0A>>=0A> =0A> Good; though I'm not sure you'll be able to buil= d a TCP one that fills the=0A> buffers fast enough to determine some of the= buffering out there (at least=0A> without hacking the TCP implementation, = anyway).=0A> =0A> The other piece of this is detecting flow queuing being a= ctive; this makes=0A> a bigger difference to actual latency than mark/drop = algorithms do by=0A> themselves.=0A> - Ji= m=0A> =0A> =0A>>=0A>>=0A>> --=0A>> Nicholas Weaver it is a= tale, told by an idiot,=0A>> nweaver@icsi.berkeley.edu full= of sound and fury,=0A>> 510-666-2903 .sign= ifying nothing=0A>> PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweave= r_pub.asc=0A>>=0A>>=0A> =0A