From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 86DFA3B2A4 for ; Thu, 16 Nov 2017 04:50:44 -0500 (EST) Received: by mail-wr0-x233.google.com with SMTP id w95so4016655wrc.2 for ; Thu, 16 Nov 2017 01:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XUUdxN0SWFukJJz1PHXd2aU91paoIsfHd4vf8I6c1oU=; b=JN2Kx2F4CxjReBoCXYJVtn7Ywkp76c/16QKCsRsG1fI3SDdcrMxlUZEN3KiFQOF0mh v+YnKfVE4+wO5ct1JU0AR14fO2SZ0meeLlR8Y7YxyvfhNe8jW5ElBiQ+IWKTVWPUgUQ7 x5F2iABHpYwgB8pDUpbk4EKxocQ/COkXtDtqT8pBo1GaUCsyudOmH4r3cFg3AN+79MXi OG+tAvjfyMfjvkxlSQulpRDAs0LQP3M8XEaRwyJh7R4cIbFejJJjSCPljuBl0KGPW2B/ We2wH99pp7M/76PMH7v6Z6igGiUBkzgU+/NQrColO+xPGGC13e/oZ926ET5S8xIC/Iig jSEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=XUUdxN0SWFukJJz1PHXd2aU91paoIsfHd4vf8I6c1oU=; b=MuYik2SlEzn/12Q4uDUEilmyhX6sfhMTWK3L/OksX2k+QxS2H3BO97a0LKfj3TpxKO /1lTAXHLcw/Zy+Vrl03vJIEyygmVk60pVQP2oYy4BxMX4Cqxlhploq0fcC8Z8Oqm2ilQ F54XsQqmrYX4aL0wM40pi5ycF7HHnmbjPl50s+comNHMW/qYzBqQXekjKcnp7IjsdFj7 y0jW8FlmSxvip92+FMzot4edGdFy4hz1v0uyiz+nEFz53QaVU16KTQBn36/SAQ1DLaXp PobrqQ0XCv57AYDUhVKQehmtYccRVb9b4k+6oq/ZmZrGjoTFL7iUsG87XxOsb9by2zzV R7hA== X-Gm-Message-State: AJaThX4dnHpC3V/gmYdCJyXDPiB/hICmMNn8WvSNdkSFtisbpI3NKO65 yc2hZd7sKIDHfoJZu9hlJ9Q71m7N X-Google-Smtp-Source: AGs4zMb2N/WE5Q329+0NuqgwvCurkiXpc1/ggfXLWLjLIcdjlukZUCQKyh6xGiGeUVRINBgAovmiVw== X-Received: by 10.223.179.26 with SMTP id j26mr1031714wrd.123.1510825843466; Thu, 16 Nov 2017 01:50:43 -0800 (PST) Received: from [10.72.0.130] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id l130sm745258wmd.47.2017.11.16.01.50.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 16 Nov 2017 01:50:42 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: Date: Thu, 16 Nov 2017 10:50:41 +0100 Cc: cake@lists.bufferbloat.net Content-Transfer-Encoding: quoted-printable Message-Id: <42A83821-6763-4732-95D0-01FA809ED6ED@gmail.com> References: To: Dave Taht X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] Cake upstream Planning 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: Thu, 16 Nov 2017 09:50:44 -0000 > From: Dave Taht > To: Pete Heist > Cc: cake@lists.bufferbloat.net > Subject: Re: [Cake] Cake upstream Planning > Message-ID: <87375f71h3.fsf@nemesis.taht.net> > Content-Type: text/plain; charset=3Dutf-8 >=20 > Dave Taht writes: >=20 >>> So yes, we can lower TCP RTT with these more aggressive settings. = But just to >>> make sure, we=E2=80=99re confident that there are no other side = effects from these lower >>> targets and intervals? Is there anything else I should test for to = be sure? For >>> example, when I rate limit to 950 Mbit and try the same test above, = =E2=80=98lan=E2=80=99 causes >>> a 20% drop in throughput vs the defaults. That may be from an = overtaxed CPU, but >>> I don=E2=80=99t know. I also wonder how this affects routed vs local = traffic. I=E2=80=99ll try >>> to test this at some point, as I want to understand it better anyway = to know how >>> backhaul links should be configured... >=20 > One interesting thing that might make tcp behave better is the new > pacing code which lets us set pacing to a different log value. = Presently > - at 10 - the TSQ algorithm recalculates things at 1ms. The pacing = value > is intended to be changed to, say, 6 or 7 to make wifi work > better... and I suspect, that if it were upped to, say 12 (250us), on = ethernet, > that might make pacing more effective there. >=20 > Just like breaking the sound barrier, breaking the 1ms barrier looks = to > be hard within conventional kernel thread scheduling. To make sure I understand, setting pacing means setting a socket option = at the sender, right? A TCP RTT of ~=3D 1ms with the =E2=80=98lan=E2=80=99 keyword is already = quite good, and not something likely worth trying to optimize right away = anyway.=