How can I go from Asuswrt-Merlin to OpenWrt?

[RMerlin]

It's a big loss to disable CTF. It helps network traffic at reduced CPU load in every way, including LAN <> WLAN and WLAN <> WLAN traffic..

CTF already has to be disabled when using Traditional QoS. That wouldn't change anything there.

You need iptables to handle the traffic classification, and CTF bypasses iptables. There's no way around that.

 

[Chrysalis]

Also CTF doesnt improve anything if you have a powerful enough router and slow enough connection, in my case my overclocked ac68 without CTF can max out my internet speed.

Really in the long term we need to push asus/broadcom away from the now very ancient 2.6 kernel, with its old code and security issues.
Short term this experimental codel support is promising and Ihope we can get it to work.

To put things in perspective linux 2.6 is 2003 code, are broadcom using code they written 13 years ago in today's routers?

 

[jbaugh]

It would probably be much easier to use Tomato. It supports fq_CoDel/CoDel.

Thanks for your reply. Prior to updating to this router my previous two routers ran Tomato firmware. So this is a

You will have to check the OpenWRT documentation for this. Treat Asuswrt-Merlin exactly as if you were still running the stock firmware when it comes to flashing another third party firmware.

Thanks,
This is a useful bit of information if I do make the decision to flash a different firmware.
John

 

[kvic]

CTF provides a 100+ Mbit/s advantage on WLAN throughput. Tested on my RT-AC56U.

Linux 2.6.x was very classical of the old development model. While 2.6.0 was 2003, 2.6.36.4 (the one in AC56/AC68/AC87) was 2011. Don't be faked by the leading digit 2.

Adaptive QoS will get you a very high score in dslreport buffer bloat test (from F to A+ in my case).

 

[jbaugh]

I appreciate all of the responses my inquiry has generated. Unfortunately for me the discussion in this thread tends to be above my technological level.

But I would like to report on my efforts thus far to mitigate bufferbloat. First I updated to the newest version of Asuswrt-Merlin (380_58_0). In "Adaptive QoS" I selected Traditional QoS. I set the "Upload Bandwidth" to a value about 10% lower than my measured upload speed and the "Download Bandwidth" to about 10% less than my measured download speed. I applied these settings and rebooted my router. Testing of up/down speeds and bufferbloat on dslreports.com showed absolutely no difference in values of bandwidth or bufferbloat with QoS on or off. After a couple of hours of changing bandwidth configurations in QoS I made a surprising discovery. I can actually reduce bufferbloat significantly (from "F" to "C" score) by REVERSING the entries for bandwidth in the QoS settings boxes. In other words, I put my measured upload bandwidth minus 10% (10Mb/s) into the box for "Download Bandwidth" and I put my measured download bandwidth minus 10% (125Mb/s) into the box for "Upload Bandwidth". My upload bandwidth is not throttled at all with these settings and I suffer only mild loss of download speed (measured download speed~ 110- 120 Mb/s). But I thought this observation to be interesting.
John

 

[Nullity]

I appreciate all of the responses my inquiry has generated. Unfortunately for me the discussion in this thread tends to be above my technological level.

But I would like to report on my efforts thus far to mitigate bufferbloat. First I updated to the newest version of Asuswrt-Merlin (380_58_0). In "Adaptive QoS" I selected Traditional QoS. I set the "Upload Bandwidth" to a value about 10% lower than my measured upload speed and the "Download Bandwidth" to about 10% less than my measured download speed. I applied these settings and rebooted my router. Testing of up/down speeds and bufferbloat on dslreports.com showed absolutely no difference in values of bandwidth or bufferbloat with QoS on or off. After a couple of hours of changing bandwidth configurations in QoS I made a surprising discovery. I can actually reduce bufferbloat significantly (from "F" to "C" score) by REVERSING the entries for bandwidth in the QoS settings boxes. In other words, I put my measured upload bandwidth minus 10% (10Mb/s) into the box for "Download Bandwidth" and I put my measured download bandwidth minus 10% (125Mb/s) into the box for "Upload Bandwidth". My upload bandwidth is not throttled at all with these settings and I suffer only mild loss of download speed (measured download speed~ 110- 120 Mb/s). But I thought this observation to be interesting.
John

If you want to know more, (in my opinion) the best intro to QoS fundamentals can be found here: http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795

 

[kvic]

If you want to know more, (in my opinion) the best intro to QoS fundamentals can be found here: http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795

Or simply go to Adaptive QoS (the menu on left column). Then QoS (the top Tab). Then Qos Type (the field). Then Adaptive QoS (the radio button).

@jbaugh do you see that radio button named Adaptive QoS?

Select that.

Put Download bandwidth 0.

Put Upload Bandwidth a value between 90% - 95% of your tested bandwidth.

 

[jbaugh]

Or simply go to Adaptive QoS (the menu on left column). Then QoS (the top Tab). Then Qos Type (the field). Then Adaptive QoS (the radio button).

@jbaugh do you see that radio button named Adaptive QoS?

Select that.

Put Download bandwidth 0.

Put Upload Bandwidth a value between 90% - 95% of your tested bandwidth.

Yes, I see the radio button for Adaptive QoS. I have tried setting up QoS with that button selected and with the Traditional QoS button selected.

Repeated testing of bufferbloat on dslreports.com with QoS DISABLED shows a consistent score of "F". When I enable QoS, select Adaptive QoS, and enter "0" into Download Bandwidth and "9" into the Upload Bandwidth box I reproducibly get a "D" score for bufferbloat. So it seems your suggested settings do make a marginal improvement in my situation.

 

[kvic]

Yes, I see the radio button for Adaptive QoS. I have tried setting up QoS with that button selected and with the Traditional QoS button selected.

Repeated testing of bufferbloat on dslreports.com with QoS DISABLED shows a consistent score of "F". When I enable QoS, select Adaptive QoS, and enter "0" into Download Bandwidth and "9" into the Upload Bandwidth box I reproducibly get a "D" score for bufferbloat. So it seems your suggested settings do make a marginal improvement in my situation.

Sad to hear Adaptive QoS failed on you at the moment. I believe it's TrendMicro's arithematic at fault here.

Seems you have 10Mbit/s upload. If so, try putting 8Mbit/s or 7Mbit/s or even 5Mbit/s. Don't worry about losing about half bandwidth (it won't...) See if it gets you a better score..

Note it's only for getting a higher score. I've no idea it actually improves so called buffer bloat...

 

[Chrysalis]

CTF provides a 100+ Mbit/s advantage on WLAN throughput. Tested on my RT-AC56U.

Linux 2.6.x was very classical of the old development model. While 2.6.0 was 2003, 2.6.36.4 (the one in AC56/AC68/AC87) was 2011. Don't be faked by the leading digit 2.

Adaptive QoS will get you a very high score in dslreport buffer bloat test (from F to A+ in my case).

5 years is still a very long time.

 

[sfx2000]

5 years is still a very long time.

The kernel they're using is an LTS kernel, so they can still get upstream patches/fixes.... the clock is ticking however, and at some point, folks will have to move to 3.2 and the attendant pain involved with a merge/update there.

Challenge here is that the API's are always moving - some get added, some get depreciated, and some get massive changes inside that can break other things - there's still a lot of 2.6.*.* out there, and that's not necessarily a bad thing.

 

[buddyp]

5 years is still a very long time.

2.6 went EOL in February of 2016. The last release was 2.6.32. Perhaps this will prod some of the hardware vendors into supporting at least a somewhat modern kernel.

Well, we can hope, can't we?

 

[sfx2000]

2.6 went EOL in February of 2016. The last release was 2.6.32. Perhaps this will prod some of the hardware vendors into supporting at least a somewhat modern kernel.

Well, we can hope, can't we?

Some already are - Linksys, at least on the WRT AC class machines is on 3.10.39 - which is important, as post 3.10, there was a major IOCTL change that broke many older wireless drivers...

Firmware Version: 2.0.7.167471
Firmware Builddate: 2015-06-10 20:28
Product.type: production
Linux: Linux version 3.10.39 (root@build-vm) (gcc version 4.6.4 (Linaro GCC branch-4.6.4. Marvell GCC Dev 201310-2126.3d181f66 64K MAXPAGESIZE ALIGN) ) #1 SMP Wed Jun 10 12:54:48 PDT 2015

 

[sfx2000]

And it looks like Quantenna - which might be holding up things - they're a bit behind, at least on the QTN example I have, which is _not_ an RT-AC87U

This one is an 802.11n 5GHz wireless video bridge device... but it runs native on the ARC that QTN uses for their MAC/Baseband software package - the 11ac version might be a bit newer...

Linux version 2.6.30 (root@build-vm) (gcc version 4.2.1 (ARC_2.3)) #1 Tue Aug 26 10:47:37 PDT 2014

 

[kvic]

5 years is still a very long time.

Considering RT-AC68U is 3 years old in consumer time, 4 years old in manufacturer's time and 5 or more years old in chip vendor's time.

It's about right..

Nevertheless, Broadcom is extremely lazy in taking advantage of a LTS kernel. They seldom ported patches from open source into their contaminated kernel.

Evidence at point: little difference between SDK6 and SDK7.14 from kernel perspective. These two SKDs are two years apart at least.

 

[kvic]

Some already are - Linksys, at least on the WRT AC class machines is on 3.10.39 - which is important, as post 3.10, there was a major IOCTL change that broke many older wireless drivers...

Ubiquiti's EdgeOS is also based on 3.x because SDKs from Cavium and MediaTek are as I read.