From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 5CF9A21F85B for ; Wed, 28 Oct 2015 10:44:09 -0700 (PDT) Received: from u-089-d060.biologie.uni-tuebingen.de ([134.2.89.60]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Las1k-1aKG0E232m-00kNNw; Wed, 28 Oct 2015 18:44:06 +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: <87lhankl4w.fsf@toke.dk> Date: Wed, 28 Oct 2015 18:44:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <87a8r4mji9.fsf@toke.dk> <751BA26E-3CC7-4341-99C6-2448111A07B4@gmx.de> <87pozzkns6.fsf@toke.dk> <87lhankl4w.fsf@toke.dk> To: =?windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:yVLPHENIIdOe2/d2kAfHygK/OQPQbBDNZESKi+h4HH6eOp/LH/3 bEfwD28N/zBY48AKOtR/VSMXeZcbgdfsS/1xvn2TtX1T99guQUp0ZNp2pSl4hrFcGNr3ckU ZcAYpyBSb32PJGsIDLe0SimRxCjhHPMOJWK5dKCw2Dd/gMq1rXMfVzfgcyjZT+SumtFFVx5 KqRSWTFTNTQa7c3o3/4PA== X-UI-Out-Filterresults: notjunk:1;V01:K0:IFgyu/dDFjE=:sQT3j/dxsC2IFSMp+rILUi U07O327yDzpMelyQ86px6ZHUYLymqTSAhZUMe+q7m17S8vSpGra1/FRncH2PVJ3UazR/J2t/g 4/l/IZn2sMnVA04rYxmPNTtctpFD0FY+Na7S9azAMtoL5Ul4AFpQoQMr11LqJU9U7woHj8l6E ZGlTCoJG3adNV5iU8XoicXAadZtdk/8eS3v8ClNIGVaTaUkKJDgdt/2oM2Mjp66UtSwAo7E3y 06DSDadik7nP1TG6FWb5zXJBdszfUZEhC990VJORaF8tNhI4LUQTu0j6sRu4KELUUBWlRoJ8K CCgikvIdor9ft8ituuJ4xERcrkc9s6Ie4KPCQpPfqzIrF9Lbg7+aVRvjfAeolbtaE/U6HyMSI 5j2Kaqo3meQVH97Gwki7z7oTIPEWwYGyLLWMwk64e+91IaQySHqB5jxSA/cBrduyC/eMJRHiO mxbOOHgGV1L+Gk6tswZN2ysLodsqh092XZXXi1up8F4k7Q67GVreCpsC5cE9SrUBCjMYvYROM FPagFcZj5I+FkLJlpGaWX1L+P4ZPv9G3IBUCvRw5W7NBzwbImxm0CY20h7yWSauwpI2wEr+fl jzG3XalK10OUa/s+1D5cfRIkbIJ94+078JaQKE3IY3JIxAFdFLjkI9RDx77lFwZUmEXAaWdL+ YMN6kJwmQFmW3gwrgQBxujXpEWYVfQGmyftDKRuqxJ20abJbIP5ePtbvrQLr0RIOuCzY1qGda 7x9YIsMjlDCJDLyd8Z0VaA+T27zUsXyTh2jg2et+3RzkiFWM0C0kBvOYsUBK+X/nguqTh6BmP 46vc8Iv Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] Running Cake at long RTTs 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: Wed, 28 Oct 2015 17:44:32 -0000 Hi Toke, On Oct 28, 2015, at 17:34 , Toke H=F8iland-J=F8rgensen = wrote: > Sebastian Moeller writes: >=20 >> Hi Toke, >>=20 >> On Oct 28, 2015, at 16:36 , Toke H=F8iland-J=F8rgensen = wrote: >>=20 >>> Sebastian Moeller writes: >>>=20 >>>> Except I requested rtf 120 ms and got 122.7, which admittedly is >>>> close. I know I repeat myself, but on of the is one things that >>>> irritate me in software is if software silently pretends to know >>>> better=85 Now 122.7 versus 120 might be in the noise, but look at = that: >>>=20 >>> I don't remember from where, but I suspect there's something wrong = with >>> the 'change' logic in Cake. Can you try removing the qdisc = completely, >>> then re-adding it, rather than doing a straight replace? >>=20 >> Good point: >> moeller@happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc replace dev = eth0 root pfifo_fast >> moeller@happy-horse:~/CODE/sch_cake> sudo tc-toke qdisc replace dev = eth0 root cake bandwidth 1Mbit besteffort rtt 100ms ; sudo tc-toke -s = qdisc >=20 > Right, so there's definitely a bug in the 'change' logic. >=20 >> Just 95 is not equal to 100 either=85 >=20 > That's also a bug as far as I'm concerned. >=20 >> At least in full automatic mode I would have assumed cake would also >> increase the interval according to the available bandwidth in the >> different Tins... >=20 > What has the interval got to do with the bandwidth? There's definitely > some value in capping the target to be at least the time it takes to > transmit one MTU's worth of data. Well according to codel=92s theory target shall be between 5 to = 10% of interval (I note this range is not deduced mathematically and so = 1/8 probably is well enough as is 1/16, heck even 1/32th might still be = good enough). So if we increase target we also should accordingly = increase interval to keep the relation correct. I believe your tests at = long RTTs have just shown that the theory is not completely off. So I am = willing to entertain the notion that adapting to slow bandwidths should = have an effect on target and interval=85=20 >=20 >> All the additional parameters are there to tweak and experiment. So I >> argue exposing knobs is not making it difficult to configure as long >> as nobody needs to touch these (I also volunteer to make the tc help >> more specific in that regard=85) >=20 > If no one needs to touch them, why are they there? At best that will > just make things break when they bitrot. Do you really envision lots of changes to cake after = upstreaming, as otherwise things should pretty much stay as well = debugged as when upstreamed: "no change no bitrot=94 or so. But the = point for exposing it that your experiments have shown that the = automatic defaults did not do the right thing, are we really sure that = we tested all relevant combinations of the parameter space to say, we = are done, the target interval relation is solved? Note I am fine with exposing some parameters only if the user = also adds a silly option like = =93willing_to_keep_the_pieces_if_cake_breaks=94 or is it crumps... >=20 > I can see how getting around the need for the encapsulation variables = is > going to be hard; Numeric overhead is all that is needed ;) > but for the target, I am not sure I see the value in > exposing this for "experimentation=94. But so far we have not gotten it right, so experimentation = was/is still required. > If we are sure that the relation > between target and interval should be fixed (and I'm not entirely > convinced of that yet, but will think about it some more), then = exposing > target is just going to enable invalid configurations. No, unreasonable maybe but not invalid; I am fine with cake not = accepting target > interval which I admit is invalid, but target =3D = interval/2 is valid no matter whether I think it is reasonable. If we go = the =93I know what is best for you route=94 we should be really really = certain that we actually do. But do we? The fact that we are having this = discussion makes me wonder a bit. The codel RFC give some guidance on the relation of interval and = target for TCPs = (https://datatracker.ietf.org/doc/draft-ietf-aqm-codel/?include_text=3D1 = Section 3.2) but we so far cake does/did not follow this guidance, = arguably recent cake was doing the wrong thing, exposed interval and = target would have made it possible for people using deployed sch_cake=92s = to fix the behavior. Currently the only redress is to edit the source = and build the module afresh, certainly outside the scope of cake=92s = =93make common things simple=94 motto, no? Best Regards Sebastian >=20 > -Toke