Would making it active only for the 'ingress' mode be an option?

Otherwise it has to be documented that when using ingress mode with lots of bulk flows on <20mbit/s the actual goodput is going to be less than the set one (eg for 9.8mbit/s set, 5.3 mbit/s actual).

On Wed, Apr 18, 2018, 12:25 PM Dave Taht <dave.taht@gmail.com> wrote:
I would like to revert this change.

On Wed, Apr 18, 2018 at 9:11 AM, Toke Høiland-Jørgensen <toke@toke.dk> wrote:
> Jonathan Morton <chromatix99@gmail.com> writes:
>
>>> On 18 Apr, 2018, at 6:17 pm, Sebastian Moeller <moeller0@gmx.de> wrote:
>>>
>>> Just a thought, in egress mode in the typical deployment we expect,
>>> the bandwidth leading into cake will be >> than the bandwidth out of
>>> cake, so I would argue that the package droppage might be acceptable
>>> on egress as there is bandwidth to "waste" while on ingress the issue
>>> very much is that all packets cake sees already used up parts of the
>>> limited transfer time on the bottleneck link and hence are more
>>> "precious", no? Users wanting this new behavior could still use the
>>> ingress keyword even on egress interfaces?
>>
>> Broadly speaking, that should indeed counter most of the negative
>> effects you'd expect from disabling this tweak in egress mode. But it
>> doesn't really answer the question of whether there's a compelling
>> *positive* reason to do so. I want to see a use case that holds up.
>
> What you're saying here is that you basically don't believe there are
> any applications where a bulk TCP flow would also want low queueing
> latency? :)
>
> -Toke
> _______________________________________________
> 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