[Cake] Long-RTT broken again

Sebastian Moeller moeller0 at gmx.de
Mon Nov 2 13:29:48 EST 2015


Hi Toke,

On Nov 2, 2015, at 17:53 , Toke Høiland-Jørgensen <toke at toke.dk> wrote:

> Hi Jonathan
> 
> I see you reverted the in-kernel target scaling and reinstated the limit
> on max queue length.

	Not that I have much leverage here, but a) not exposing the limit control to user space and b) not honoring as a hard maximum limit is not a road to success; unless one defines success as "causing un-enforced OOMs”.

> Well, TCP now once again can't fill the pipe at
> long RTTs when running through cake; see attached plot. And yes, the
> userspace code did set target to 62.5ms here.
> 
> Since you obviously didn't like my previous fix, could you please do
> something else about it? The current state is quite obviously broken.
> 
> kthxbye,
> 
> -Toke
> 
> P.S. I still think the scaling of the target should be in the kernel,
> and that target should not be exposed to userspace at all.

	I beg to differ; this is rather another argument for exposing target to user space, if even we, arguable one of the groups on this planet most sensitive to the nuances of codel behavior, consistently get this wrong, maybe exposing target as a mechanism around failed auto-tuning strategies has some merit. I want to add I do not buy the argument that this will disincentivate “researchers” to play with target (after all this is just a small source change further away than if exposed via tc); all it will do is make it harder for common people to opt out of any automatic process we come up with, hopefully allowing better behavior in corner cases. I also realize that I am most likely not wining this battle ;) (as long as I convince you/us to expose limit I am fine).

> 
> P.P.S. If the above seems a bit blunt, it's because I'm somewhat annoyed
> at you arbitrarily reverting a commit without (a) saying anything about
> it and (b) adding another fix for the issue it was supposed to address.
> Was going to start a long series of tests today and ended up having to
> debug this instead. Grump.

	I believe I understand your emotions, I also understand that the initial commit was not as well tested as it should have been… and if this is about voicing raw feelings, I am less than excited about the report I got for triggering a BUG_ON with simple tc operations. My cursory reading of linux-netdev tells me this will not makes us many fans over there (also not with our potential users).

Best Regards
	Sebastian

> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cake-longrtt-fail.pdf
Type: application/pdf
Size: 188560 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/cake/attachments/20151102/b4a77176/attachment-0002.pdf>
-------------- next part --------------
> _______________________________________________
> Cake mailing list
> Cake at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cake



More information about the Cake mailing list