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 did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 74344201261 for ; Tue, 4 Sep 2012 12:51:40 -0700 (PDT) Received: by wgbfa7 with SMTP id fa7so4032112wgb.28 for ; Tue, 04 Sep 2012 12:51:38 -0700 (PDT) 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=pAc9kLJyFbHVVYQRGnHJxcS5K9VaWhiNuchMuSQ0oug=; b=tE02weeOmd6pZMzebyz1t9Kd7p0uQa70+UgHQ1l6LBngc+VyAjQaexVMnvhIPBm91V OWIsYjL5yx4DidyKOodDrE3UOqMolVPfU70KS74ebzEDMZNGzrofxqUbl4Kp8m4zfJTv ukrLYpA7KerR1NsTyF4oQFshKq+7rJ57SZil3ac7p+SCQKFcstsVvYF5euY3jcS4waQ4 OcZkycKLH8Ifn5fMNhk6OIq1VEcRhwg6i6Phto/jS4FwcQIvNvfkEs8HNNFDq7lliKYH Dst8ctfqEtCnOWSg5GnhYMkK9MKALyuyMnDOahOwHkZEecIU3ng8fNJEXKzZbtVNNFDO OxOQ== MIME-Version: 1.0 Received: by 10.216.181.67 with SMTP id k45mr151765wem.17.1346788298526; Tue, 04 Sep 2012 12:51:38 -0700 (PDT) Received: by 10.223.159.134 with HTTP; Tue, 4 Sep 2012 12:51:38 -0700 (PDT) In-Reply-To: <1346785347.13121.77.camel@edumazet-glaptop> References: <1346785347.13121.77.camel@edumazet-glaptop> Date: Tue, 4 Sep 2012 12:51:38 -0700 Message-ID: From: Dave Taht To: Eric Dumazet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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:51:40 -0000 On Tue, Sep 4, 2012 at 12:02 PM, Eric Dumazet wrot= e: > 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 =3D 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 <=3D mtu) >> vars->first_above_time =3D 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 =3D false; >> return skb; >> } >> >> later on there's >> >> if (vars->dropping) { >> if (!drop) { >> /* sojourn time below target - leave dropping st= ate */ >> vars->dropping =3D 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 =3D codel_dequeue(sch, &q->cparams, &flow->cvars, &q->cstats, > dequeue); - and we exit dropping state when that queue empties, when globally, across all the fq_codel queues, we still need to be dropping in order to get to the target. And that first_above time for that cvars for that fq_codel queue is reset to 0 for that fq_codel queue when it empties, forcing a recalc of the right interval (sojourn) for re-entering dropping state, with a "hands off" interval... It's seems reasonably ok for a fq_codel queue to go empty for a while but not have to go through a sojourn again to start dropping. It makes sense to always deliver one packet after going empty... these thoughts are half formed, and I did my damnedest to describe the behavior I was seeing. > So each flow has its own codel unit. > > Try to view fq_codel as a multiplexor, then a Codel unit for each flow. I do. > 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. No, this thread was about fq_codel's assumptions differences from codel's assumptions. Codel has it's own bugs, which I didn't talk to in this thread. > The only thing that fq_codel codel units share are the parameters and > stats. Understood. > > > > > --=20 Dave T=E4ht http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out with fq_codel!"