You mention in the above post the experimental qos stuff and the regarding branch. So i checked it out and see roughly whats going on. But can you maybe explain more in detail what that code should implement.
I can see smt about IFB modules so i think advanced traffic shaper modules should be activated. I saw the fq_codel implementation( which is one of the greatest improvements to see IMO). Can u clarify a bit in detail from your side whats the branch for? Whats the target or better to say the targeted benefit? Also is it implemented by Asus or by you ( seems like your work and the patches from Kyle Sanderson and the backport patch of kernel.org)?
Development is currently stalled on the qos code due to an SDK bug that affects QoS in general in Asuswrt. I have to wait for Asus to resolve it first. But what you see in the qos branch is entirely my work, not Asus's.
This is very experimental at this stage, and there's no guarantee it will eventually end up in the firmware. I've done a few of these "failed" experiments over the years, like the switch to jpeg-turbo (random crashes I could never sort out) or the toolchain update which I eventually dropped.
(I don't like the word "failed" here, because I usually still do learn something out of it. More like "scrapped" I guess.)
The current plan,
if everything works out to my satisfaction, is:
1) Allow Asus's Traditional QoS method to support using both the current sfq and the more advanced fq_codel queue management
2) Implement a fourth QoS method that will be based on OpenWRT's SQM. I got both the simple.qos and simplest.qos SQM scripts mostly running (aside from a few glitches I still need to track down). I haven't decided yet any of the details, it will depend on the results of my tests with both scripts.
Simplest is just one simple queue, while
simple is currently based on DSCP plus 3 queues - I could possibly extend that to 6 queues and interface it with the 6 levels supported by Traditional QoS. This is what IFB is used for. It allows the router to control both inbound and outbound traffic, while the traditional implementation is limited to outbound. It's an alternative to the IMQ scheduler used in Tomato's MIPS builds. IMQ is not possible on ARM because it involves making changes to the skbuf kernel structure, which totally breaks the closed-source components such as the Wireless driver. IFB doesn't touch that structure, so it should be clear for playing nice with those closed source bits.
I wish I could also play with the traffic classification done by AdaptiveQoS, but it uses the closed source qosd binary to setup the Linux traffic classifier, so it's outside of my control (unless I decided to put a wrapper around tc, and intercept its "tc" calls, but that's currently not in the plans.) A shame, might have been cool leveraging the DPI engine to classify traffic, and then use a more advanced queue mechanism than sfq to handle it.
The SQM stuff isn't on Github yet, as I'm still manually playing with tweaked versions of the OpenWRT scripts rather than any final firmware-level implementation. They currently reside within my router's JFFS partition.
But this is all mostly stalled until Asus/BCM can resolve the SDK-related QoS issues. Once that's resolved, tests will have to convince me that there IS any actual advantage to it. I know the bufferbloat complainers insist that fq_codel is the silver bullet to it - something I'm still skeptical about, as I've seen just as much improvement from even sfq. The fq_codel implementations have the same basic recommendation that I've been making for a long time with Adaptive QoS (which is to set upstream/downstream slightly below your max speed). I suspect that this alone has a much bigger impact on latency than the queue mechanism itself.
. Maybe i am to tired today, that i wasnt able to get this easy and self explaining logic on my own. Whatever 
