Re: [Cake] Modification of DRR with deficit saving

[Sebastian Moeller <moeller0@gmx.de>]

Hi Dave,

> On Jan 4, 2018, at 16:42, Dave Taht <dave.taht@gmail.com> wrote:
> 
> On Thu, Jan 4, 2018 at 7:23 AM, Luca Muscariello
> <luca.muscariello@gmail.com> 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.

	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
> 
> '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 <chromatix99@gmail.com>
>> wrote:
>>> 
>>>> On 4 Jan, 2018, at 4:29 pm, Toke Høiland-Jørgensen <toke@toke.dk> 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 throughput
>>>> 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
>> 
> 
> 
> 
> -- 
> 
> Dave Täht
> 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