From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-f171.google.com (mail-we0-f171.google.com [74.125.82.171]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id C69C121F0A2 for ; Tue, 4 Sep 2012 13:22:07 -0700 (PDT) Received: by weys43 with SMTP id s43so7938967wey.16 for ; Tue, 04 Sep 2012 13:22:06 -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=67spqSd9QjKkusF+9s/wn8dFljhH+LHCf2oDwbbAc1g=; b=IZeX1P17pVk7lpUIL6pfgaTVr/RXVdRS7UiY9SmZleib2qbJJC5+kdLqNk9kzE81MW Frrb3lNR5nNoWvw2qCyEo3ne7nrKlI+P/0XhQA3CiLsdlA/e+lbHOH5RdrlN7OR+CFqe WsCftj99rRWhWNi1DciX022KFnMUAeTrOk+gZ1zc2z1yeWlB0Y3cm4kjxcOmeSjc/8Bc CgcD+xjRVz3YrjmCVKAVd3CTuG1W45oeuIujbe3rLws7MfGqCvg1Xsstr/4UlNbc6tSI gIjv42bKEMq0PhkwocUPyK+nf5Y704fg/bEY4dfbFSb6Zu633xM/1nXUdScZdImmCZNF ECBQ== MIME-Version: 1.0 Received: by 10.180.87.34 with SMTP id u2mr32943681wiz.3.1346790125865; Tue, 04 Sep 2012 13:22:05 -0700 (PDT) Received: by 10.223.159.134 with HTTP; Tue, 4 Sep 2012 13:22:05 -0700 (PDT) In-Reply-To: <50465E63.4000606@pollere.com> References: <1346784623.13121.65.camel@edumazet-glaptop> <50465E63.4000606@pollere.com> Date: Tue, 4 Sep 2012 13:22:05 -0700 Message-ID: From: Dave Taht To: Kathleen Nichols 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 20:22:08 -0000 On Tue, Sep 4, 2012 at 1:02 PM, Kathleen Nichols wrot= e: > > > I can't keep up with the pace here, but I'm compelled to express puzzleme= nt > at the notion that fq_codel gives *longer* standing queues than codel. I'm not saying that. fq_codel < codel < pfifo_fast, certainly and we don't run into needing floating point on count, and it's totally great. I'm saying that at high numbers of flows we end up with a standing queue in fq_codel. That's it. It would be cool to find a way to drain that swamp more, or understand better what I see, and that was the basic thrust of that long email (that I had been sitting on a week), where I tried to point at what I felt were flawed assumptions regarding temporarily empty queues. Eric views fq_codel as a "codel multiplexor", and I was trying to describe, obviously unsuccessfully, possible ways to do a merger of fq PLUS codel tha= t might work better. >The > opposite happens with sfq_codel which is, I believe, doing the same basic > things as fq_codel (a similar approach to that below for queues/bins that= go > empty) except for being packet scheduled rather than byte scheduled. I > see this wonderful, well-controlled behavior without "reverse traffic" > issues. If you run your sfqcodel sim at 10 and 100mbit with 150 bidirectional flows, what do you get? 300? 1000? > This is why I think Eric's work on this rocks. I think it rocks too. Most of my own battle of late has been with uTP. > > imho, > Kathie I'm going to crawl back under my rock now. > > > On 9/4/12 11:50 AM, Eric Dumazet wrote: >> On Tue, 2012-09-04 at 11:35 -0700, Dave Taht wrote: >> >>> 2) New flows >>> >>> The next issue (at these 10 and 100Mbit rates) is the "new flow" idea >>> in fq_codel. It is VERY useful pushing sparse flows to the fore of the >>> queues, and also provided a boost to long RTT flows. However at high >>> levels of occupancy and low bandwidth, flows empty their queue >>> rapidly, become "new flows", and then mislead codel for that flow into >>> resetting itself again, since we end up with a short delay for the >>> re-entrance. This isn't a particularly horrible behavior, but as my >>> own hope for this feature was to make voip better primarily, and >>> everything else we got from it was a bonus. >>> >>> TSQ really made this oddity show up big. I think on routed traffic it >>> will be less of an issue. >> >> This is simply not true, and based on misunderstanding on what does >> fq_codel. >> >> A flow never leaves the new flow list before doing a full RR cycle in >> old flow list (even without any packet in this flow) >> >> _IF_ we did a full RR cycle, then we accumulated a full quantum of >> credit, and lost our rank the 'fq_codel RR queue' (the combination of >> the 2 internal queues, new and old) >> >> Therefore, we allow the flow to be queued in 'new flow', to recover a >> bit of the lost rank in queue. >> >> Basically you dont interpret correctly the 'new_flow_count' counter. >> >> It means almost nothing at all, since for a given TCP flow, we _can_ >> increment this counter several time. >> >> >> >> _______________________________________________ >> 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 --=20 Dave T=E4ht http://www.bufferbloat.net/projects/cerowrt/wiki - "3.3.8-17 is out with fq_codel!"