[Cake] 5ms target hurting tcp throughput tweakable?
moeller0 at gmx.de
Mon Feb 27 13:13:19 EST 2017
> On Feb 27, 2017, at 19:02, Andy Furniss <adf.lists at gmail.com> wrote:
> Sebastian Moeller wrote:
>> Looking at tc-adv, I would recommend to use “rtt 50” (maybe it is
>> “rtt 50ms”) which allows to directly explicitly request a new
>> “interval” (which IIRC is corresponding to the time you allow for
>> the TCP control loop to react to cake’s ecn-marking/dropping)
>> “target’ will be calculated as 5% of the explicit interval, in
>> accordance with the rationale in the codel RFC.
> 50 is certainly better than 10, but still seems to hurt single a bit
> even on a close server.
Oopps, what I meant to convey is that there is the numeric option “rtt NNN” that allows to select the exact RTT/interval you believe to be valid. I picked 50 just because I wanted to give a concrete example, not because I believe 50 to be correct for your experiments...
> On more distant servers maybe even more - I am getting results that are
> too variable to tell properly at the current time (of day).
> Almost OK, but with 100ms this test usually shows x1 and x6 the same.
Interesting. My mental image is that interval defines the time you give both involved TCPs to get their act together before escalating cake’s/codel’s signaling. The theory as far as I understand it says that the RTT is the lower bound for the time required, so I am not totally amazed that relaxing that interval a bit increases bandwidth utilisation at a vert moderate latency cost (if any). The art is to figure out how to pick the interval (and I believe the codel paper showed, that at least for codel the exact number is not so important but the ballpark/ order of magnitude should match).
> Of course as we all know ingress shaping is a different beast anyway and
> would deserve its own thread.
The cool thing is that ingress shaping with all its “approximateness” (is that a word) works as well as it does ;)
More information about the Cake