From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass DE-1" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id BBDEE21F53C for ; Mon, 2 Nov 2015 03:17:45 -0800 (PST) Received: from u-089-d061.biologie.uni-tuebingen.de ([134.2.89.61]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0Lhfu5-1aF7o228J7-00mreG; Mon, 02 Nov 2015 12:17:39 +0100 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sebastian Moeller In-Reply-To: Date: Mon, 2 Nov 2015 12:17:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D22BEFF-B6B6-4348-B83E-3AB76F933BDF@gmx.de> References: To: Alan Jenkins X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:PDFt/6hieApez+9SpbTPapToARyK3xSYX0/RfKAVVG7OU4wdcDk zvhM8TsCP+KueEBPr9M7QOnZELx4wUvJ6h7s+cyKkUcY/ZsNtCaxLYS/2MJK4DQeNXMC5xC oPfBEIHDdeTtFgvTRdNSja1Uy8m1fQcbHOhRz1Viep5WZNS8PhofVoAzcSPJhzX/P6/VHN3 49l79L+7YL5V8Qe3kUehw== X-UI-Out-Filterresults: notjunk:1;V01:K0:JEZI+i2PNXw=:gVcdPdWH/oyLDNRPmNr2za WmIzqBaomDa79xsKEnAwvRVFVVHi4+/FVtxUyTLcAfrxyuan1PQCXhqK79bqCjthmEQEtKVFL 3oeieRZ+E2+t9wylgLlMjYwk1mYC3nXN+QVbcLsod0vupGl3PDP3bik79/1cPIB4Y2ofSepPu arMQ/4gjgX+mnQIzvyHCS71rJ+taeBcqzqFeRGY2U1uBQtOZjTexBdCCjZhvoZ9WNBNvOXcEC hkcKoQf8dsLkV6SnnGUbchnRcU6StlODEH3+VZawY/GdrrNZL0F3yed6pVF/jeUTvI1yABdwB s7hwgzmYl0PsCBwDnp0EsH7rSbsRQKzwEGBaolduDrngbKDFuqQf2cNySeTPixa2kY5TTL+Ir qa3KBHZg/Ke1JrJZZ9phhSPS0pStqJn+T8bu03WIV/eTHmaExzBpfxOa6UvVISKMQMP038aAB 9lejFQO6zox8ndr3YjGwjQ/t+kFXGXtcQRo1zQbX2FUWB2PBe38C+l6aSr2E5AuXy+1bBWJsv jhuKla3jH2QnLTuOLVce7gblOKn8yp+1BaD1PaiteQubJ2ZpGfiGzZlhKJRNyHpEgAJmUllQa UTdo+opTiUWW4gBnvXZzmyZtjr/RitPvcDla89ZU88VEED4xMPgTLfYzAolwrMeOx+euLQDeG s7jHIKdWQC+fW3Lm/wbCvnKNpFHCjSLz8pUbvyyFQKO0lki/b9cysSIThL2NOkI676KJz9vG0 u6x6Ijg9kFy49vp6B++lfU4CFupS+Rl4oYp2erjHrhevkq+DCdHCwvx82Kj5hhaqeTpZf4BwH +50OIzI 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 11:18:08 -0000 Hi Alan, On Nov 2, 2015, at 01:20 , Alan Jenkins = wrote: > On 01/11/2015, Kevin Darbyshire-Bryant = wrote: >>=20 >> Can't give full explanation now but the bytes per ns calculation = which is >> used as a basis for target on 'slow' links uses mtu*1.5 >>=20 >> -- >> Cheers, >=20 > Right. And mtu*1.5 matches better than my math, if I look at Sebs > figures again. Oops :). >=20 > 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 ideal 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)... >=20 > Sebs 12.5% is indeed 1/8th. (See last line). >=20 >=20 > u32 byte_target =3D mtu + (mtu >> 1); /* MTU * 1.5 */ > ... > byte_target_ns =3D (byte_target * rate_ns) >> rate_shft; >=20 > b->cparams.target =3D max(byte_target_ns, ns_target); > 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 = highlight that we need a better description of what cake does to not = confuse future users, sorry for that. >=20 > Maybe this keeps the target/interval ratio from going too far over the > recommended 10%. Though that's not what CoDel says to do. >=20 > 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). =20 I know, I believe that K. Nichols recommended to increase = interval, and I opted for the simplest additive increase (as effectively = the expected RTTs increase by the amount of transfer time, and for = asymmetric links we can ignore the faster direction mostly).=20 Looking at the rationale in the codel RFC I now believe that = scaling would be the right thing=85 in theory smaller target better = preserves responsiveness at a slightly higher bandwidth sacrifice, and = with slow links I believe responsiveness is more important; but then I = wonder what is more responsive, a higher target ratio with a (smaller) = estimated reaction time (in first approximation interval gives the time = we allow sender and receiver to react to our signaling) or the = theoretical better target ratio with an artificially increased interval. = I guess that needs data... > I can't see what the justification > is for `target * 8` though. If there's a good reason maybe it could > use a comment. I fully agree, and hopefully not only in the code but also in = the man page as that has potential to confuse users if not documented = (and even if in the man page it will still cause confusion at least we = can say RTFM ;)) Best Regards Sebastian >=20 > Thanks > Alan