From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 43AD53B2A3 for ; Mon, 27 Feb 2017 14:26:25 -0500 (EST) Received: by mail-wr0-x234.google.com with SMTP id u108so29287517wrb.3 for ; Mon, 27 Feb 2017 11:26:25 -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=AgAmLPnNOCt0uQ/X8fai5yPuNq15gMLW/utfe3u+ldA=; b=LFkt6RcmGLtgHbnvRxmcxNKt3ihI8ojq1BIonFHiV8kAidQ9EjOtI4NZHMT5y1dkhn KCxem8uTI2huXQb1GRSkc700qJh6/DoyQHqsVtBMhyob1eYkfeGo77wo0C7qYVKAdrG3 zqoe3pb3C+Di0uMVjx2jo2MPoei+CPIGgrpC2ZRHzlV7eZXiZt0rLfpTUgRqqq46W4pe Q3FYTcAlu9v6G0SJ+uHLmYiMSE2TvTKN8aoHZJzfYXPt81Ctg8TDVGBtaejuT/xV4wZh TMXvTs+yS1UwrYlE2Z0MCB23Ad8EJSD1DAxBE+Jz4e6fbXHtEcfA4KFpqYMtcezBL9P/ /zCg== 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=AgAmLPnNOCt0uQ/X8fai5yPuNq15gMLW/utfe3u+ldA=; b=hjmDSbNlcVW6gi5eC0AmGL4daUNCYNG7A6gMB+AiG8gpoOMIeD+ySLmIY8ITs3fLtn JnFo/NE1nVh9D2i8NLkJv5Zlw3lT33Y3/rd9t63W11snNnQhjSDMTAo0mN5E+z4DXbyO YDyN5UeKWDMy75NBgF95MeuU9uuPH53KPOXNZg+wkYkOLJg8yY7Hr8/r1UoFT/wQj/qu 78TjSzNkSvV3n9j/mU+6pn9vTEM55W7wpQ4+KInPRDCqO4Vmcr6ksfUN8EX+UtXAdIzL T0/EJzidvAZq8DrMDpcwBAF5yyVMA9BphEedgac0kUsh3f0Z97kpI4tj0PLfCLLGZUG1 Wt1g== X-Gm-Message-State: AMke39kQdkTeGIQEUWuOuVcvJZghOsltpEGuGtKGgvpW2S/EG2UQxJaVPibg8wLfn413Pg== X-Received: by 10.223.170.157 with SMTP id h29mr15301331wrc.63.1488223584228; Mon, 27 Feb 2017 11:26:24 -0800 (PST) Received: from [192.168.0.3] (34.218.125.91.dyn.plus.net. [91.125.218.34]) by smtp.gmail.com with ESMTPSA id m29sm23497881wrm.38.2017.02.27.11.26.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Feb 2017 11:26:23 -0800 (PST) To: Sebastian Moeller Cc: Jonathan Morton , 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> From: Andy Furniss Message-ID: <46520682-a67e-e77c-3ccb-4944cc3739ec@gmail.com> Date: Mon, 27 Feb 2017 19:26:23 +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: <3F9B4D98-ED26-4B56-812E-783CBBF64AAF@gmx.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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: Mon, 27 Feb 2017 19:26:25 -0000 Sebastian Moeller wrote: > Hi Andy, > > >> On Feb 27, 2017, at 19:02, Andy Furniss >> wrote: >> >> Sebastian Moeller wrote: >>> Looking at tc-adv, I would recommend to use “rtt 50” (maybe it is >>> “rtt 50ms”) which allows to directly explicitly request a new >>> “interval” (which IIRC is corresponding to the time you allow for >>> the TCP control loop to react to cake’s ecn-marking/dropping) >>> “target’ will be calculated as 5% of the explicit interval, in >>> accordance with the rationale in the codel RFC. >> >> 50 is certainly better than 10, but still seems to hurt single a >> bit even on a close server. > > Oopps, what I meant to convey is that there is the numeric option > “rtt NNN” that allows to select the exact RTT/interval you believe > to be valid. I picked 50 just because I wanted to give a concrete > example, not because I believe 50 to be correct for your > experiments... Ahh, OK. > >> >> On more distant servers maybe even more - I am getting results >> that are too variable to tell properly at the current time (of >> day). >> >> http://www.thinkbroadband.com/speedtest/results.html?id=1488216166262542155 >> >> >> >> Almost OK, but with 100ms this test usually shows x1 and x6 the same. >> >> http://www.thinkbroadband.com/speedtest/results.html?id=1488218291872647755 > >> >> > Interesting. My mental image is that interval defines the time you > give both involved TCPs to get their act together before escalating > cake’s/codel’s signaling. The theory as far as I understand it says > that the RTT is the lower bound for the time required, so I am not > totally amazed that relaxing that interval a bit increases bandwidth > utilisation at a vert moderate latency cost (if any). The art is to > figure out how to pick the interval (and I believe the codel paper > showed, that at least for codel the exact number is not so important > but the ballpark/ order of magnitude should match). Seems to be a repeatable result. > >> >> Of course as we all know ingress shaping is a different beast >> anyway and would deserve its own thread. > > The cool thing is that ingress shaping with all its > “approximateness” (is that a word) works as well as it does ;) Yea, though I am always interested in any ingress specific tweaks. On my current line I have a 67 meg sync and the ISP buffer seems to spike to max 80ms then settle to 40 = luxury compared to when I used to have a 288/576 kbit sync adsl line with a 600ms remote buffer. Ingress shaping on that was a bit more "interesting", especially as I targeted latency for gaming. Back then I used to use connbytes and a short head dropping sfq (needed hack) to get tcp out of (no so) slow start quickly. Even on this line I can measure regular (without qos) tcp blips of 70ms when someone is watching an HD vid on youtube. Streaming is misleading description for this test at least, blipping would be better :-) Sacrificing 6 meg does make it better (bit variable 20 - 40ms), but the blips still show. The challenge of keeping the remote buffer empty ish without sacrificing too much speed is an interesting one. Until recently I didn't need to care as my ISP did QOS with AFAIK Ellacoyas. Unfortunately they had a big change in their network and for reasons unknown it all went pear shaped so they have turned it off.