From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 4BD383B2A4 for ; Fri, 10 Feb 2017 05:05:40 -0500 (EST) Received: by mail-wr0-x232.google.com with SMTP id 89so103981336wrr.2 for ; Fri, 10 Feb 2017 02:05:40 -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:message-id:references :to; bh=QGLlkXRgegNufVgMmABaHyQuwQYM1HiBBiVdFJ2eHsA=; b=R17pbylZYk1ifT/CVY1RBdW7Pwrl1O+kAs14QQjZOJaPBUIoARZF/VkNsGJZwarAgI w7tdPg9V8+sJq8XfHcfeMZu2uxfeBOQJxSQ1wHgyu0qGFqTFaMSaXmJGzvaWbsOblqpO tmrtJ/N/6rB2p03/RfTnCiRqcWkSK26gQbjKSgq+ZEck6kzUAA9y1ZQRec2e9fXVhLc5 KiJPPo89Mu/yoz+NLFMc819RAIEdy9mZYbFoPGuyqPagKLjHhiE2mbo8NcHPnWQC5rM9 dT1syHzXZ99G1ztwmFu2+Nla400M4LM+6sEJr2pBtJteMO0v/0qUKM5r/JHMxFI9rz6L fyAg== 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 :message-id:references:to; bh=QGLlkXRgegNufVgMmABaHyQuwQYM1HiBBiVdFJ2eHsA=; b=A/EgvAL9AUhasywHjHEkM/63gWTe/Sbi4uA97X3DUhNN2f1D8WB2has0RBB+JlAkzS us+InVmMO9LA+eazvDv8Z48gctzNyZ5x2GBI6fGYa6B6SfmZpEDFK5gyzhiUNkSkTxPy a4NtjGnwNuYOUDl1bFLpGx86WASl+xzEs3L/705o4dSKjmNTGr0Bd1dde1Lj5jjRCeHk Ll6a6UuZRhinrZqpmfEUOjCEhj6u8l1ELlEBpmzqYL9kxIGk88aioTxkKWI7J/rmAQDo udCrxj/w9HkXtxiJDKCO3HuLuvStTSXH/9LqS8px/ja32aIVsSYZ84HCkDBX2rXgX/lb nc8A== X-Gm-Message-State: AMke39nkvBvHHiE/s47So5wUkMSEX45IsVwHRmSu26+I1veddAb0G4neNRZcbyncH7vbFA== X-Received: by 10.223.177.202 with SMTP id r10mr6886730wra.94.1486721139142; Fri, 10 Feb 2017 02:05:39 -0800 (PST) Received: from [10.72.0.34] (h-1169.lbcfree.net. [185.99.119.68]) by smtp.gmail.com with ESMTPSA id 40sm1936525wry.22.2017.02.10.02.05.38 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 10 Feb 2017 02:05:38 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_C66CF4AA-50DA-478F-A5EC-87080D11A32C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Pete Heist In-Reply-To: <5BE2A225-4B9C-4F0F-ACC5-C23CCC873DF5@gmail.com> Date: Fri, 10 Feb 2017 11:05:42 +0100 Cc: cake@lists.bufferbloat.net Message-Id: <4B18C549-4CEF-4275-B9B3-CB8A046EB4EC@gmail.com> References: <459B9F17-317F-465E-8D2F-361CF47E5F32@gmail.com> <3D9E1A43-0182-4A1F-8262-6F587A79254E@gmail.com> <830143EE-20F2-42A5-A4FC-ECE7DF50C632@gmail.com> <652AA7A2-60C5-460F-AE60-CF4CB1D1D781@gmail.com> <5BE2A225-4B9C-4F0F-ACC5-C23CCC873DF5@gmail.com> To: Jonathan Morton X-Mailer: Apple Mail (2.3124) Subject: Re: [Cake] Cake latency update 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: Fri, 10 Feb 2017 10:05:40 -0000 --Apple-Mail=_C66CF4AA-50DA-478F-A5EC-87080D11A32C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 10, 2017, at 10:29 AM, Jonathan Morton = wrote: >=20 >> On 10 Feb, 2017, at 11:21, Pete Heist wrote: >>=20 >> Here are the results at various bitrates (all half-duplex rate = limiting on this CPU). >=20 > Hold on a minute. What does =E2=80=9Chalf-duplex rate limiting=E2=80=9D= mean exactly? >=20 > - Jonathan Morton >=20 Yes, that=E2=80=99s a good point, I probably invented the phrase = =E2=80=9Chalf-duplex rate limiting". :) It means that both the ingress = and egress have been redirected over the same IFB device and QoS'd = together. This seems to work better for the half-duplex nature of Wi-Fi, = because then you can use soft rate limiting to control the queue and = keep latency low while still allowing almost the full one-directional = throughput. You made the suggestion earlier on the Cake list to try it, = and it does work for me. By the way, in case you want to see the qdisc setup, it=E2=80=99s there = for each host under the qos_* sections on each page. The AP router is = =E2=80=9Cmbp=E2=80=9D, which I use for half-duplex limiting, then for = full-duplex limiting it=E2=80=99s done both ends of the link- =E2=80=9Cmin= i=E2=80=9D and =E2=80=9Cmbp=E2=80=9D. And if you want to see the QoS = setup script, it=E2=80=99s here: http://www.drhleny.cz/bufferbloat/qos.sh = But what I hadn=E2=80=99t noticed before is that I so far haven=E2=80=99t = seen the same throughput shifts in the so-called "full-duplex=E2=80=9D = rate limiting results, meaning I=E2=80=99m just limiting on the egress = of both ends of the point-to-point link. http://www.drhleny.cz/bufferbloat/cake_fd-eth-both_10mbit/index.html = http://www.drhleny.cz/bufferbloat/cake_fd-eth-both_20mbit/index.html = http://www.drhleny.cz/bufferbloat/cake_fd-eth-both_30mbit/index.html = http://www.drhleny.cz/bufferbloat/cake_fd-eth-both_40mbit/index.html = http://www.drhleny.cz/bufferbloat/cake_fd-eth-both_45mbit/index.html = http://www.drhleny.cz/bufferbloat/cake_fd-eth-ap_70ms_40mbit/index.html = And =E2=80=9Cfull-duplex limiting=E2=80=9D for fq_codel: http://www.drhleny.cz/bufferbloat/fq_codel_fd-eth-both_10mbit/index.html = = http://www.drhleny.cz/bufferbloat/fq_codel_fd-eth-both_20mbit/index.html = = http://www.drhleny.cz/bufferbloat/fq_codel_fd-eth-both_30mbit/index.html = = http://www.drhleny.cz/bufferbloat/fq_codel_fd-eth-both_40mbit/index.html = = http://www.drhleny.cz/bufferbloat/fq_codel_fd-eth-both_45mbit/index.html = = But what I _do_ see now in the full-duplex limiting results is not = throughput shifts, but occasional latency shifts for individual flows, = like in the 30 Mbit full-duplex Cake result: http://www.drhleny.cz/bufferbloat/cake_fd-eth-both_30mbit/index.html = and when I was testing lowering Cake=E2=80=99s rtt parameter I saw it = (perhaps unrelated to changing the rtt parameter), so here=E2=80=99s rtt = 70ms, bandwidth 40 Mbit: http://www.drhleny.cz/bufferbloat/cake_fd-eth-ap_70ms_40mbit/index.html = I=E2=80=99m still parsing all of these results and haven=E2=80=99t = figured everything out yet, so thanks for making me look at that again. = It does appear that the throughput shifts may be related to rate = limiting both egress and ingress over the same IFB device. However, I = have not seen such throughput shifts for HTB+fq_codel when rate limited = in the same way... Pete --Apple-Mail=_C66CF4AA-50DA-478F-A5EC-87080D11A32C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Feb 10, 2017, at 10:29 AM, Jonathan Morton <chromatix99@gmail.com> wrote:

On 10 = Feb, 2017, at 11:21, Pete Heist <peteheist@gmail.com> wrote:

Here are the results at various bitrates (all half-duplex = rate limiting on this CPU).

Hold= on a minute.  What does =E2=80=9Chalf-duplex rate limiting=E2=80=9D = mean exactly?

- Jonathan Morton


Yes, that=E2=80=99s a good point, I probably = invented the phrase =E2=80=9Chalf-duplex rate limiting". :) It means = that both the ingress and egress have been redirected over the same IFB = device and QoS'd together. This seems to work better for the half-duplex = nature of Wi-Fi, because then you can use soft rate limiting to control = the queue and keep latency low while still allowing almost the full = one-directional throughput. You made the suggestion earlier on the Cake = list to try it, and it does work for me.

By the way, in case you want to see the = qdisc setup, it=E2=80=99s there for each host under the qos_* sections = on each page. The AP router is =E2=80=9Cmbp=E2=80=9D, which I use for = half-duplex limiting, then for full-duplex limiting it=E2=80=99s done = both ends of the link- =E2=80=9Cmini=E2=80=9D and =E2=80=9Cmbp=E2=80=9D. = And if you want to see the QoS setup script, it=E2=80=99s = here:

http://www.drhleny.cz/bufferbloat/qos.sh

But what I hadn=E2=80=99t = noticed before is that I so far haven=E2=80=99t seen the same throughput = shifts in the so-called "full-duplex=E2=80=9D rate limiting results, = meaning I=E2=80=99m just limiting on the egress of both ends of the = point-to-point link.

http://www.drhleny.cz/bufferbloat/cake_fd-eth-both_10mbit/index= .html

http://www.drhleny.cz/bufferbloat/cake_fd-eth-both_20mbit/index= .html

http://www.drhleny.cz/bufferbloat/cake_fd-eth-both_30mbit/index= .html

http://www.drhleny.cz/bufferbloat/cake_fd-eth-both_40mbit/index= .html

http://www.drhleny.cz/bufferbloat/cake_fd-eth-both_45mbit/index= .html

http://www.drhleny.cz/bufferbloat/cake_fd-eth-ap_70ms_40mbit/in= dex.html

And= =E2=80=9Cfull-duplex limiting=E2=80=9D for fq_codel:

http://www.drhleny.cz/bufferbloat/fq_codel_fd-eth-both_10mbit/i= ndex.html

http://www.drhleny.cz/bufferbloat/fq_codel_fd-eth-both_20mbit/i= ndex.html

http://www.drhleny.cz/bufferbloat/fq_codel_fd-eth-both_30mbit/i= ndex.html

http://www.drhleny.cz/bufferbloat/fq_codel_fd-eth-both_40mbit/i= ndex.html

http://www.drhleny.cz/bufferbloat/fq_codel_fd-eth-both_45mbit/i= ndex.html

But what I _do_ see now in the full-duplex limiting results = is not throughput shifts, but occasional latency shifts for individual = flows, like in the 30 Mbit full-duplex Cake result:

http://www.drhleny.cz/bufferbloat/cake_fd-eth-both_30mbit/index= .html

and = when I was testing lowering Cake=E2=80=99s rtt parameter I saw it = (perhaps unrelated to changing the rtt parameter), so here=E2=80=99s rtt = 70ms, bandwidth 40 Mbit:

http://www.drhleny.cz/bufferbloat/cake_fd-eth-ap_70ms_40mbit/in= dex.html

I=E2=80=99m still parsing all of these results and haven=E2=80=99= t figured everything out yet, so thanks for making me look at that = again. It does appear that the throughput shifts may be related to rate = limiting both egress and ingress over the same IFB device. However, I = have not seen such throughput shifts for HTB+fq_codel when rate limited = in the same way...

Pete

= --Apple-Mail=_C66CF4AA-50DA-478F-A5EC-87080D11A32C--