From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-gg0-f171.google.com (mail-gg0-f171.google.com [209.85.161.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 DEDCC2002A9; Wed, 20 Jun 2012 08:52:37 -0700 (PDT) Received: by ggmi1 with SMTP id i1so10536440ggm.16 for ; Wed, 20 Jun 2012 08:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:organization:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=uSLQ05qbmzfk1Ac+ZVLpZJxbBOfLGTaXdbxbj/jGlhM=; b=GNEN8kHdOZaJ5/9SQLBt2MBM8L+P5OtGn7fZA3FHClkGAVi4fL/Z7GgxdFNEUVvypG ghF9UP/a1lpSTAxW3Xb8iO5Sy+XjGaWVOxJTfKWPI86odjRuiU0WFxM0pFO6cJXqIE3+ 4RrN6EJmZpV+nX0GlhoWARGc+KRhk9YBvufwIX46uKMmgsBxtRuhbLpSx4H6zZjfXkkr 7zILoEUoWAKivVdh2pwFpiRGHNzdH5ylBj7YengW9Ar00UQDp3AJz65yanBBM1v5cvhU 64p1J5HK1YS9DmZ6f4patZTri8PcX9OteUFlKyCSI4OQgS6lj0cxNW//hiRAizp60rrV Pb7Q== Received: by 10.236.197.8 with SMTP id s8mr29086468yhn.9.1340207555516; Wed, 20 Jun 2012 08:52:35 -0700 (PDT) Received: from [172.30.42.80] (c-24-218-176-94.hsd1.ma.comcast.net. [24.218.176.94]) by mx.google.com with ESMTPS id q32sm40766366anh.21.2012.06.20.08.52.33 (version=SSLv3 cipher=OTHER); Wed, 20 Jun 2012 08:52:34 -0700 (PDT) Sender: Jim Gettys Message-ID: <4FE1F1C0.6030808@freedesktop.org> Date: Wed, 20 Jun 2012 11:52:32 -0400 From: Jim Gettys Organization: Bell Labs User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jonathan Morton References: <3455F07C-D677-44CC-B8DD-54070D8CB2E6@gmail.com> In-Reply-To: <3455F07C-D677-44CC-B8DD-54070D8CB2E6@gmail.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 15:52:40 -0000 On 06/20/2012 06:08 AM, Jonathan Morton wrote: > 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 explanation 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 threshold. Yeah, I've been worrying about ack compression... Not sure exactly what we should be doing about it, as I don't fully understand it. - Jim > > The key to knowledge is not to rely on others to teach you it. > > 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". >> >> 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". >> >> -- >> Dave Täht >> SKYPE: davetaht >> http://ronsravings.blogspot.com/ >> _______________________________________________ >> Codel mailing list >> Codel@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/codel > _______________________________________________ > Codel mailing list > Codel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/codel