From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 DAD3321F52C for ; Wed, 28 Oct 2015 02:36:57 -0700 (PDT) Received: from u-089-d060.biologie.uni-tuebingen.de ([134.2.89.60]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0M8mCe-1ZluZc1jtk-00C7gC; Wed, 28 Oct 2015 10:36:52 +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: <87y4enuao8.fsf@toke.dk> Date: Wed, 28 Oct 2015 10:36:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1CACB869-2FBF-4392-BA4F-2586472800C3@gmx.de> References: <87a8r4mji9.fsf@toke.dk> <8C854819-448B-42F9-850C-5B85D7885CFE@gmail.com> <87y4enuao8.fsf@toke.dk> To: =?windows-1252?Q?Toke_H=F8iland-J=F8rgensen?= X-Mailer: Apple Mail (2.1878.6) X-Provags-ID: V03:K0:bk0chnSSgCZHOVbvzT9lz4YE/3X1zhaTV6T3dyy4RxmthelKYNc 1fPX7NmF3ulARJ5NXzH0N0aGR30nu25SRaKRf7GsJ6CnM2eP/N3tplQfZ6mW59UizZWdYSr Mwky1SOLwN2UvMozUqV28vNHEmBa3ccnWTlhQ+KLm4LFe81nOXKiBo4v8J8WaHL2Pkf0fWC 9fAhu5cRhO1UXW8NMjLgg== X-UI-Out-Filterresults: notjunk:1;V01:K0:Z6qznW+Allo=:gxyPSkwJhqXwG+GH/Qele7 zqlVvrxpoNlWcLQRLuDqWKI1Gq8IPtYG4jsRpY6cGMdVRL7BxkoR2LFM9zEkKy6jl5oEf1E0s 8Z1Q2TMwrQ6VZ3ONz2UwK8GT0WhmJRfVdexCy6/1fbvkI3JBk2uI9OC5YktWCkrn0c/5Kkv3c 2ibQkyzBFIn9ou3VXkgpzZysMoL9Iw2BeCueaH1I2mVboy1q+v1U//g051YA+lbvAS7cby/j3 TIV4y17C8ShIoHhFpp1WNDeYtZxujfQiT+EoDWotq9TrFlENIJRtl5YtYzUH+uJfO08XL8SXC AdpXOQtvDBoHvntKkvfr4U4oIPJ0QqULnupdpbsHHMIHncxiUns0UWBi6ImYKQTM+xVcsQHMG B3dmuOZSsvTaq1S6qgZWDXRcRLsvVgHFoH8QrmVlHOPnUB2yChZdg3P/Cq90tKk2iFpXPamlE zuHLNPH1dQ2VrvPWchJgBXvNU3wG6xGaZcgDLNqRqDoy4n8yCzq8Gb9elqoL/2RxMA6LwFlYM j42auCGsHqBOMjrFoT24u71InTuZSFlDDowU2Gd5cNZMZEewfNscf90mz4v2W5nyAamQQD6k0 59fUArrVaEbys/NB1ncSFVVj9/QD8vd9rmEFZJPgRv7moxWXE/7sATyXd4bRkDfAFkCXZgFJQ L3erIdZ2AZ+pi8vqIvP9ix0SMEH018/Q3O+8VY8kTB1irh2qdsTinrjfn3v2EWuq5PAfge84k dJ60JFD2DmNKMcJLB2UIrGLsNiyskBeglfTDn+ryWjqPV2X2H04umUEk68vOjGSPFDv44Xh1d hM2xG0a 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 09:37:20 -0000 Hi Toke, hi Jonathan, On Oct 28, 2015, at 00:57 , Toke H=F8iland-J=F8rgensen = wrote: > Jonathan Morton writes: >=20 >> The first change implies that the 10K packets * MTU default (ie. = 15MB) >> isn=92t big enough, but the 50MB calculated by 4 * RTT * rate is. = That=92s >> a fairly narrow range, which suggests that the latter calculation is >> correct. >>=20 >> However, have you tried it with just the second change and not the = first? >> Conventional wisdom suggests that 15MB (which is slightly more than = one BDP) >> should be about the right size for a buffer under these conditions. I = don=92t want >> to gain a false impression of what the minimum usable buffer size is. >=20 > Well, indirectly: The first change was actually to address the problem > that Cake with CoDel turned off (i.e. interval 300s) did not achieve > full throughput. Changing the buffer size fixed that. Guess I can go > back and revert that and try again; will do so tomorrow. >=20 >> Limiting it to 10K * MTU was a safety valve to avoid the buffer size >> exploding. With the first change in place, the =93interplanetary=94 >> setting effectively removes any limit on buffer size as well. This >> makes me deeply uncomfortable. Instead, we should arrange to = configure >> the safety-valve limit when accommodating LFNs. >=20 > I agree that some sort of safety valve is probably needed (as is a > minimum; but that's another matter). Perhaps just setting the limit > higher could be a pragmatic solution? Might I propose again to actually expose the hard maximal limit = somehow to user space? Both 15MB as well as well as 50MB will wreck = havoc on my poor 64MB wndr3700v2. I believe other qdiscs allow to = control the maximum buffering (at least approximately, since a buffer = limit in packets will ignore all the sib overhead that seems relevant; = ideally I would like cake to honor what ever hard limit the user set). >=20 >> The result from the second change is more clearly beneficial, but = I=92ll >> put it in userspace (ie. tc) rather than in the kernel. >=20 > I'm not sure I agree with that. Putting it in userspace means = basically > exposing the target. I believe it already is exposed, so if this is unwanted we = should change this back before upstreaming? > Even if it's not recognised in iproute, it will be > exposed in the netlink API, which sooner or later some other tool is > going to speak. We will then risk ending up in a situation where the > target is set arbitrarily, leading to a need to print out what it > actually is; which in turn brings us back to having exposed target > completely. If I might repeat my opinion here, let=92s expose it, it is one = thing to be pro-active and have well working defaults that do not need = manual intervention, but it is a totally different thing saying =93trust = me I know what is best for you=94. >=20 > Now, I'm not ruling out that exposing target may eventually be the = right > thing to do. However, I do like the simplicity of having only the one > parameter; so if we can avoid it I think we should. I guess more > experimentation is needed to answer this. I would argue that cake should do what we consider to be ideal = by default without user intervention, and if the user starts specifying = things it should honor them (still using its heuristics for the = parameters not explicitly specified), though cake might complain to = syslog that it thinks the user requested something silly. It is fine to = reject the impossible ;). The advantage of exposed knobs is that it = allows experimentation without recompilation from source... Best Regards Sebastian >=20 >> I think the patch as given has some unintended consequences. Scaling >> target with interval also means I have to take more care with the >> threshold calculation, since the threshold scales with the product of >> the two. >=20 > That is most probably true. :) >=20 > -Toke > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake