From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-f171.google.com (mail-lb0-f171.google.com [209.85.217.171]) (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 6483921F0AA; Wed, 20 Jun 2012 03:08:11 -0700 (PDT) Received: by lbom4 with SMTP id m4so716349lbo.16 for ; Wed, 20 Jun 2012 03:08:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=4dSvfvI1xgkTwrU9ge32g8R5Bwb/OiptEDdRw5/CBDI=; b=TqbmcfA8e5wrom9Ekf5jUvHCazvHpIq2ib/JfKP9zKT/ClMRh9KzCJh+K81q6fhV8I eXUIizucTsAOT88o4yQ72+N0pn2k8nQYvudL7WDLCYKOQ8+OGqgw4Ygo/6D1h5RLsh00 eVboWa7ajaWYLGKUWRXOhqrfTL9WEQ3RQDm7IM/aqRfNPy17qNRP8TZKb1nd//RBW3P/ UZfsfdTnvk1re2svQCZgDdtLWo21Nu2jWPzDzNB7EaGsfNki3gGmSysqEUaBJYeMYR0W YsQNAhAWY2Y5xOReAVQTFLwP+uIkyRBINDs9j5mzP8dhgSu65rCIrxOyxPk1u7FZUsra RSlw== Received: by 10.152.104.77 with SMTP id gc13mr21642227lab.31.1340186888005; Wed, 20 Jun 2012 03:08:08 -0700 (PDT) Received: from [10.248.144.252] (37-219-224-168.nat.bb.dnainternet.fi. [37.219.224.168]) by mx.google.com with ESMTPS id fd1sm15859417lbb.7.2012.06.20.03.08.00 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 20 Jun 2012 03:08:07 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (iPhone Mail 8C148) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: <3455F07C-D677-44CC-B8DD-54070D8CB2E6@gmail.com> X-Mailer: iPhone Mail (8C148) From: Jonathan Morton Date: Wed, 20 Jun 2012 13:08:20 +0300 To: Dave Taht Cc: "codel@lists.bufferbloat.net" , "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Codel] codel "oversteer" 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: Wed, 20 Jun 2012 10:08:12 -0000 Is the cwnd also oscillating wildly or is it just an artefact of the visible= part of the queue only being a fraction of the real queue? Are ACK packets being aggregated by wireless? That would be a good explanati= on for large bursts that flood the buffer, if the rwnd opens a lot suddenly.= This would also be an argument that 2*n is too small for the ECN drop thres= hold.=20 The key to knowledge is not to rely on others to teach you it.=20 On 20 Jun 2012, at 04:32, Dave Taht wrote: > I've been forming a theory regarding codel behavior in some > pathological conditions. For the sake of developing the theory I'm > going to return to the original car analogy published here, and add a > new one - "oversteer". >=20 > Briefly: >=20 > If the underlying interface device driver is overbuffered, when the > packet backlog finally makes it into the qdisc layer, that bursts up > rapidly and codel rapidly ramps up it's drop strategy, which corrects > the problem, but we are back in a state where we are, as in the case > of an auto on ice, or a very loose connection to the steering wheel, > "oversteering" because codel is actually not measuring the entire > time-width of the queue and unable to control it well, even if it > could. >=20 > What I observe on wireless now with fq_codel under heavy load is > oscillation in the qdisc layer between 0 length queue and 70 or more > packets backlogged, a burst of drops when that happens, and far more > drops than ecn marks that I expected (with the new (arbitrary) drop > ecn packets if > 2 * target idea I was fiddling with illustrating the > point better, now). It's difficult to gain further direct insight > without time and packet traces, and maybe exporting more data to > userspace, but this kind of explains a report I got privately on x86 > (no ecn drop enabled), and the behavior of fq_codel on wireless on the > present version of cerowrt. >=20 > (I could always have inserted a bug, too, if it wasn't for the private > report and having to get on a plane shortly I wouldn't be posting this > now) >=20 > Further testing ideas (others!) could try would be: >=20 > Increase BQL's setting to over-large values on a BQL enabled interface > and see what happens > Test with an overbuffered ethernet interface in the first place > Improve the ns3 model to have an emulated network interface with > user-settable buffering >=20 > Assuming I'm right and others can reproduce this, this implies that > focusing much harder on BQL and overbuffering related issues on the > dozens? hundreds? of non-BQL enabled ethernet drivers is needed at > this point. And we already know that much more hard work on fixing > wifi is needed. >=20 > Despite this I'm generally pleased with the fq_codel results over > wireless I'm currently getting from today's build of cerowrt, and > certainly the BQL-enabled ethernet drivers I've worked with (ar71xx, > e1000) don't display this behavior, neither does soft rate limiting > using htb - instead achieving a steady state for the packet backlog, > accepting bursts, and otherwise being "nice". >=20 > --=20 > Dave T=C3=A4ht > SKYPE: davetaht > http://ronsravings.blogspot.com/ > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel