From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 DFB533B2A4 for ; Wed, 1 Mar 2017 17:48:37 -0500 (EST) Received: by mail-wm0-x235.google.com with SMTP id n11so10978411wma.0 for ; Wed, 01 Mar 2017 14:48:37 -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=/Yugo5NA7o+smVVsl3BY4wUizGq+hrH8xbhDmSY92p8=; b=e10eSQ/iqrxKFbbjJgSuRbCyNdUBUiC3PPAAjWB80/GhjAKCAH5TsnKzv+tb6OCM2W 6ctttPr/iajhQMFGR7a4E23ea2qK26RrXQzsIi45zv0ff4uS5mVbN3Jd1eeNlZXueFSt TtveqzCLyUpK2EbUIpUw8r3lEXJlAfHRnA+jIR3Q/ZPIvCymRGRI7HxM2wXyqq29bgeb y/v+cG1rqkOR3hu0tUNhspEoYCwCfppgGCKg/hH98NyqGm21WT4HzJlSWDfDeFilPPpU uN2jITlbgvH0CmT+eX2Fw6AvX+aHecX9eeHni7BcpubbsYysGSuEuG83810HWo0tQKEC qqfg== 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=/Yugo5NA7o+smVVsl3BY4wUizGq+hrH8xbhDmSY92p8=; b=B9vkTLlRAVFkR2AO8p3pSVSuKhzK78kByfAoP3/b9G1RWgwyYLXFyBgA9CDZz3Dv9Z loqImwh/VvMu2J28Z/gm5Pr+NHNYQ2sb+IVwI22kgHjQfso1eQ3OcJLNyZhIKkuXAigb YLGH2qZ3cmfpOAgUbBfr2RrLsaF/SOVJTC2ns452jmu9o7xVg6lEoHBs+0EdFe1XwGvr V/8H2fRtoS1Dv7S7RyaaWO9fbh7yPbLdsQ3/RQ7Q55vIpEg2TPJNJ+MZm6eycQx0Noi0 4FJBuC+S5x1jGb2k3jbNiqkbjeBKtNifq8fBWSxNhzy11Y0KsI0/NEDLpImYOkfLbUJf BdQw== X-Gm-Message-State: AMke39mqUTJvMiEAGQ5IWPY4jq30JhdFqXoDcfUb3D98ALk812H/8LbFsoti2m8jbJhLCA== X-Received: by 10.28.208.72 with SMTP id h69mr2939284wmg.100.1488408516340; Wed, 01 Mar 2017 14:48:36 -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 m188sm24598701wma.27.2017.03.01.14.48.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Mar 2017 14:48:35 -0800 (PST) To: Benjamin Cronce Cc: Sebastian Moeller , cake@lists.bufferbloat.net References: <75e10bac-f982-655f-0ef6-483a36797479@gmail.com> <6EA3F28B-2A50-4BDB-A0D4-B94207BFF1A4@gmail.com> <3c0c8aab-2a9a-82a4-0828-d58c604d35dc@gmail.com> <028AA856-B11E-4025-B1BD-84BAC6768508@gmx.de> <9353cc42-220b-af1b-3105-19be52ed0627@gmail.com> <3F9B4D98-ED26-4B56-812E-783CBBF64AAF@gmx.de> <46520682-a67e-e77c-3ccb-4944cc3739ec@gmail.com> From: Andy Furniss Message-ID: <98af9836-cd5e-c3dc-b863-e1fcb6c3bb5f@gmail.com> Date: Wed, 1 Mar 2017 22:48:33 +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: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Cake] 5ms target hurting tcp throughput tweakable? 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: Wed, 01 Mar 2017 22:48:38 -0000 Benjamin Cronce wrote: > I have not sampled YouTube data in a while, but the last time I looked it > had packet-pacing issues. With TCP going from idle to full, several times a > second. Not only do you get the issue that TCP will front-load the entire > TCP window all at once, but if the data being transfers fits within the TCP > window, it never learns to back down. If you have a 30ms ping to YouTube, > at 67Mb/s, your window is about 2mbits, which is about 256KiB, which is > about the same size as the request sizes to "stream", last I knew. > > Netflix is working on packet pacing for FreeBSD. After bufferbloat, it's > the next big issue. Interesting, I guess to some extent client behavior plays a part as well. I did another test with the same vid looking with a live ping monitor and "stats for nerds" on. In this case the spacing was 2 to 4 seconds, with the ping spikes matching the display showing buffer fills. I guess just changing the buffer watermarks to do more smaller reads would also be helpful in this case. Pinging at 10pps shows the spikes last 0.2 to 0.3 seconds on my 67mbit line. The CDN the data is coming from is only 9ms away from me.