What's new

[Beta] Asuswrt-Merlin 380.67 Beta is now available

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Status
Not open for further replies.
I thought fq_codel required a much newer kernel than what Asus is using? Anyway good news and great work on that, I've been using it on an OpenWrt router previously and now on the ER-X and it's excellent for shaping slow upstream. Devices doing uploads for online backup, Facebook etc no longer cause high latency.

Kyle Sanderson backported fq_codel to 2.6.36 last year for Tomato. It will still lack BQL support since that one cannot be backported to older kernels (and also requires driver-level support), however it will still offer some benefits.

I already added fq_codel support last year to Traditional QoS. Today's beta includes a patching system that allows fq_codel to also be used with Trend Micro's Adaptive QoS, by intercepting calls it makes to configure the traffic classifier, replacing "sfq" with "fq_codel" where appropriate before passing the command to the kernel.
 
I'm one of those that have been testing the QoS changes on my RT-AC68U and my observation is that it only works best when you have the manual bandwidth settings right - I'm on about 10% below my actual speeds, but it still seems to work well at peak times when my connection is around 10% slower. It doesn't help with Automatic bandwidth settings.

For those interested, here are some of my test results taken this evening when I expect my ISP to be at the most congested. You should scroll down to the latency results to really see the benefits I've had:

Test without any QoS http://www.dslreports.com/speedtest/18059409
Test using sfq http://www.dslreports.com/speedtest/18059499
Test using codel http://www.dslreports.com/speedtest/18059595
Test using fq_codel http://www.dslreports.com/speedtest/18059671
Test using fq_codel and the overhead set to 27 (VDSL / PPPoE) http://www.dslreports.com/speedtest/18059829

Many thanks to @RMerlin for all his hard work
 
380.67 Beta 3 is now available, with a short, but important changelog.

Code:
04eec3c Bumped revision to beta 3
2e39e39 ctf: revert BCM6.37's ctf to pre-7743 version, as an attempt to fix broken PPPoE acceleration
23f8e63 Merge with GPL 7743 binary blobs for RT-AC87U; updated kludges
d992e24 qos: implement overhead support for AdaptiveQoS; re-design overhead configuration on the webui; add non-atm based overhead support
927d443 rc: duplicate ssl_enable keyword when enabling FTP TLS
51256fc Add space before WAN IP
b99dc76 qos: implement wedge to iproute2 to insert (fq_)codel support in Adaptive QoS

Beta 3 adds support for fq_codel to Adaptive QoS. This is done by intercepting calls made by the Trend Micro component to the Linux traffic classifier, and replacing sfq settings on-the-fly with fq_codel settings. The same technique is also used to implement support for configurable overhead values for Adaptive QoS.

The overhead configuration was also overhauled for both Traditional and Adaptive QoS. Now, you can enable or disable ATM support (previously, anything >0 was automatically set to ATM). The value can also be manually entered, or chosen from a list of preset configurations. I'm unsure of the actual impact of this parameter, as the documentation on it is rather sparse, even conflicting at time. My best recommendation is that you experiment with them. If in doubt, keep things at the default value (0, with ATM disabled).

The screenshot I posted earlier show the latency of a ping being sent every second to www.google.ca while running a speedtest from speedtest.net. As you can see, fq_codel does help in keeping average latency lower (aside from a few occasional spikes, yet those aren't as high).

My thanks to the group of volunteers that confirmed that the patch system was working properly. Do note that fq_codel is not a magic bullet. It won't make your connection go faster, and it might only help in some specific scenarios. You might also need to experiment a bit with the overhead value. But in general, it should be an improvement in terms of latency when having multiple concurrent streams.

Finally, in an attempt to resolve the lack of NAT acceleration for PPPoE for some models, the NAT acceleration component was reverted to an older version. Please confirm whether this makes any difference if you have an AC56/AC68/AC87 and a fast PPPoE connection that had performance issues with beta 1 and 2.

Dear Eric,

I confirm that the NAT acceleration for PPPoE works properly now. Gone are the bugs from 380.67 beta 1 and beta2!

Thank you very, very much for your beautiful work!
Speed_test_Fiberlink_500_Romania_RCS-RDS.png
 
aPAyoTx.png


FQ_Codel + Bandwidth set to Manual
18067255.png


SFQ + Bandwidth set to Manual
18067471.png


SFQ + Bandwidth set to Automatic
18067615.png
 
For best results, you'll want to manually set your bandwidth, slightly below their maximum. Automatic doesn't work too well at managing congestion. For my ISP that gives me 33/11 Mbps (yes, those are the actual numbers, they started over provisioning by 10% last year, probably just to get better results in speed test reviews even tho they advertise it as 30/10), I use 31/10.
 
For best results, you'll want to manually set your bandwidth, slightly below their maximum. Automatic doesn't work too well at managing congestion. For my ISP that gives me 33/11 Mbps (yes, those are the actual numbers, they started over provisioning by 10% last year, probably just to get better results in speed test reviews even tho they advertise it as 30/10), I use 31/10.

I can't find the conversion table for Canadian to US to see what smoking fast dl/ul you're getting?
 
Beta3 test on 87U:
1) QoS on
2) turn QoS off and apply (now hardware NAT FA is not enabled, can not turn on - pic1 - with beta2 he was enable)
3) turn QoS on and now i can not configurate this (see pic2)
 

Attachments

  • pic1.PNG
    pic1.PNG
    5.9 KB · Views: 459
  • pic2.PNG
    pic2.PNG
    84.9 KB · Views: 691
Beta3 test on 87U:
1) QoS on
2) turn QoS off and apply (now hardware NAT FA is not enabled, can not turn on - pic1 - with beta2 he was enable)
3) turn QoS on and now i can not configurate this (see pic2)

Well Merlin knows already, But I flashed the latest beta on a AC3100 I have, and when going to the QoS page. I have no option to select what QoS system I want to use. So in return QoS isn't usable as it will give you the pop up box saying no QoS has been selected to use. So a little bug, I'm sure Merlin might be able to find, and maybe up another beta build not to far off to fix this problem.
 
Upgraded from Beta 1 to Beta 2 on my AC66U.

Personally generated SSL certificate and key were overwritten by router ones instead of reused, while "Generate a new certificate" is set to "No".
Personally generated SSL certificate and key are re-used on Beta 3 :)
 
Not sure why the Adaptive QoS settings would disappear on these two models. At least I have the RT-AC87U so that one I'll be able to test over the weekend. It must be model-specific, as I didn't any similar report either during the closed beta test.
 
Asuswrt-Merlin 380.67 Beta 2 is now available for all supported model. This update merges with newer Asus GPL, improves SSL certificate support for the webui, and updates various components.

Changes in Beta 3:
Code:
04eec3c Bumped revision to beta 3
2e39e39 ctf: revert BCM6.37's ctf to pre-7743 version, as an attempt to fix broken PPPoE acceleration
23f8e63 Merge with GPL 7743 binary blobs for RT-AC87U; updated kludges
d992e24 qos: implement overhead support for AdaptiveQoS; re-design overhead configuration on the webui; add non-atm based overhead support
927d443 rc: duplicate ssl_enable keyword when enabling FTP TLS
51256fc Add space before WAN IP
b99dc76 qos: implement wedge to iproute2 to insert (fq_)codel support in Adaptive QoS

Still having a problem with OpenVPN. I have my 2nd openvpn server setup with "Direct clients to redirect Internet traffic" and when I connect to it via my laptop internet stops working. I have it setup with a TAP interface and UDP Protocol using L4Z compression.
 
I´m seeing you all talking about QOS so I decided to give a try but got no success.

After changing the toggle I got the queue options but no more.

vg0tax.png
 
@Adamm @RMerlin

Update.....now for the bad news after some more testing. I think I've recreated the tomato reboot problem. Issuing an 'ipset flush' crashes the kernel :(

Ahh thats a bummer, the comment feature is super handy. Thanks for looking into it atleast
 
Could it be a browser caching issue as it's working fine for me?
upload_2017-7-7_22-56-13.png
 
For best results, you'll want to manually set your bandwidth, slightly below their maximum. Automatic doesn't work too well at managing congestion. For my ISP that gives me 33/11 Mbps (yes, those are the actual numbers, they started over provisioning by 10% last year, probably just to get better results in speed test reviews even tho they advertise it as 30/10), I use 31/10.

Strange thing for me I can only achieve A+ for all three by setting the QOS upload higher than my VDSL connection. I'm on a 100/20 VDSL package and the sweetspot in QOS is 98/30 with that I can constantly achieve A+ for overall, buffer bloat & quality
http://www.dslreports.com/speedtest

Just spent the last hour trying all different QOS combinationa and this is the only one where I get A+ across the board

Model AC88u
 
Last edited:
Beta3 on 87U. It is probably my imagination, but the WebUI seems a lot faster. Not seeing any issues in the last few hours.
 
Status
Not open for further replies.

Latest threads

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top