From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-bk0-f43.google.com (mail-bk0-f43.google.com [209.85.214.43]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id E46C0201261 for ; Tue, 4 Sep 2012 12:02:33 -0700 (PDT) Received: by bkty15 with SMTP id y15so4216412bkt.16 for ; Tue, 04 Sep 2012 12:02:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; bh=vJVb/qppVGE7Ly0LIg31y7iO62Xio90C9G03xn7FRE0=; b=UiylskygEHdGtJHCwPa8j5kIWH1rq92VHeurSPgcCdBhqBHB7aQeEJNndjc5fFZfrt T7lSeJvvJqfNf1/iT1vUw0YLP2L0MDEXNn6sxa0GYgy+rtNP3qSQ8jumkP+Ol4sX4S+x +GIaJkeJP3DBwlLdSUOBD82feOwYg0lBsWD3f651S10gGfpesUx/lBr2aPUctghtbD49 PKhSd4g5BLiaZbnlXdiF5gA3A/sz79xR+ls6gwra3LWwB3w+mnyfCtEY8AWYin2dNI9l A8+WoJRYPVJTtWcZGhA7XzUf46iZietaEFnL58Ww7E7nvgEStW03dJuVEy07/RfTMfGl BWng== Received: by 10.204.145.90 with SMTP id c26mr8751863bkv.34.1346785351432; Tue, 04 Sep 2012 12:02:31 -0700 (PDT) Received: from [192.168.142.158] ([74.125.121.33]) by mx.google.com with ESMTPS id gq2sm11240378bkc.13.2012.09.04.12.02.29 (version=SSLv3 cipher=OTHER); Tue, 04 Sep 2012 12:02:30 -0700 (PDT) From: Eric Dumazet To: Dave Taht In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Tue, 04 Sep 2012 21:02:27 +0200 Message-ID: <1346785347.13121.77.camel@edumazet-glaptop> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit Cc: codel@lists.bufferbloat.net Subject: Re: [Codel] fq_codel: revenge of the standing queue 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: Tue, 04 Sep 2012 19:02:34 -0000 On Tue, 2012-09-04 at 11:35 -0700, Dave Taht wrote: > 1) An empty queue in fq_codel has no meaningful information. > > in: codel_should_drop > > if (!skb) { > vars->first_above_time = 0; > return false; > } > I believe the codel intent here was to reset codel's state when the > single FIFO queue was emptied. In fq_codel's case, an empty queue > contains no information about the state, really, and a > > if (!skb) { > if(sch->qstats.backlog <= mtu) > vars->first_above_time = 0; > return false; > } > > comes closer to the intent. That said, the null skb then bleeds into > the rest of the algorithm > > in codel_dequeue > > > if (!skb) { > vars->dropping = false; > return skb; > } > > later on there's > > if (vars->dropping) { > if (!drop) { > /* sojourn time below target - leave dropping state */ > vars->dropping = false; > > and the same assumption within the while loop and in the else if(drop)... > > I'm pretty sure that leaving of dropping state just because this > fq_codel queue is (temporarily) empty is not the right thing, and that > the main reason for exiting the dropping state should be getting under > the target delay. It might make sense to reschedule the next drop on a > null skb, perhaps after reducing count... > > While I've fiddled with these ideas, and got some drainage, I do get > fairly big oscillations in queue depth, and starvation of some flows, > in various versions of my explorations. Which led me to looking at > quantums and... I have no idea of what you try to say. Each flow has its own cvars : skb = codel_dequeue(sch, &q->cparams, &flow->cvars, &q->cstats, dequeue); So each flow has its own codel unit. Try to view fq_codel as a multiplexor, then a Codel unit for each flow. So if you believe there is a bug in Codel, try to describe the big in Codel, not in fq_codel, because fq_codel is _not_ a codel variant. The only thing that fq_codel codel units share are the parameters and stats.