[Cake] Long-RTT broken again
moeller0 at gmx.de
Tue Nov 3 14:24:50 EST 2015
On Nov 3, 2015, at 20:17 , Jonathan Morton <chromatix99 at gmail.com> wrote:
> Conceptually, I think limiting actual memory usage is the right thing to do.
I agree ;) but I am coming at this from the avoid OOM direction anyway; I believe Toke’s point for people coming from the BDP angle is equally valid (if less important to me personally).
> Ideally, the allocations would turn out closer to the actual packet sizes, but by watching the allocated size, we will automagically take advantage of improvements in this area - which must happen elsewhere in the kernel.
But this is acknowledging there is a discrepancy and the punting, turning it into someone else’s problem, no?
> Limiting total on-wire packet bytes is nice from a theoretical point of view, but we don't live in a theoretical world. The performance discrepancy shouldn't be as big as it is.
But this is about honoring BDP calculations for worst case buffering scenarios where the sender dumps all packets for a whole transfer period in one instantaneous burst (well almost); this seems well documented in the literature and hence might be something users might actually want to do...
> Limiting packet count is wrong and awful and we shouldn't do that, even if everyone else does. The fact that counting allocated bytes behaves the same way at the moment is unfortunate.
Why? The fact that they are correlated also allows to limit by allocated size, since the correlation is directionally insensitive, so to speak, we can always argue that the packet fans just need a proportionality constant and be done with ;). I guess this needs a clear name than simply limit to avoid confusing people who already know other qdiscs and their behavior.
> - Jonathan Morton
More information about the Cake