From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 04662208AAD for ; Fri, 21 Dec 2012 09:43:24 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so4116550iaz.17 for ; Fri, 21 Dec 2012 09:43:24 -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=zMkWKt9GfvUpU25TpDVR1OTJiuODYjPJMo/46+J/N5c=; b=Svp0wPK8Mu0L4XtRTqrZsPg2HgscQzpXDabBzHrbAj6xnM9ZIT1f8IgG2HhDVs7Qd3 fiOCO9edso1aU7w/OCINIJ1opy5qwX6jo+7K3XQ+dSBw3LDi4ZFPuss/ODsFlmZvEeBc kyRVi82+JObh8ZtSg4yN5gYi4b4+F+uerMP7Xmxp73yuC1xIm7RdbjwVe74KSXnmeaqI gSZ80VVpaCbiYzvQpaatuPrlSmLzM4taJuihnz9vDSkOPvO3LX9tyW00j4rtUNEkuika QmUN0u308m5oKOE0sPGRlzUn9SyBbl842DhlhnQCJRaxa1nJc+dUGw/8h5lWE1kIs3yu Rj0Q== MIME-Version: 1.0 Received: by 10.50.88.136 with SMTP id bg8mr9385286igb.96.1356111803953; Fri, 21 Dec 2012 09:43:23 -0800 (PST) Received: by 10.64.135.39 with HTTP; Fri, 21 Dec 2012 09:43:23 -0800 (PST) In-Reply-To: <50D496FB.5090409@pollere.com> References: <50D496FB.5090409@pollere.com> Date: Fri, 21 Dec 2012 18:43:23 +0100 Message-ID: From: Dave Taht To: Kathleen Nichols Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] R: Making tests on Tp-link router powered by Openwrt svn X-BeenThere: codel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: CoDel AQM discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 17:43:25 -0000 On Fri, Dec 21, 2012 at 6:06 PM, Kathleen Nichols wro= te: > On 12/21/12 2:32 AM, Dave Taht wrote: >> On Fri, Dec 21, 2012 at 5:19 AM, Alessandro Bolletta >> wrote: > I don't understand why you are lowering the target explicitly as the use = of > an MTU's worth of packets as the alternate target appeared to work quite > well at rates down to 64kbps in simulation as well as in changing rates. > I thought Van explained this nicely in his talk at IETF. I call this the horizontal standing queue problem, and it's specific to *fq*_codel (and to some extent, the derivatives so far). I figure codel, by itself, copes better. but in fq_codel, each (of 1024 by default) queue is a full blown codel queue, and thus drops out of drop state when the mtu limit is hit. Worse, fq_codel always sends a full quantum's worth of packets from each queue, in order, not mixing them. This is perfectly fine and even reasonably sane at truly high bandwidths where TSO/GSO and GRO are being used, but a pretty terrible idea at 100Mbit and below, and results in moving rapidly back and forth through the timestamps in the backlog on that queue... The original fq_codel did no fate-sharing at all, the current one (in 3.6) does. I produced (several months ago) a couple versions of (e and n) fq_codel that did better mixing at a higher cpu cost. It was really hard to see differences. I just found a bug in my nfq_codel patch today in fact... Also fiddled a lot with the per queue don't shoot me at MTU limit, in one version shared amongst all queues, in another, set to the size of the biggest packet to have hit that queue since the end of the last drop interval. So I then decided to really look at this, hard, by working on a set of benchmarks that made it easy to load up a link with a wide variety of actual traffic. I'm really happy with the rrul related tests toke has put together. I tried to talk about this coherently then, and failed, so once I had good tests showing various behaviors, I figured I'd talk about it. I would still prefer not to talk about until I have results I can trust and finding all the sources of experimental error in the labs setup so far have eaten most of my time. I didn't mean to jump the gun on that today, I have a few weeks left to go, and to collate the analysis coherently with the lab results, and for all I know some aspect of the lab implementations, the known BQL issue (bytes rather than packets), or the fact that HTB buffers up a packet, are all more key to the problem. If it's real. In the benchmarks I've been doing via toke's implementation of the rrul test suite, *on a asymmetric link* fq_codel behavior gets more stable (uses up the largest percentage of bandwidth) if you set target above the size of the maximum size packet's delivery time at that bandwidth. Another benchmark that will show bad behavior regardless is to try pounding a line flat for a while with dozens of full rate streams. in your sfq_codel (which I hope to look at next week), do you have a shared MTU limit for all streams or do you do it on a per stream basis? > > Kathie > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html