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
_______________________________________________
Cake mailing list
[email protected]
https://lists.bufferbloat.net/listinfo/cake
