From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (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 E851721F232 for ; Mon, 25 May 2015 13:09:51 -0700 (PDT) Received: by oihd6 with SMTP id d6so63666685oih.2 for ; Mon, 25 May 2015 13:09:39 -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=8wm3/QJOrneBaJzZMnll1tyl7wHv6Vip7tYRwsYskRQ=; b=iTkSEGvXSPmf8eE0w2B6yCEKwQVjG5tIqFmMqS5ijWMHTQZsmFf45wAzHezlObrbq9 1mopFsBMmb9ObgqtWkgYt8OYrdKB2c1+2+KDKPvCYKL0t3HtxfpeUjLKgg6f0GBCcpMf ZSYcd1u2w1oV26gQmBYzU5jtb+i84WpdqceigBprF8bqWTg+GGV7BGU2XJwA+ZvIuHfM WJzoo1fMNTXudUBaP6tJlEVB/dpR2GWgaxxsgVj/UU6iUAXsDfwBEIu/4wovJOz0kVot p/2zljCsePITmeDk5HnatLISWqA4h9pbtT5vTas0Oidm2yDrxXlVpRGwP8p9pztwb9Y8 7LHw== MIME-Version: 1.0 X-Received: by 10.182.29.101 with SMTP id j5mr1044725obh.0.1432584579158; Mon, 25 May 2015 13:09:39 -0700 (PDT) Received: by 10.202.105.146 with HTTP; Mon, 25 May 2015 13:09:39 -0700 (PDT) In-Reply-To: <67EE7961-8978-4403-AC1A-1157F008795D@gmail.com> References: <67EE7961-8978-4403-AC1A-1157F008795D@gmail.com> Date: Mon, 25 May 2015 13:09:39 -0700 Message-ID: From: Dave Taht To: Jonathan Morton Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] peeling at sub-1ms X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Cake - FQ_codel the next generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 May 2015 20:10:31 -0000 On Sun, May 24, 2015 at 9:56 PM, Jonathan Morton wr= ote: > >> On 23 May, 2015, at 20:47, Dave Taht wrote: > >> I think I would be happier if we peeled at 250usec rather than 1ms. At >> 110Mbit that is 2 packets, but at a gig quite a lot. >> >> (selfishly, that is the speed I am running at while watching >> dslreports misbehave) >> >> The second problem is that the default peeling behavior somehow should >> work while at line rate, whether the rate be 10mbit or a gbit. >> >> another option is when we know we have lots of flows, to peel more. > > Since it doesn=E2=80=99t seem to have completely blown up in your face, I= can assume that I was on basically the right track, and do a bit more refi= nement on the peeling code. There probably is some room for efficiency imp= rovements. > I said the heck with it and peeled superpackets apart universally in my most recent tests of cake. The original (1960s) definition of a packet was 1000 bits. Everything since then has fudged the issue. packets occupy mass, transistors, etc. A core trade-off I am observing is that having one queue per flow impacts overall delay - I see fq_codel achieving a 15ms induced delay typically (with 100 flows extant and 4 measurement flows), cake 30, pie about 40ms... on a 100/10 link on these crazy bidir tests. Now the goal of course is to fill the pipe - and another goal (which is becoming more apparent to me) is to provide an SRTT estimate to the tcps that is real. We are giving a consistent over-estimate of the baseline RTT to the tcps... the cwnds stay flat... the single data point the "fast/slow queue" distinction gives is not enough ( I keep thinking we can seriously improve a tcp here, and also certainly improve the ecn behavior of a tcp if it used the minimum observed rtt to base it's rate reductions on). I also re-instated the 300 quantum for speeds up to 400mbit instead of the previous cutoff of 40mbit. I don't like how much extra cpu that uses, but it led to much saner ack clocking overall at these extreme loads. The above also kills the fast/slow distinction also. Sigh. I really need a fora for writing these down, with graphs, and turning the results around more quickly to share. and a testbed running. and.... sigh. Do you want me to push branches for this sort of exercises? > If I do some pre-computation at shaper configuration time, I think I can = efficiently handle the cases you mention. Well, one thought in bobbie (dynamically dropping the rate) is pretty computationally expensive in cake and hits several paths when changed on the command line that it needent (tc cake change dev eth2 bandwidth 50mbit). If we were to start exploring a gargoyle-router-project-esq self tuning option those paths should get tightened. I am definately seeing heisenbugs with watch tc -s qdisc qdisc show on a 2 sec interval. Want to throw drops/marks to userspace.... > > - Jonathan Morton > --=20 Dave T=C3=A4ht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67