From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id CC5D221F2DF for ; Mon, 22 Sep 2014 15:25:32 -0700 (PDT) Received: by mail-ob0-f170.google.com with SMTP id uz6so1626713obc.1 for ; Mon, 22 Sep 2014 15:25:31 -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=CUvpIpmVGwnvcPS/Xcp+j+UhSydWvOLkhx+kbCLrvsU=; b=wvufmIpv99KRh+L+bkYAImyNYZuU/3ugBdnaTchDbLt/8lerLqPhG11BIxwciz1jA4 68JbrA4+1QVSEGbCZ0rnpCgB1rby4mkcRZBHWU/M4LvZ7Tl8AyO98bZBSb7dBqeo75ZE pSzLJV5EgO5vbxjuVdmHlFlLxynWw49YBXuxzqTqgMhEX3fytse7JUTy2NZNdqlF5ftE hnl7v3EgSlXfeDdGw6WU0lEC0f6dj4sYSCRU389/3sV1c6Wf3haH4Erf4XkPeRz3DbkJ UH7f36NX/FxXfKReGc6pTOReaBQj/YIZSvIO7y/fa/dA/s/p8f0SrWUp/znXkx9Si6lM LtqQ== MIME-Version: 1.0 X-Received: by 10.60.141.35 with SMTP id rl3mr21931764oeb.43.1411424731528; Mon, 22 Sep 2014 15:25:31 -0700 (PDT) Received: by 10.202.227.76 with HTTP; Mon, 22 Sep 2014 15:25:31 -0700 (PDT) Date: Mon, 22 Sep 2014 15:25:31 -0700 Message-ID: From: Dave Taht To: "cerowrt-devel@lists.bufferbloat.net" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [Cerowrt-devel] Comparison against cablelabs test setup X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 22:26:01 -0000 Aaron, all: I am curious as to what happens in rrul and other tests when fq_codel is configured for the values that cablelabs used for their simulations, compared to how you have it configured now. e.g. Try: target 50ms interval 150ms quantum 300 flows 32 Instead of the defaults... I have some data too, but nothing at 120Mbit with only the upstream managed, as aaron has, as one example, and my real world 50/10 mbit data is suspect at the moment. ---------- Forwarded message ---------- From: Greg White Date: Mon, Sep 22, 2014 at 2:44 PM Subject: Re: [aqm] adoption call: algorithm drafts To: Dave Taht Cc: "Fred Baker (fred)" , Wesley Eddy , "aqm@ietf.org" On 9/19/14, 3:04 PM, "Dave Taht" wrote: >On Fri, Sep 19, 2014 at 11:18 PM, Greg White >wrote: >> Fred, >> >> I know you, Rong and Bill VS have seen it, but in case others haven't, >> there is an apples-to-apples comparison of fq-codel and fq-pie in my >>paper >> from May (along with some design notes, since the merge of fq and pie is >> not as straightforward as one might think). > >Please don't declare fq_codel (in the real world) equal to your setup >of ns2 sfq_codel. Yes, YMMV depending on a lot of things. Our comparison was specific to DOCSIS upstreams, and used some optimized parameters to get the best feasible mix of performance that we could. It was apples-to-apples, but I'm not claiming that the results should be interpreted to hold across all possible implementations and configurations of *fq(-|_)(pie|codel). >It is something of a wild extrapolation to compare sfq_codel target >50ms interval 150ms flows 32 > >to what we have deployed in the real world against cablemodems as >fq_codel quantum 300 target 5ms interval 100ms flows 1024 Different for sure, but I wouldn't characterize it as a wild extrapolation. We used quantum 300 as well. For the other parameters, we tested with the lower target values and lower interval values and saw better performance by boosting them to the values we reported. With *fq in the mix, CoDel or PIE really become the second line of defense and primarily impact latency performance when you have a hash collision. With 1024 queues, I would expect that is somewhat rare (certainly more rare than we saw with 32 queues), so opening up some more burst/buffer tolerance for TCP could get you better short term TCP results in a range of conditions (keep in mind that RRUL is a nice test, but not the only one) with very little downside. 32 queues vs 1024 ... yes we would have seen more frequent hash collisions in our results. But, 32 queues per Service Flow (1024 queues total) was about the limit of plausibility for our MAC. Also, we've already shared our concerns about potential exacerbations of the horizontal queuing problem, VPN tunnels, etc. In any case, I'm not trying to say that I have a monopoly on comparisons between *fq-codel and *fq-pie, just that we did one (and so far it's the only one). >as we show here: > >http://burntchrome.blogspot.gr/2014_05_01_archive.html I guess I missed the comparison to *fq-pie on that page. ? Also, please don't declare your PIE implementation equal to the one that is defined in DOCSIS ;-) >the two level DRR in fq_codel has a bit less complexity than the ns2 >SFQ_codel code and I've never felt it matched the linux code well >enough. How so? >I otherwise mostly agree that the issues with applying fq on top of >pie induce below. > >Now that the cablelabs ns2 code is mainlined, and GSOC bufferbloat >summer of code for ns3 is done, and most of that code headed for >mainline, (codel and some asymmetric network tests landed, (including >a partial CMTS emulation), fq_codel is waiting on some improvements of >packet header processing) I hope to find the time to do a real >fq_codel implemention for ns2, and maybe get netperf-wrapper up to >where it could duplicate more of your tests. > >I am curious, do any of your tests assume ack prioritization is in play? No, the contrary. We assume it is not present. >> >>http://www.cablelabs.com/wp-content/uploads/2014/06/DOCSIS-AQM_May2014.pd >>f >> >> Best Regards, >> Greg >> >> >> >> >> On 9/18/14, 12:20 PM, "Fred Baker (fred)" wrote: >> >>> >>>On Sep 16, 2014, at 6:58 AM, Dave Taht wrote: >>> >>>> If a fq_pie were produced, how would that work? >>> >>>We are doing an fq_pie implementation, at least as a prototype. It >>>merges >>>the fq part of your existing fq_codel code RP=C2=B9s PIE algorithm. Ther= e is >>>a >>>part of me that would want to revisit the design of fq to make it a >>>calendar queue, but that is down the road. What we=C2=B9re interested in >>>right >>>now is an apples/apples comparison with fq_codel. Further reports when >>>we=C2=B9re ready to report, which isn=C2=B9t yet. >> > > > >-- >Dave T=C3=A4ht > >https://www.bufferbloat.net/projects/make-wifi-fast --=20 Dave T=C3=A4ht https://www.bufferbloat.net/projects/make-wifi-fast