From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 210A13B2A3 for ; Sun, 5 Mar 2017 07:37:42 -0500 (EST) Received: by mail-wr0-x22a.google.com with SMTP id g10so99734706wrg.2 for ; Sun, 05 Mar 2017 04:37:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=VsII+CKCus7GXWaYfDWf2uqx9p3C8qp2imo1ko6MeLY=; b=ervdknsPhvmudTsDC+LEj5lJ+Y/fKl2DTvlz+e7WSCaDP3xSM9Fj6kVFD/eds7UN5H OluXUtZZ9NND7lBQ+xcyFrmb9cD9i0INa3OIT6WZkVi8UK2RqcwICK45hLhBMUNW/J6/ oxkXuko45rL2WU6QI1PcmZVBiGKUbalzPf3h1hIRQErBuRM15N9y17Dze5B9+QhEg/xD 5MueVjty5bDQrst+TUWgqQp4evy6xrTse7j5zAqBnTyBVGkRbFOQ3GiVE6rCT7k3cYsE 6Q9lxNzY82zgi5nByK6UzQFu7usulryONHv+Nz1ZWF/GXBUXtqunVMGwfxPiIHC5qdcH jq1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=VsII+CKCus7GXWaYfDWf2uqx9p3C8qp2imo1ko6MeLY=; b=cAMcHQclZms7KXcaz5t0V+rkRcQ1H6KdPVuQHeptMx1cvaJP0oFOxUfuJkpcI9/nYf Wp0ZW1498dpDplNWAjRshUXFzfFstSb4ptV+1q0InSUG9gvsAVDVBBhs1xHtr/MVKMjy 26dhuiCWLBbROWZFGoQOzJn4G9tMBFJnPeJsWdGN0ocSwEAl8ByEKPWnxEOv4yfv1+QW ryb61exRkJ8W+CVf9gE6FxhYh03JY8lQHl5oXqDQgGaL5Hs/U2P+OU7i4q4c/IWIgjsx NP+AfVSAw3M1PsYbRgpEUXsVdWBILhryPT/gdTKi19oSkhhCIpKcsAs0hg7iX74ZZfu4 yQxQ== X-Gm-Message-State: AMke39nDKYcwpA1OJ//XPYRJikgcutJAGpTe46yGAfX1gSLELKnAq3kHK1l2qf8fPg+rgg== X-Received: by 10.223.147.164 with SMTP id 33mr11406760wrp.42.1488717461146; Sun, 05 Mar 2017 04:37:41 -0800 (PST) Received: from [192.168.0.3] (189.182.7.51.dyn.plus.net. [51.7.182.189]) by smtp.gmail.com with ESMTPSA id t30sm22945426wra.52.2017.03.05.04.37.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 05 Mar 2017 04:37:40 -0800 (PST) To: Jonathan Morton Cc: Cake@lists.bufferbloat.net References: <752ad487-0826-ba92-6bbf-a46d031a10ee@gmail.com> <95D56BA5-0C5E-4D2E-B28F-A8C957B5F65D@gmail.com> From: Andy Furniss Message-ID: <325f92c7-e867-6511-f5c9-8f1f6f6abe2f@gmail.com> Date: Sun, 5 Mar 2017 12:37:38 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46 MIME-Version: 1.0 In-Reply-To: <95D56BA5-0C5E-4D2E-B28F-A8C957B5F65D@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Cake] low bandwidth default params best effort vs voice latency. X-BeenThere: cake@lists.bufferbloat.net X-Mailman-Version: 2.1.20 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, 05 Mar 2017 12:37:42 -0000 Jonathan Morton wrote: > Okay, I think I’ve worked out what is happening. > > At 250KB/s, it takes 6ms to get one 1500-byte bulk packet down the > pipe. This is unavoidable, so having a bulk flow competing with your > game traffic will always increase your peak latency by that much. > > With three independent game streams in play, it’s possible for them > all to transmit simultaneously *and* to coincide with a bulk packet > having just been sent. With overheads, it will take a total of 8.5ms > to get all four packets through. This corresponds nicely to your > best-effort results; you’re getting very close to the theoretical > best performance there. Yea, the pleasures of low bandwidth - not that I would have called 2mbit low a few years ago, and 8ms isn't that bad. Historically, I once had an asymmetric mss clamping setup so up tcp was smaller than down. > So Diffserv marking actually can’t improve your performance in this > particular case. But it shouldn’t make it worse either. You’re > actually seeing a nearly 6ms increase in peak latency, which > corresponds neatly to an additional bulk packet ending up ahead of > the game traffic in the queue. > > That’s not supposed to happen, but I think I can see how it *can* > happen with the current Diffserv logic. It’s a weighted DRR, much > like what is used between flow queues a little further down - but it > *doesn’t* have a special bonus for sparse tins. That’s something I > clearly need to fix. > > To help remind me, please do open an issue on the Github project. OK, I opened https://github.com/dtaht/sch_cake/issues/52