> On 27 Mar, 2015, at 04:10, Dave Taht <dave.t...@gmail.com> wrote:
>
> I think cake can be improved quite a bit more and we really need to do some
> profiling to find other bottlenecks.
I’ve got far enough with the improved Diffserv logic to see that, at the very
least, cake3 will need to do less work to figure out that it’s throttled.
That’s because the hard shaper is now global rather than class-local, so I can
hoist it before any of the class-specific work. If it gets past that, it can
be confident that it’s got a packet to deliver.
This is important, because cake_dequeue() often gets called twice per packet -
once just after cake_enqueue(), when it might be too soon to transmit, and
again when the watchdog timer fires to denote the correct transmit time.
The class selection loop is also smaller and simpler (fewer edge cases to cope
with), and I worked out a shortcut to put in further down, so it doesn’t have
to re-run the class selection if a flow happens to be in deficit. That’s
another likely win.
So those might turn out to be significant efficiency improvements, altogether.
Of course, if the real overhead is elsewhere, the improvements in throughput
might turn out to be small, but for the moment I’m actually focusing on
behaviour rather than throughput.
On that note, I’ve added a four-class Diffserv mapping alongside the existing
eight-class one. This new mapping is:
Latency Sensitive (CS7, CS6, EF, VA, CS5, CS4)
Streaming Media (AF4x, AF3x, CS3, AF2x, TOS4, CS2, TOS1)
Best Effort (CS0, AF1x, TOS2, and all not otherwise
specified)
Background Traffic (CS1)
> So I saw fairly long delays (7ms or more) when running at these speeds
> through the router.
TBH, it’s a sign of how far we’ve come that we now consider 7ms to be painful.
:-)
- Jonathan Morton
_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
