Re: [Cake] low bandwidth default params best effort vs voice latency.

[Andy Furniss <adf.lists@gmail.com>]

Jonathan Morton wrote:
> Okay, I think I’ve worked out what is happening.
>
> At 250KB/s, it takes 6ms to get one 1500-byte bulk packet down the
> pipe.  This is unavoidable, so having a bulk flow competing with your
> game traffic will always increase your peak latency by that much.
>
> With three independent game streams in play, it’s possible for them
> all to transmit simultaneously *and* to coincide with a bulk packet
> having just been sent.  With overheads, it will take a total of 8.5ms
> to get all four packets through.  This corresponds nicely to your
> best-effort results; you’re getting very close to the theoretical
> best performance there.

Yea, the pleasures of low bandwidth - not that I would have called 2mbit
low a few years ago, and 8ms isn't that bad.

Historically, I once had an asymmetric mss clamping setup so up tcp
was smaller than down.

> So Diffserv marking actually can’t improve your performance in this
> particular case.  But it shouldn’t make it worse either.  You’re
> actually seeing a nearly 6ms increase in peak latency, which
> corresponds neatly to an additional bulk packet ending up ahead of
> the game traffic in the queue.
>
> That’s not supposed to happen, but I think I can see how it *can*
> happen with the current Diffserv logic.  It’s a weighted DRR, much
> like what is used between flow queues a little further down - but it
> *doesn’t* have a special bonus for sparse tins.  That’s something I
> clearly need to fix.
>
> To help remind me, please do open an issue on the Github project.

OK, I opened
https://github.com/dtaht/sch_cake/issues/52