From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::233]) (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 B843821F2FA for ; Mon, 16 Nov 2015 04:41:48 -0800 (PST) Received: by lfaz4 with SMTP id z4so22239569lfa.0 for ; Mon, 16 Nov 2015 04:41:46 -0800 (PST) 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=Ah4zGRLNebGvxsgQt+L8AkPQNvyftCMCm818e9M0VIc=; b=GuDOSAofFabWLXlUnFJKtjbMXqerXSTyF+nj54firUsz91PsypFMmrKLDMqlB62KVh BkESQJ5H6XJ6TtPU/KWFlIX3eD8GrIFH2sLFLfS/eeLc0JUSkH0JMuQYNHg9WfVOJOFN CNo+JmQCvipR2a3hWP0G7uImDteU9txHd20RqDgKURScb/fzU3uiE2t1BCfYHHgXGx45 nG4USjvSX38K42XXoftumN5t8D93ekk+xqIZsNMuB4bk1y+v1XrmuAdIHAlOFHvrpgQJ +K0vqm+1PGyWoZT3FMIeRzGfUeaveOOid+5sKRyncoDz4O1fyBIOIjMYtF/4KYG9sfE+ +f4g== X-Received: by 10.25.164.66 with SMTP id n63mr16651687lfe.24.1447677705995; Mon, 16 Nov 2015 04:41:45 -0800 (PST) Received: from bass.home.chromatix.fi (83-245-237-30-nat-p.elisa-mobile.fi. [83.245.237.30]) by smtp.gmail.com with ESMTPSA id ak1sm5452763lbc.2.2015.11.16.04.41.44 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Nov 2015 04:41:45 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) From: Jonathan Morton In-Reply-To: <5649CA7A.5060706@darbyshire-bryant.me.uk> Date: Mon, 16 Nov 2015 14:41:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7983D5EE-9FF7-41AC-8F84-406EF7DB742F@gmail.com> References: <5638A4F4.2010701@darbyshire-bryant.me.uk> <87si4nntcg.fsf@toke.dk> <0196FDEC-50A7-4ECA-9973-1FD23FF2945A@gmx.de> <877flznq3f.fsf@toke.dk> <848953E5-8571-4B81-B67F-D4A7BA4A1F96@darbyshire-bryant.me.uk> <8737wnnpco.fsf@toke.dk> <563B86D4.6030704@darbyshire-bryant.me.uk> <563F21AE.5040506@darbyshire-bryant.me.uk> <56408DAB.6080106@darbyshire-bryant.me.uk> <0B75A2D1-80FC-4499-8DCD-FC2C4E150448@gmail.com> <5649CA7A.5060706@darbyshire-bryant.me.uk> To: Kevin Darbyshire-Bryant X-Mailer: Apple Mail (2.3096.5) Cc: cake@lists.bufferbloat.net Subject: Re: [Cake] More on 'target' corner cases - rate/target/interval confusion? 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, 16 Nov 2015 12:42:11 -0000 > Video & Voice can gang together to claim 3/4 bandwidth > still leaving 1/4ish to be battled between bulk & best effort=85 That=92s the intended behaviour of the current settings, since Voice = borrows all the bandwidth it uses from Video=92s allocation. With Video reduced to a =BD allocation, Video + Voice should also be = limited to =BD in total if there is competing saturating traffic. It=92s = possible that you haven=92t altered the =93bandwidth balance=94 DRR = weights to match the new allocations, which might cause such an = artefact. >> The tin-specific tuning of target and interval was introduced when = Cake had a separate hard shaper per tin. It was the obvious design at = the time. Now that Cake uses soft shaping between tins (allowing any tin = to use the full link bandwidth if uncontended), it=92s possible that = choosing identical target and interval for all tins might suffice. = Alternatively, we might choose an even more conservative strategy. >>=20 >> But which - and how do we decide? > I've no idea! I tried the following experiment: set ingress & egress > b/widths to 2mbit & 448kbit respectively (like my parents adsl...on a > good day) Ran a 'rrul8_splittin' and noted ping box_plot for each tin = - > EF was about 30ms higher (120ms) than CS3 (90ms) Thinking I'd found a > smoking gun and that 120ms was quite close to the EF target of 140ms I > tweaked code to copy tin 0 target across all tins ..... it barely = made any > difference at all! Since you=92re using saturating traffic in all tins, Voice will be = operating in =93deprioritised=94 mode to penalise this abuse, so a = higher latency is entirely expected. If you delete the EF bulk flows = but leave the latency measurements in place, you should see a big = latency advantage. As I tried to explain before, the Codel settings affect latency and = throughput *within* flows rather than *between* them. Since you are = presently measuring using a between-flows methodology, it=92s not = surprising that you saw no difference. - Jonathan Morton