From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-x233.google.com (mail-qg0-x233.google.com [IPv6:2607:f8b0:400d:c04::233]) (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 E5A5A21F55A for ; Mon, 2 Nov 2015 08:20:44 -0800 (PST) Received: by qgeo38 with SMTP id o38so120781550qge.0 for ; Mon, 02 Nov 2015 08:20:43 -0800 (PST) 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=idANm+Ji4tFKd+wKu91hEZReP1gR/Vls/eFuuEd3fwg=; b=ERMV5SEyWCWgWQQlaQjS2KFFabTm3clL4oP6cY9CYH2qU9Ep6Gx2f+1hbbNoXFHRm6 A/hv2+PckU/SthJksBZtUdmnBNcqz4KlhR2wjfd/zj2HDp6aA6VF8RrpoWyj+e3wx2H5 9/jSnlJtx1KUuYcrd+ZnHT4BjnCdPQukHeIDBqeOD3Wk+K5Ia5sehYHCSHpmpxv1Bigi I2naUwmvyxEIpNIoDIYa+3ELSMfMjKj2WbekiTjyxVj07csB0bgRA+oVNm7BX8K3hfYr EFQ7mk3wXwltSitYqMxfEvtOlwOovFF6pK/OavGfD8pFcesbc4NyYo4amwh7Y/yoasE3 PmyA== MIME-Version: 1.0 X-Received: by 10.140.216.213 with SMTP id m204mr31924723qhb.34.1446481243469; Mon, 02 Nov 2015 08:20:43 -0800 (PST) Received: by 10.140.85.39 with HTTP; Mon, 2 Nov 2015 08:20:43 -0800 (PST) In-Reply-To: <2D22BEFF-B6B6-4348-B83E-3AB76F933BDF@gmx.de> References: <2D22BEFF-B6B6-4348-B83E-3AB76F933BDF@gmx.de> Date: Mon, 2 Nov 2015 16:20:43 +0000 Message-ID: From: Alan Jenkins To: Sebastian Moeller Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cake@lists.bufferbloat.net" Subject: Re: [Cake] cake target corner cases? 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, 02 Nov 2015 16:21:07 -0000 On 02/11/2015, Sebastian Moeller wrote: > Hi Alan, > > On Nov 2, 2015, at 01:20 , Alan Jenkins > wrote: > >> I thought SQM works fine with mtu * 1.0. But cake has been like this >> since at least April, and I didn't notice an extra 7ms when I tried >> it. Confusing. > > Well, sqm-scripts does take an MTU of 1540 bytes, which is less than ide= al > because for ATM encapsulation the on wire size is actually 32 or 32 * 53,= so > the worst case should be 33*53 =3D 1749 bytes, but in reality the actual = limit > itself only needs to be approximately right.. That said, I guess I fixed = up > sqm-scripts right now (by making target large enough for one 1749 byte > packet, I would be delighted if you could go measure whether this changes > things, before increasing auto-target to 1.5 worst case on-wire-packets, = and > also scaling interval so that target <=3D 0.1*interval stays true)... Ok. Actually I wouldn't have measured +7ms because I wasn't testing cake flowblind, aka codel. (And I was looking at ping under load, not tc -s qdisc, or the tcp rtt's). The increased target doesn't increase my bandwidth. Actually I'm failing to measure any changes at all, even for mtu*1.5. I'm sure there's a real effect on buffering, if I had a less noisy way to measure it :(. I couldn't work out exactly what you wanted testing; if there's something more specific I could probably spend more time on it. I agree with the reasoning for 1749 bytes. If you think mtu*1.5 is a good idea for SQM, I can't follow the logic, but it wouldn't bother me for fq_codel. I'm not really worried about cake, because I don't understand it. cake flowblind with mtu*1.5 hard-coded sounds less good, but I don't have any reason to use it in that mode :). >> b->cparams.interval =3D max(rtt_est_ns + >> b->cparams.target - ns_target, >> b->cparams.target * 8); > > I sort of cheated, I knew this was in the code, but I wanted to highligh= t > that we need a better description of what cake does to not confuse future > users, sorry for that. I won't complain, I'm probably the one being obstructive here. >> Maybe this keeps the target/interval ratio from going too far over the >> recommended 10%. Though that's not what CoDel says to do. >> >> In the CoDel draft you just don't drop below 1 MTU. You don't adjust >> target for the rate. There's no suggestion to increase interval >> either. It makes sense that long transmission times add to the >> expected rtt (SQM does this too). > > I know, I believe that K. Nichols recommended to increase interval, and = I > opted for the simplest additive increase (as effectively the expected RTT= s > increase by the amount of transfer time, and for asymmetric links we can > ignore the faster direction mostly). > Looking at the rationale in the codel RFC I now believe that scaling wou= ld > be the right thing=E2=80=A6 in theory smaller target better preserves res= ponsiveness > at a slightly higher bandwidth sacrifice, and with slow links I believe > responsiveness is more important; but then I wonder what is more responsi= ve, > a higher target ratio with a (smaller) estimated reaction time (in first > approximation interval gives the time we allow sender and receiver to rea= ct > to our signaling) or the theoretical better target ratio with an > artificially increased interval. I guess that needs data... Data always good. AIUI the ratio is about how low you can set target, before the bandwidth reduction becomes painful. I can imagine expected rtt increases e.g. in Tin 4, when it's de-prioritised because of exceeding the bandwidth threshold. I don't see why it would increase by over 400ms, in the 1Mbit/s case you showed. Regards Alan