[Bloat] some notes on the archer c7v2's suitability for make-wifi-fast

[Jonathan Morton]

> On 27 Mar, 2015, at 04:10, Dave Taht <dave.taht at 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