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 7026D3B29E for ; Fri, 1 Dec 2017 13:09:14 -0500 (EST) Received: from nemesis.taht.net (unknown [IPv6:2603:3024:1536:86f0:2e0:4cff:fec1:1206]) (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 51E6121367; Fri, 1 Dec 2017 18:09:02 +0000 (UTC) From: Dave Taht To: Georgios Amanakis Cc: Jonathan Morton , Dave Taht , Cake List References: <98B33089-BA99-40C2-8C25-B4568505AAC6@gmail.com> Date: Fri, 01 Dec 2017 10:09:00 -0800 In-Reply-To: (Georgios Amanakis's message of "Thu, 30 Nov 2017 13:32:11 -0500") Message-ID: <87lgimgw1v.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 Subject: Re: [Cake] cake flenter results round 3 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, 01 Dec 2017 18:09:19 -0000 All this testing has inspired me to go pick up a cheap ($500!!!) 12 core Xeon box I found on craigslist, this afternoon. I'm tired of napping through kernel builds, and needed a space heater. If anyone else could use a build box and sim station pls send me a ssh key. I'd like to get some mips/arm/whatever qemu instances up also. Assuming it proves reliable, I'll converge it with my 10TB nas for packet captures. Georgios Amanakis writes: > Could you provide an example how to rate limit with netem? tc qdisc add dev eth0 root netem rate 20mbit That however creates a tail-drop per-packet queue. You can attach a sub-qdisc that more closely emulates the real link. Or use HTB. Or leverage SQM. Thing is, we've been living in a fantasyland (cake in both directions), and I'm thinking at least in the downstream direction, attaching a CMTS or DSLAM emulating tail drop queue would be useful (and depressingly, I am thinking that ack filtering will lead to even worse bloat on an un-caked head end). Your typical Cisco CMTS seemed to be 1000 1.5k packets max. Arris CMTSes (more common) - I can't tell. My best guess is that they have a 1000-2000 packet limit with GRO enabled, per subscriber, no matter the rate. Another way to emulate a range of CMTSes is to put a bfifo limit 256k, 512k, 1024k. DSLAMs have seemed to be in the 64k range. > What does "slot 4ms 4ms bytes 10k 16" Dave provided do? This is an attempt to emulate bursty mac (like wifi)'s behaviors. It will accumulate 4ms worth of packets, then deliver them all in a bunch. The "interesting" thing to me is the probable effect of the microburst on cake's deficit scheduler (and new ack filter) By additionally specifying bytes and packets you can get a max rate out of it, otherwise it is bound by the speed of qdisc_watchdog_schedule_ns. I goofed on the line above, it is actually: slot 4ms 4ms bytes Xk packets Y slot 4ms # minimum delay for a slot 4ms # max delay for a slot (it is REALLY hard to reason about things with these set for realism[1], so 4ms 4ms is sane for rrul testing. A one way test might be 1ms 4ms, with the ack-mostly side being 1ms 1ms.) bytes 10k # deliver X kbytes per slot. In this case, 10k * 1000/4ms per slot = ~25Mbit/sec packets Y - 802.11n does have a limit (up to 42) [1] worse, using 1ms-4ms would create a uniform distribution where the real distribution is very different and long tailed. (that's work pending) > > George > > On Thu, Nov 30, 2017 at 1:27 PM, Jonathan Morton wrote: > > If you use netem to simulate the physical link, you could test Cake's > ingress mode downstream of it. > > - Jonathan Morton > > > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake