From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2.tohojo.dk (mail2.tohojo.dk [77.235.48.147]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 8B05D21F538 for ; Tue, 27 Oct 2015 16:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at mail2.tohojo.dk DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=toke.dk; s=201310; t=1445990264; bh=yxQiU9Kyhebx592+Sy5ntAn5fYvM5INmggJkGEyK0Zo=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=CU/TNZbb29aDDdiobkldWJyt9a+dqNHs1YpLAxgPJ/O7Km4x+WVwhfUkYZQymWfwR skM8w1ZcV7UA7CqnT9WEKvz/4SRH+MkFvUobD0SkynK3C5awK+dXee5c989imrApsu lz/D3BqtPfhS9WlKfQdobpz5UkiEGFtlD7ujler8= Sender: toke@toke.dk Received: by alrua-karlstad.karlstad.toke.dk (Postfix, from userid 1000) id E70854E1219; Wed, 28 Oct 2015 00:57:43 +0100 (CET) From: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= To: Jonathan Morton References: <87a8r4mji9.fsf@toke.dk> <8C854819-448B-42F9-850C-5B85D7885CFE@gmail.com> Date: Wed, 28 Oct 2015 00:57:43 +0100 In-Reply-To: <8C854819-448B-42F9-850C-5B85D7885CFE@gmail.com> (Jonathan Morton's message of "Tue, 27 Oct 2015 21:04:03 +0200") X-Clacks-Overhead: GNU Terry Pratchett Message-ID: <87y4enuao8.fsf@toke.dk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Tue, 27 Oct 2015 23:58:11 -0000 Jonathan Morton writes: > The first change implies that the 10K packets * MTU default (ie. 15MB) > isn=E2=80=99t big enough, but the 50MB calculated by 4 * RTT * rate is. T= hat=E2=80=99s > a fairly narrow range, which suggests that the latter calculation is > correct. > > 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 B= DP) > should be about the right size for a buffer under these conditions. I don= =E2=80=99t want > to gain a false impression of what the minimum usable buffer size is. 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. > Limiting it to 10K * MTU was a safety valve to avoid the buffer size > exploding. With the first change in place, the =E2=80=9Cinterplanetary=E2= =80=9D > 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. 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? > The result from the second change is more clearly beneficial, but I=E2=80= =99ll > put it in userspace (ie. tc) rather than in the kernel. I'm not sure I agree with that. Putting it in userspace means basically exposing the target. 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. 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 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. That is most probably true. :) -Toke