From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 D313B3B2A4 for ; Thu, 4 Jan 2018 10:56:02 -0500 (EST) Received: from [192.168.250.102] ([134.76.241.253]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LeSOH-1fGfu80k8L-00qET0; Thu, 04 Jan 2018 16:56:01 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Sebastian Moeller In-Reply-To: Date: Thu, 4 Jan 2018 16:56:00 +0100 Cc: Luca Muscariello , Cake List Content-Transfer-Encoding: quoted-printable Message-Id: References: <87bmi97l3w.fsf@toke.dk> To: =?utf-8?Q?Dave_T=C3=A4ht?= X-Mailer: Apple Mail (2.3273) X-Provags-ID: V03:K0:FPxaKjFEacbf1yIN9019GulQC4ipUbNXRzooyt+FPaDAf/Bp4cA VEpBkzyxk6RcUY+IMiT8+/pF+z6Pa685xRoduwfQXyrZLlgAoqbJSg7RCgPdnoDoiddsh1n Pcjie/PJKXA6bVZuCQ/JGXZkfGbPoJdAooeO3O71bO2aZQPU7WYkPK6D2B6O81pwRf264Gm oUWyFDw+DtWBdBfieUhmg== X-UI-Out-Filterresults: notjunk:1;V01:K0:sjHSDfTMbAs=:MH9vNnyrsYpuZQ9P3I3AUn bi3PVXr0FYtvTxHZ4cp7QbRhCysp/Umkh3dxDmBeWzShNFNnIw0CNDfPF1+5Cqd5gkbaS3m57 n0xcLbzozKcdNuQfSuggxJJ8CFhuJ0dhk6PGzMucAd0qGUcCeIsw7LFkOnvzVIMDXPiVibq8W wO2AyiAYiKi7DE47RN97/0zZgLAQQGIEQCpiUsKkYy28eFx8TyTavvUXi8Btyr3nWSd84AAfy 0sDc7BLSpLC2rj8ayNCNgNHmW8/+viGPtAlx47C0rxv/M61eNO2YRVMJBiQm9pI1VB8UyrN7M tjnEVpMjN7EDXY+8WtJ4CR0P6rC/7IFy9SQOFMdcvdX8Ig23su4WMU6WucI5qBWE5mcd3VWl9 zjoyFHkNK0UmQOTrXpOFE/ub1Fd8G9JV+JrZKgvUBodfHqk+QeYgOaJ1xmeqEyEAmTKTBvdOg fntO35Z3K44STKrt2madArEG8zkzr11xODq8Y1p96MHxJSUXPEhILMP1l/JKdwdWzTYanOT58 hCoKCSpvK9X9cneEupqWOsjJFX+H1J7g+xWA41bMObA6XJhkm4GQbUWXDKt9B0m8EF8urHQKw Vs4J7mg4yH3xzB9VMXEkZ4BK4XoV+xzvDHAHeAFCSDv1fjxUs+XAWLcxezSkxJ4Hz6yvDLpGd aepJJWQ1NHeU7EgSeZINOQlIuzsNZS1ZsY2rp0d/408Wevj6ybnNUwDVOo1P0t2kyrF8/NIbF 4qNkGA0Xo8qehC9PTdBXDpVrxIjrxY0ICYDs1Omunj6FZVxC6N0fXVZfbGIVfCW3UhogAushs w+ZpgJXgvr87a30UOmsaRHLDjwoswAPhV7+y9+eKllQCs1tCBw= Subject: Re: [Cake] Modification of DRR with deficit saving 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, 04 Jan 2018 15:56:03 -0000 Hi Dave, > On Jan 4, 2018, at 16:42, Dave Taht wrote: >=20 > On Thu, Jan 4, 2018 at 7:23 AM, Luca Muscariello > wrote: >> I think the closest scheduler to Cake is this one, if I have to = compare: >>=20 >> https://team.inria.fr/rap/files/2013/12/KOR05.pdf >=20 > Try as I might, at workloads that I've been able to create (I did just > add 10GigE capability to my testbed), it's seemingly nearly impossible > to have more than a few hundred flows in memory (compared to > potentially thousands actually active), and it's unclear how to go > about thinking about it sanely.This tends to point to cake's 8 way set > associativity as being overkill, but haven't got around to trying > higher bandwidths, lower target RTTs, or, as I said, higher > bandwidths. Maybe if you set #define CAKE_QUEUES (1024) in sch_cake.c to = something smaller you might see an effect at lower speeds? Best Regards Sebastian >=20 > 'course, while I disagree with this statement in the paper, and do > care a lot about handling overload sanely, >=20 > "In overload, it is necessary to apply per-flow admission control in > order to preserve good performance for admitted flows. Note that no > scheduler can avoid drastic performance degradation when offered > traffic exceeds capacity. PDRR has the advantage of allowing" >=20 > I wish I had reasonable proof that what we do in cake is truly sane, > or had some curve to apply to flows per the available bandwidth. >=20 >>=20 >> J. Roberts et al. Implicit Service Differentiation using Deficit = Round >> Robin, In Proc of ITC 2005. >>=20 >> Luca >>=20 >>=20 >> On Thu, Jan 4, 2018 at 4:01 PM, Jonathan Morton = >> wrote: >>>=20 >>>> On 4 Jan, 2018, at 4:29 pm, Toke H=C3=B8iland-J=C3=B8rgensen = wrote: >>>>=20 >>>> This popped up in my Google Scholar notifications: >>>>=20 >>>> = https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth18b.pdf >>>>=20 >>>> Basically, they are proposing to permit a queue to accumulate a = larger >>>> deficit while empty to allow light users to achieve the same = throughput >>>> as heavy users (users being an endpoint with potentially multiple >>>> flows). >>>>=20 >>>> Not sure how useful this really is, but it's somewhat related to = Cake's >>>> src/dst user fairness feature, so may be of interest. >>>=20 >>> They're trying to solve the same problem as DRR++ does, not the same = one >>> as Triple Isolation does. >>>=20 >>> As a result, they've basically proposed a bugfix to the original DRR = (ie. >>> you should keep replenishing the deficit until it saturates, even if = the >>> queue is temporarily empty), without gaining the full benefit of = DRR++. >>>=20 >>> Not interesting at all. >>>=20 >>> - Jonathan Morton >>>=20 >>> _______________________________________________ >>> Cake mailing list >>> Cake@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cake >>=20 >>=20 >>=20 >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake >>=20 >=20 >=20 >=20 > --=20 >=20 > Dave T=C3=A4ht > CEO, TekLibre, LLC > http://www.teklibre.com > Tel: 1-669-226-2619 > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake