From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 D59D43B2A4 for ; Thu, 4 Jan 2018 10:42:48 -0500 (EST) Received: by mail-qk0-x22f.google.com with SMTP id l12so2032166qke.13 for ; Thu, 04 Jan 2018 07:42:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3d19o58OSk07WKwZ90sV4g9VaKMSnnfmxJGpezfflAQ=; b=sQBff18pDOMkeM8rAilBrE29yP9aQrVU4vv1GlhHYWfI+d0ES94xSBJ69kj1Zj0mIH n8C7BWOyz7tZMLjFffoSjHDe20GQV2GG81FXEmFHWB89dVXIjEWRrZi8kLDsW1SCTy/n IouGbrxWrGttXqqRrf3RcQ2ku0C3F01x2DBZ3RU0Qb+I/ExXQAWvEvPgsf8eeFjw/r0H DZk8lNmXBvuuDvZexx5xxU3gxTnmIAU7NvnU1BxvejKe7cXUfLzlMq8K/h37vmTu1ZB6 qdZW4Ia8cB7nfNlFQr1CI3JfGm/7jn9MAwCWSov8vWroiEaMI9jn/UPDRa9o+LWu+ZpN N1SQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3d19o58OSk07WKwZ90sV4g9VaKMSnnfmxJGpezfflAQ=; b=cAuC8dT3dWuiP/5evyChkDGka3KdqsrqRbBJz4VlUiTu0F+bPVnJ/QwhnUKU1WoEbK vzPSmJ+swVIf6xQzWAr3SgzEm59uHzVohXM1Gqr4Yjv3ol8/4oMPQlTqAUHlnQQLjlgs BerI4qPp4j9TOLA+3nVTu19KHSVLgGnKpREhtRhEFjV7TbBJU33XUhijSdEnvpw75Ww+ WiDIqfCOrz3SVo4suUxRCzDXkFlwVWm9uFIYjYcCSntuyTvBhS6h0DN+kEYrv5DNif0P wijI/7u0yJT6B9EBmAAakdoWc2W6S3hEKYA7CHefUYTaILotBOBqrejY/UZ0AbO6sRey 1yVA== X-Gm-Message-State: AKGB3mISfeNIcr2qdmwZotZxU29BHLVRWfJFSg43XvjRP3o5ULK0SbgE S/sX1ylxY5G+lG1IZE9xUprXhhWaw8wR7p/fqVM= X-Google-Smtp-Source: ACJfBosENRnf5WxMiqbE2/MIY18O8Xwek/P1m9NFZN1bqdhcvBAcQucm4Pe6iNQzTJWjIzcqmML/o1j9XgqlAlH7mOo= X-Received: by 10.55.154.213 with SMTP id c204mr6776110qke.327.1515080568409; Thu, 04 Jan 2018 07:42:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.193.93 with HTTP; Thu, 4 Jan 2018 07:42:47 -0800 (PST) In-Reply-To: References: <87bmi97l3w.fsf@toke.dk> From: Dave Taht Date: Thu, 4 Jan 2018 07:42:47 -0800 Message-ID: To: Luca Muscariello Cc: Jonathan Morton , Cake List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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:42:48 -0000 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: > > https://team.inria.fr/rap/files/2013/12/KOR05.pdf 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. 'course, while I disagree with this statement in the paper, and do care a lot about handling overload sanely, "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" 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. > > J. Roberts et al. Implicit Service Differentiation using Deficit Round > Robin, In Proc of ITC 2005. > > Luca > > > On Thu, Jan 4, 2018 at 4:01 PM, Jonathan Morton > wrote: >> >> > On 4 Jan, 2018, at 4:29 pm, Toke H=C3=B8iland-J=C3=B8rgensen wrote: >> > >> > This popped up in my Google Scholar notifications: >> > >> > https://atlas.informatik.uni-tuebingen.de/~menth/papers/Menth18b.pdf >> > >> > Basically, they are proposing to permit a queue to accumulate a larger >> > deficit while empty to allow light users to achieve the same throughpu= t >> > as heavy users (users being an endpoint with potentially multiple >> > flows). >> > >> > 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. >> >> They're trying to solve the same problem as DRR++ does, not the same one >> as Triple Isolation does. >> >> 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++. >> >> Not interesting at all. >> >> - Jonathan Morton >> >> _______________________________________________ >> Cake mailing list >> Cake@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cake > > > > _______________________________________________ > Cake mailing list > Cake@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cake > --=20 Dave T=C3=A4ht CEO, TekLibre, LLC http://www.teklibre.com Tel: 1-669-226-2619