From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com [74.125.82.47]) (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 E874421F0A2; Tue, 19 Jun 2012 18:32:02 -0700 (PDT) Received: by wgbfa7 with SMTP id fa7so5247324wgb.28 for ; Tue, 19 Jun 2012 18:32:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=nSk74gXoY1dOqAeMCjtkSAwAGQcOBgvED958T1XwDR8=; b=Yzth9eFekfr50PAezMhEVN1BtdtXw/nmLvgVEL20dRHlCALLzcltO4XxeU4jCsorJa NsAAacIo4rqIH259Dod1pIA5MsaUuUjgE0Cc0fFZXWEmiOkU8yVKsbblqnCDOhJDs1pB 4cB6P7fB2Q/8sMdae21SnT6cLyBDxPPDxsS87n+M0FLzh1prQoQI9PUy8clNkFLZ0ZaW bnOnligOCVWomiDZpQ4kGaL8FEmDD8Axah6n7EJkf9w9FJuXhuCks+UWCDAmlaB/46ni mCBAvGRh3B11sRE62PdjbNSg9LSkdU3vaReRbFT2AS6vOUmMP0lLGCbxEK3ZecOkg9Yc 7m7g== MIME-Version: 1.0 Received: by 10.180.78.161 with SMTP id c1mr7734795wix.1.1340155920770; Tue, 19 Jun 2012 18:32:00 -0700 (PDT) Received: by 10.223.103.199 with HTTP; Tue, 19 Jun 2012 18:32:00 -0700 (PDT) Date: Tue, 19 Jun 2012 21:32:00 -0400 Message-ID: From: Dave Taht To: codel@lists.bufferbloat.net, cerowrt-devel@lists.bufferbloat.net Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [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 01:32:03 -0000 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". Briefly: 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. 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. (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) Further testing ideas (others!) could try would be: 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 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. 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 Dave T=E4ht SKYPE: davetaht http://ronsravings.blogspot.com/