From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (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 49EDF21F5E3 for ; Tue, 27 Oct 2015 12:04:09 -0700 (PDT) Received: by lffz202 with SMTP id z202so177629934lff.3 for ; Tue, 27 Oct 2015 12:04:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OmxKabVSp91x+FpOM64TWUFhjYBnnf4y2g1NjKbDFw0=; b=bFVP849mnP4dYzwDYE+8Ft5kfc3PIsoAhhQyb/RAfXBSaKzrrvxSFDDykGiFr6/fLZ 411A1ht3A6p9dwi29cuOWLJDlnTOiCkFBozjecz+oNDd1tpkavI9mqG1NS3T47q68KYN 7kFcIsigkDKPmch+vDNmMmZpk50uTrfY6oaixnJE7sDM5ETobQt43b1iQ7cAXD1jWDPF O30ndwRIFPQmaNZWvafCmqCKZ1v+DpmNcjjDS4Cx88kD8AuCRNO68qR9tzZKCXf6yyF8 ZEw62L1OrSKqpuTxE63/P2ppXnGXiCw3JiW384Hog3vLXoHuJmNTIuNnyjNYVwAeaANZ Mqzw== X-Received: by 10.25.21.83 with SMTP id l80mr14465063lfi.79.1445972647237; Tue, 27 Oct 2015 12:04:07 -0700 (PDT) Received: from bass.home.chromatix.fi (83-245-237-115-nat-p.elisa-mobile.fi. [83.245.237.115]) by smtp.gmail.com with ESMTPSA id s73sm7334094lfs.32.2015.10.27.12.04.06 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 27 Oct 2015 12:04:06 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Jonathan Morton In-Reply-To: <87a8r4mji9.fsf@toke.dk> Date: Tue, 27 Oct 2015 21:04:03 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8C854819-448B-42F9-850C-5B85D7885CFE@gmail.com> References: <87a8r4mji9.fsf@toke.dk> To: =?utf-8?Q?Toke_H=C3=B8iland-J=C3=B8rgensen?= X-Mailer: Apple Mail (2.2104) 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 19:04:32 -0000 > On 27 Oct, 2015, at 17:14, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >=20 > - Turn the hard packet queue size into a lower bound rather than an > upper bound. >=20 > - Scale the target to be 1/16th of the interval. >=20 > The first change allows Cake to actually reach the target throughput, > but it still takes a long while to get there. With the second change, = we > actually get the desired behaviour. 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. = That=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 BDP) 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. 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. The result from the second change is more clearly beneficial, but I=E2=80=99= ll put it in userspace (ie. tc) rather than in the kernel. 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. - Jonathan Morton