From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.taht.net (mail.taht.net [IPv6:2a01:7e00::f03c:91ff:feae:7028]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 508C73B29E for ; Sun, 19 Nov 2017 15:41:32 -0500 (EST) Received: from nemesis.taht.net (c-24-6-113-161.hsd1.ca.comcast.net [24.6.113.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.taht.net (Postfix) with ESMTPSA id CA4EF21341; Sun, 19 Nov 2017 20:41:30 +0000 (UTC) From: Dave Taht To: Pete Heist Cc: Dave Taht , Cake List References: <4235D7B6-1CA6-4B57-BA00-97D3F7D44EFA@gmail.com> Date: Sun, 19 Nov 2017 12:41:27 -0800 In-Reply-To: <4235D7B6-1CA6-4B57-BA00-97D3F7D44EFA@gmail.com> (Pete Heist's message of "Sun, 19 Nov 2017 19:48:58 +0100") Message-ID: <8760a6rog8.fsf@nemesis.taht.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Cake] [RFC PATCH 4/5] q_netem: support delivering packets in delayed time slots 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, 19 Nov 2017 20:41:32 -0000 Pete Heist writes: >> On Nov 18, 2017, at 8:02 PM, Dave Taht wrote: >>=20 >> On Sat, Nov 18, 2017 at 5:18 AM, Pete Heist wrote: >>>=20 >>> On Nov 17, 2017, at 11:55 PM,dave.taht@gmail.com wrote: >>>=20 >>> Slotting is a crude approximation of the behaviors of shared media such >>> as cable, wifi, and LTE, which gather up a bunch of packets within a >>> varying delay window and deliver them, relative to that, nearly all at >>> once. >>>=20 >>> Nice=E2=80=A6 >>=20 >> Meh. It really is "crude", and I keeping kicking about ways to somehow >> emulate half (or less) duplex, variable rates around a mean, mcast, >> etc. >>=20 >> it IS very nice to have a rate limiter that actually behaves a bit >> more like wifi, and I hope to also add the new ack fitering stuff to >> it. > > I guess there may never be a way to make this perfect, only to try to rep= roduce > the behavior that matters enough to make it usable for testing. > >>> One of the things I also notice in my LAN tests is latencies for differ= ent >>> flows staying at more or less fixed (and different) positions relative = to >>> the mean in flent results. Those positions, and the mean, can change wi= th >>> each test run. Do you think this could result from the hashing to diffe= rent >>> hardware queues (four in my case) changing between test runs? >>=20 >> yes if you are using bql probably. Is it sch_mq on top? Only if you want unlimited mode, and birthday problems, and don't have cpu to burn. > > Yep with bql. I hadn=E2=80=99t thought about mq before. What my qos setup= scripts are > doing though is replacing the root qdisc (which now I see defaults to mq)= with a > single cake instance. With bql, should rather be leaving mq and putting f= our > cake instances underneath it? > >>> And is it >>> worth trying to simulate this effect, or not really? >>=20 >> Dunno. There are a couple ways to turn it off. > > Fair enough... > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake