From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (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 517D521F1C1 for ; Sun, 8 Nov 2015 08:36:49 -0800 (PST) Received: by lbces9 with SMTP id es9so15003126lbc.2 for ; Sun, 08 Nov 2015 08:36:47 -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=O3druxhj0eUjUWoAcF6VRqtuFOOR07vq7hYnNdtCis8=; b=dUCx9OmKa1dPgBo29K4QuhivWg8ZUYcnHDJXW0XPaImixnn8KZvXNtCikM3I6/bsuJ eYoZjwIFZ29MJkgloahwdfnsHtwGaIzzWfTVeqkmi2Rks0fG2gzg9yWudD+OP8MTHAqK v//kSTwC7hjTdLkNdJ1XN2vrgxUkQ5JhsaY6rbCg+TjlgVn2HW8pE7zHAc1RLaCOPTg8 gMrHUvk4tZCzbXFFnffY4XFoBsUn6P3VyuMyQyv4/nU1OGEhQVeU7lm5HBQGz58CT0PP yCbh7jZr3rTr7J16WoPena51VsGy3DpfFA9+yfz8HnCl83DRqqQDhMxHbtLwWO+lcbAR ljrg== X-Received: by 10.112.188.168 with SMTP id gb8mr11729580lbc.6.1447000607138; Sun, 08 Nov 2015 08:36:47 -0800 (PST) Received: from bass.home.chromatix.fi (83-245-237-101-nat-p.elisa-mobile.fi. [83.245.237.101]) by smtp.gmail.com with ESMTPSA id f8sm1676028lbv.6.2015.11.08.08.36.46 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 08 Nov 2015 08:36:46 -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: <563F21AE.5040506@darbyshire-bryant.me.uk> Date: Sun, 8 Nov 2015 18:36:44 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: 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> 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: Sun, 08 Nov 2015 16:37:12 -0000 > On 8 Nov, 2015, at 12:19, Kevin Darbyshire-Bryant = wrote: >=20 > Whilst I was there I also subtly tweaked the diffserv4 video tin > bandwidth allocation to 11/16ths rather than 3/4. In combination with > voice (1/4) it meant that (theoretically) best effort could be > completely starved, let alone bulk - it doesn't seem to actually = happen > in real life, but setting video to 11/16th & voice to 4/16th means = that > there's 1/16th to be fought over between best effort and bulk - and = best > effort as a result does seem to get a little bit more of a look-in in > the face of 'more important' competition. Actually, the =93threshold=94 mechanism doesn=92t implement the priority = queue at all, but only switches the underlying DRR weights between = =93priority balance=94 and =93bandwidth balance=94. Since it=92s = fundamentally DRR, and the weights of the queues never go to zero, there = is no possibility of starvation. Additionally, the threshold mechanism = itself =93borrows=94 bandwidth from lower tins to serve higher ones - = this is a holdover from an earlier version when there was indeed a = separate hard shaper per tin. It *is* possible that the per-tin choices of target and interval might = want tweaking, but it=92s probably best to have some hard data for the = effects of doing that. One possibility is that target should be tuned = for the worst-case (minimum) bandwidth under maximally saturated = conditions, rather than the raw threshold value. - Jonathan Morton