What's new

[Beta] Asuswrt-Merlin 384.8 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 guess that there is no option for cake

No, as Cake is not supported by 4.1.51, plus it's not directly compatible with sfq/codel/fq_codel. Using Cake would require completely rewriting the tc configuration, which only Trend Micro/Asus can do, unless you were to completely disable Adaptive QoS, and configure everything manually yourself.

As the RT-AC56U is now dropped I’ll have to upgrade to another router. Am I amble to put it back on ASUS firmware to be used in AP mode.

Why go with stock firmware? The reason for me dropping it is specifically because Asus is also dropping it. You won't be getting any further updates by moving to stock (or if Asus did, then I would be able to resume support for it as well).
 
If you have that kind of speed from your isp then QOS really has no need to be run.;):)

That's why I tend to not rely on QoS to begin with. But QoS can still be beneficial even with high bandwidth if you like me are running your own Plex local Plex-server and torrent-server that can easily eat your entire upload and download resulting in other services getting too little bandwidth. Try having 4K HDR Remux streaming from your local Plex server to a external clients, that's 50 mbps++ for a single stream. It's a easy way for you to ensure that essential services will always get the bandwidth they require.

Luckily my connection will be 1/1 gbps as soon as my ISP has replaced some of their equipment to fully support it. Will just be a few more months, and hopefully it will come with full support for native IPv6 which will mean I can start using other equipment altogether as I would not longer need to rely on UPNP and Open NAT filtration / Full-Cone-NAT for all my gaming to work as intended.
 
It's pretty much the same level of compression, just that uses more efficient structures, reducing overhead slightly. It's a poorly documented feature in OpenVPN 2.4.

On Cortex-A 32-bit (ARMv7a), it's a wash, actually lzo can perform better than lz4 in some cases - on x86/amd64, lz4 has performance advantages - even with things like compcache (zram)...

Personally I recommend not using compression with OpenVPN anyway, as most network traffic doesn't compress too well these days (since it's already encrypted).

Yep, agreed - it's creating more work for the core/cores, and can add latency by doing work that really isn't needed...
 
Why go with stock firmware? The reason for me dropping it is specifically because Asus is also dropping it. You won't be getting any further updates by moving to stock (or if Asus did, then I would be able to resume support for it as well).

You’re right as it’s EOL. Wasn’t thinking clearly.
 
So clearly there is something that limits the WAN throughput to around 300 mbps when you do not have the "Runner" acceleration activated.

Might be the queue lengths - playing around with fq_codel on pfSense, I had to increase the queue lengths from the default (1000) to 4000... and then bandwidth started working correctly, reflecting my WAN up/down - I'm highly asymmetric in bandwidth - 150 down/10 up - once 'tuned' get good performance across the board, and A+ for bufferbloat and connection Quality on the dslreports speedtest...

Not sure how to get "under the hood" to tune the QoS queues and shapers with AsusWRT-RMerlin...

Screen Shot 2018-11-17 at 1.31.54 PM.png
 
I was looking at the logs for beta1 and saw these lines. I do not know what they mean. Except that when I logged in the webui, then clicked on the System Log button, it dumped me back to the login page. Is this saying that?

Nov 17 14:32:49 kernel: httpd[800]: unhandled level 3 translation fault (11) at 0x002a808c, esr 0x92000007
Nov 17 14:32:49 kernel: pgd = ffffffc014c6d000
Nov 17 14:32:49 kernel: [002a808c] *pgd=000000001538e003, *pud=000000001538e003, *pmd=0000000013915003, *pte=0000000000000000
Nov 17 14:32:49 kernel: CPU: 0 PID: 800 Comm: httpd Tainted: P O 4.1.27 #2
Nov 17 14:32:49 kernel: Hardware name: Broadcom-v8A (DT)
Nov 17 14:32:49 kernel: task: ffffffc019394b40 ti: ffffffc014ca4000 task.ti: ffffffc014ca4000
Nov 17 14:32:49 kernel: PC is at 0xf71f2aa0
Nov 17 14:32:49 kernel: LR is at 0x26cd4
Nov 17 14:32:49 kernel: pc : [<00000000f71f2aa0>] lr : [<0000000000026cd4>] pstate: 20000010
Nov 17 14:32:49 kernel: sp : 00000000ff87c1d8
Nov 17 14:32:49 kernel: x12: 000000000008c71c
Nov 17 14:32:49 kernel: x11: 00000000000791b1 x10: 0000000000000001
Nov 17 14:32:49 kernel: x9 : 00000000001534c8 x8 : 0000000000000000
Nov 17 14:32:49 kernel: x7 : 0000000000137978 x6 : 0000000000143ba0
Nov 17 14:32:49 kernel: x5 : 00000000002a8080 x4 : 00000000002a8080
Nov 17 14:32:49 kernel: x3 : 00000000ffffffff x2 : 00000000f709e7a8
Nov 17 14:32:49 kernel: x1 : 0000000000000000 x0 : 00000000002a8080
Nov 17 14:32:54 watchdog: restart httpd
Nov 17 14:32:54 rc_service: watchdog 808:notify_rc stop_httpd
Nov 17 14:32:54 rc_service: watchdog 808:notify_rc start_httpd
Nov 17 14:32:54 RT-AC86U: start httpd:80
 
unhandled level 3 translation fault (11) at 0x002a808c, esr 0x92000007

It's a page fault, the kernel's memory manager is looking for data at an address that doesn't exist so the kernel kills the calling task, in this case, it's httpd, hence the watchdog bounces one back to the login page...

Just for levity's sake...

Code:
/* 
task died - kick the dog, yipe yipe yipe... 
*/

for devs - take a look at arch/arm64/mm/fault.c in the kernel code...
 
The cost is 800 NOK / 95 USD per month, but it's being fully paid by my workplace.

Nice... I pay more than that for 150/10 - and lucky to get that...

The broadband marketplace in the US is not very competitive, and we're not seeing the levels of investment that would make things better for everyone... big Telco/CableCo seem more interested in mergers/acquisitions and returning shareholder value rather than improving service to the home...
 
I get random reboots also now and again, latest has this in log:

Code:
May  5 07:05:05 kernel: _ Reboot message ... _______________________________________________________
May  5 07:05:05 kernel: Unable to handle kernel paging request at virtual address c8ffffffc01743d4pgd = ffffffc015378000[c8ffffffc01743d4] *pgd=0000000000000000, *pud=0000000000000000Internal error: Oops: 96000004 [#1] PREEMPT SMPModules linked in: tun init_addr(          (null) -           (null)), core_addr(ffffffbffc31a000 - ffffffbffc31d4ec) ip_set_list_set init_addr(          (null) -           (null)), core_addr(ffffffbffc314000 - ffffffbffc315600) ip_set_hash_ip init_addr(          (null) -    
May  5 07:05:05 kernel:  (null)), core_addr(ffffffbffc2c3000 - ffffffbffc2e4b08) tdts(PO) init_addr(          (null) -           (null)), core_addr(ffffffbffcac5000 - ffffffbffcb01360) nf_nat_sip init_addr(          (null) -           (null)), core_addr(ffffffbffcabe000 - ffffffbffcabf980) nf_conntrack_sip init_addr(          (null) -           (null)), core_addr(ffffffbffcab3000 - ffffffbffcab5e80) nf_nat_h323 init_addr(          (null) -           (null)), core_addr(ffffffbffcaad000 - ffffffbffcaae0d
May  5 07:05:05 kernel: ffbffca86c30) sr_mod init_addr(          (null) -           (null)), core_addr(ffffffbffca6e000 - ffffffbffca70318) cdrom init_addr(          (null) -           (null)), core_addr(ffffffbffca61000 - ffffffbffca65d00) usblp init_addr(          (null) -           (null)), core_addr(ffffffbffca59000 - ffffffbffca5afd8) thfsplus(O) init_addr(
May  5 07:05:05 kernel: usb 3-1: new high-speed USB device number 2 using ehci-platform
May  5 07:05:06 kernel:           (null) -           (null)), core_addr(ffffffbffca37000 - ffffffbffca43fac) tntfs(PO) init_addr(          (null) -           (null)), core_addr(ffffffbffc9aa000 - ffffffbffc9f68b0) tfat(PO) init_addr(          (null) -           (null)), core_addr(ffffffbffc954000 - ffffffbffc983f78) usb_storage init_addr(          (null) -           (null)), core_addr(ffffffbffc93d000 - ffffffbffc9409c8) sg init_addr(          (null) -           (n
May  5 07:05:06 kernel: usb 2-2: new SuperSpeed USB device number 2 using xhci-hcd
May  5 07:05:06 kernel: ull)), core_addr(ffffffbffc930000 - ffffffbffc934448) sd_mod init_addr(          (null) -           (null)), core_addr(ffffffbffc922000 - ffffffbffc926b78) scsi_mod init_addr(          (null) -           (null)), core_addr(ffffffbffc8e4000 - ffffffbffc8f4a58) cdc_mbim init_addr(          (null) -           (null)), core_addr(ffffffbffc8df000 - ffffffbffc8dfb50) qmi_wwan init_addr(          (null) -           (null)), core_addr(ffffffbffc8d4000 - ffffffbffc8d4728) huawei_cdc_ncm
May  5 07:05:06 kernel:         (null) -           (null)), core_addr(ffffffbffc8ab000 - ffffffbffc8ad780) asix init_addr(          (null) -           (null)), core_addr(ffffffbffc8a0000 - ffffffbffc8a2898) libphy init_addr(          (null) -           (null)), core_addr(ffffffbffc892000 - ffffffbffc895a60) cdc_acm init_addr(          (null) -           (null)), core_addr(ffffffbffc887000 - ffffffbffc889628) usbnet init_addr(          (null) -           (null)), core_addr(ffffffbffc87b000 - ffffffbffc8
May  5 07:05:06 kernel: init_addr(          (null) -           (null)), core_addr(ffffffbffc84b000 - ffffffbffc8529a8) xhci_plat_hcd init_addr(          (null) -           (null)), core_addr(ffffffbffc846000 - ffffffbffc846538) xhci_hcd init_addr(          (null) -           (null)), core_addr(ffffffbffc824000 - ffffffbffc8339c0) usbcore init_addr(          (null) -           (null)), core_addr(ffffffbffc7e7000 - ffffffbffc7fece0) usb_common init_addr(          (null) -           (null)), core_addr(fff
May  5 07:05:06 kernel: rdpa_cmd init_addr(          (null) -           (null)), core_addr(ffffffbffc59d000 - ffffffbffc5a5750) bcm_thermal init_addr(          (null) -           (null)), core_addr(ffffffbffc597000 - ffffffbffc597818) bcmspu init_addr(          (null) -           (null)), core_addr(ffffffbffc57f000 - ffffffbffc586910) bcmpdc init_addr(          (null) -           (null)), core_addr(ffffffbffc578000 - ffffffbffc579530) pwrmngtd(P) init_addr(          (null) -           (null)), core_add
May  5 07:05:06 kernel:  - ffffffbffc3813b8) pktflow(P) init_addr(          (null) -           (null)), core_addr(ffffffbffc33a000 - ffffffbffc34da6c) chipinfo(P) init_addr(          (null) -           (null)), core_addr(ffffffbffc336000 - ffffffbffc336134) rdpa_mw init_addr(          (null) -           (null)), core_addr(ffffffbffc32a000 - ffffffbffc32da28) rdpa(P) init_addr(          (null) -           (null)), core_addr(ffffffbffc17f000 - ffffffbffc1e03a0) rdpa_gpl_ext init_addr(          (null) -
May  5 07:05:06 kernel: Tainted: P           O    4.1.27 #2Hardware name: Broadcom-v8A (DT)task: ffffffc0193340c0 ti: ffffffc017b88000 task.ti: ffffffc017b88000PC is at bcmfc_br_fdbdev_get+0xd0/0x118LR is at bcmfc_br_fdbdev_get+0x20/0x118pc : [<ffffffc0004eb5a0>] lr : [<ffffffc0004eb4f0>] pstate: 20000145sp : ffffffc017b8b430x29: ffffffc017b8b430 x28: ffffffc004f52e40 x27: ffffffc01722b800 x26: ffffffc017439068 x25: 0000000000000000 x24: ffffffc0006e0b10 x23: ffffffc0006e0b20 x22: ffffffc017439000 x21:
May  5 07:05:06 kernel: ____________________________________________________________________________
 
I get random reboots also now and again, latest has this in log:

Code:
May  5 07:05:05 kernel: _ Reboot message ... _______________________________________________________
May  5 07:05:05 kernel: Unable to handle kernel paging request at virtual address c8ffffffc01743d4pgd = ffffffc015378000[c8ffffffc01743d4] *pgd=0000000000000000, *pud=0000000000000000Internal error: Oops: 96000004 [#1] PREEMPT SMPModules linked in: tun init_addr(          (null) -           (null)), core_addr(ffffffbffc31a000 - ffffffbffc31d4ec) ip_set_list_set init_addr(          (null) -           (null)), core_addr(ffffffbffc314000 - ffffffbffc315600) ip_set_hash_ip init_addr(          (null) -   
May  5 07:05:05 kernel:  (null)), core_addr(ffffffbffc2c3000 - ffffffbffc2e4b08) tdts(PO) init_addr(          (null) -           (null)), core_addr(ffffffbffcac5000 - ffffffbffcb01360) nf_nat_sip init_addr(          (null) -           (null)), core_addr(ffffffbffcabe000 - ffffffbffcabf980) nf_conntrack_sip init_addr(          (null) -           (null)), core_addr(ffffffbffcab3000 - ffffffbffcab5e80) nf_nat_h323 init_addr(          (null) -           (null)), core_addr(ffffffbffcaad000 - ffffffbffcaae0d
May  5 07:05:05 kernel: ffbffca86c30) sr_mod init_addr(          (null) -           (null)), core_addr(ffffffbffca6e000 - ffffffbffca70318) cdrom init_addr(          (null) -           (null)), core_addr(ffffffbffca61000 - ffffffbffca65d00) usblp init_addr(          (null) -           (null)), core_addr(ffffffbffca59000 - ffffffbffca5afd8) thfsplus(O) init_addr(
May  5 07:05:05 kernel: usb 3-1: new high-speed USB device number 2 using ehci-platform
May  5 07:05:06 kernel:           (null) -           (null)), core_addr(ffffffbffca37000 - ffffffbffca43fac) tntfs(PO) init_addr(          (null) -           (null)), core_addr(ffffffbffc9aa000 - ffffffbffc9f68b0) tfat(PO) init_addr(          (null) -           (null)), core_addr(ffffffbffc954000 - ffffffbffc983f78) usb_storage init_addr(          (null) -           (null)), core_addr(ffffffbffc93d000 - ffffffbffc9409c8) sg init_addr(          (null) -           (n
May  5 07:05:06 kernel: usb 2-2: new SuperSpeed USB device number 2 using xhci-hcd
May  5 07:05:06 kernel: ull)), core_addr(ffffffbffc930000 - ffffffbffc934448) sd_mod init_addr(          (null) -           (null)), core_addr(ffffffbffc922000 - ffffffbffc926b78) scsi_mod init_addr(          (null) -           (null)), core_addr(ffffffbffc8e4000 - ffffffbffc8f4a58) cdc_mbim init_addr(          (null) -           (null)), core_addr(ffffffbffc8df000 - ffffffbffc8dfb50) qmi_wwan init_addr(          (null) -           (null)), core_addr(ffffffbffc8d4000 - ffffffbffc8d4728) huawei_cdc_ncm
May  5 07:05:06 kernel:         (null) -           (null)), core_addr(ffffffbffc8ab000 - ffffffbffc8ad780) asix init_addr(          (null) -           (null)), core_addr(ffffffbffc8a0000 - ffffffbffc8a2898) libphy init_addr(          (null) -           (null)), core_addr(ffffffbffc892000 - ffffffbffc895a60) cdc_acm init_addr(          (null) -           (null)), core_addr(ffffffbffc887000 - ffffffbffc889628) usbnet init_addr(          (null) -           (null)), core_addr(ffffffbffc87b000 - ffffffbffc8
May  5 07:05:06 kernel: init_addr(          (null) -           (null)), core_addr(ffffffbffc84b000 - ffffffbffc8529a8) xhci_plat_hcd init_addr(          (null) -           (null)), core_addr(ffffffbffc846000 - ffffffbffc846538) xhci_hcd init_addr(          (null) -           (null)), core_addr(ffffffbffc824000 - ffffffbffc8339c0) usbcore init_addr(          (null) -           (null)), core_addr(ffffffbffc7e7000 - ffffffbffc7fece0) usb_common init_addr(          (null) -           (null)), core_addr(fff
May  5 07:05:06 kernel: rdpa_cmd init_addr(          (null) -           (null)), core_addr(ffffffbffc59d000 - ffffffbffc5a5750) bcm_thermal init_addr(          (null) -           (null)), core_addr(ffffffbffc597000 - ffffffbffc597818) bcmspu init_addr(          (null) -           (null)), core_addr(ffffffbffc57f000 - ffffffbffc586910) bcmpdc init_addr(          (null) -           (null)), core_addr(ffffffbffc578000 - ffffffbffc579530) pwrmngtd(P) init_addr(          (null) -           (null)), core_add
May  5 07:05:06 kernel:  - ffffffbffc3813b8) pktflow(P) init_addr(          (null) -           (null)), core_addr(ffffffbffc33a000 - ffffffbffc34da6c) chipinfo(P) init_addr(          (null) -           (null)), core_addr(ffffffbffc336000 - ffffffbffc336134) rdpa_mw init_addr(          (null) -           (null)), core_addr(ffffffbffc32a000 - ffffffbffc32da28) rdpa(P) init_addr(          (null) -           (null)), core_addr(ffffffbffc17f000 - ffffffbffc1e03a0) rdpa_gpl_ext init_addr(          (null) -
May  5 07:05:06 kernel: Tainted: P           O    4.1.27 #2Hardware name: Broadcom-v8A (DT)task: ffffffc0193340c0 ti: ffffffc017b88000 task.ti: ffffffc017b88000PC is at bcmfc_br_fdbdev_get+0xd0/0x118LR is at bcmfc_br_fdbdev_get+0x20/0x118pc : [<ffffffc0004eb5a0>] lr : [<ffffffc0004eb4f0>] pstate: 20000145sp : ffffffc017b8b430x29: ffffffc017b8b430 x28: ffffffc004f52e40 x27: ffffffc01722b800 x26: ffffffc017439068 x25: 0000000000000000 x24: ffffffc0006e0b10 x23: ffffffc0006e0b20 x22: ffffffc017439000 x21:
May  5 07:05:06 kernel: ____________________________________________________________________________

Time for a clean install. I don't have that issue on my 86U.
 
I was looking at the logs for beta1 and saw these lines. I do not know what they mean. Except that when I logged in the webui, then clicked on the System Log button, it dumped me back to the login page. Is this saying that?

Nov 17 14:32:49 kernel: httpd[800]: unhandled level 3 translation fault (11) at 0x002a808c, esr 0x92000007
Nov 17 14:32:49 kernel: pgd = ffffffc014c6d000
Nov 17 14:32:49 kernel: [002a808c] *pgd=000000001538e003, *pud=000000001538e003, *pmd=0000000013915003, *pte=0000000000000000
Nov 17 14:32:49 kernel: CPU: 0 PID: 800 Comm: httpd Tainted: P O 4.1.27 #2
Nov 17 14:32:49 kernel: Hardware name: Broadcom-v8A (DT)
Nov 17 14:32:49 kernel: task: ffffffc019394b40 ti: ffffffc014ca4000 task.ti: ffffffc014ca4000
Nov 17 14:32:49 kernel: PC is at 0xf71f2aa0
Nov 17 14:32:49 kernel: LR is at 0x26cd4
Nov 17 14:32:49 kernel: pc : [<00000000f71f2aa0>] lr : [<0000000000026cd4>] pstate: 20000010
Nov 17 14:32:49 kernel: sp : 00000000ff87c1d8
Nov 17 14:32:49 kernel: x12: 000000000008c71c
Nov 17 14:32:49 kernel: x11: 00000000000791b1 x10: 0000000000000001
Nov 17 14:32:49 kernel: x9 : 00000000001534c8 x8 : 0000000000000000
Nov 17 14:32:49 kernel: x7 : 0000000000137978 x6 : 0000000000143ba0
Nov 17 14:32:49 kernel: x5 : 00000000002a8080 x4 : 00000000002a8080
Nov 17 14:32:49 kernel: x3 : 00000000ffffffff x2 : 00000000f709e7a8
Nov 17 14:32:49 kernel: x1 : 0000000000000000 x0 : 00000000002a8080
Nov 17 14:32:54 watchdog: restart httpd
Nov 17 14:32:54 rc_service: watchdog 808:notify_rc stop_httpd
Nov 17 14:32:54 rc_service: watchdog 808:notify_rc start_httpd
Nov 17 14:32:54 RT-AC86U: start httpd:80
I've been seeing this, too. Not positive, but I think it started with the .8 alphas. I have an 86u.
 
Random httpd crashes on the RT-AC86U has existed for months. I've never seen it happen myself, can't reproduce it, and it could be caused by anything within httpd (and some portions of it are now closed source, so I can't review Asus's code either for any obvious issues).

The firmware watchdog should restart httpd within a minute or so.
 
Dirty update from 384.7_2 on AC86U...
Very impressed: run the update while streaming video, through a VPN connection, to a wifi connected Apple-TV and the update went through without interruption of the streaming video.
Thank you @RMerlin, this is simple awesome!
 
Random httpd crashes on the RT-AC86U has existed for months. I've never seen it happen myself, can't reproduce it, and it could be caused by anything within httpd (and some portions of it are now closed source, so I can't review Asus's code either for any obvious issues).

The firmware watchdog should restart httpd within a minute or so.

Is ASUS also seeing this crash?
 
So I decided to play around with QoS. I enabled Adaptive QoS with custom settings. I choose fq_codel Ethernet VLAN (4) for my GPON Fiber 500/500 mbit Internet connection and was using the preset for gaming with bandwidth set to 475/475 mbit. These are my results;

Without QoS:


With QoS:



I did retest a few times over and the results seems to be consistent. When enabling QoS I will be loosing throughput. I'm not entire sure how this Adaptive QoS is supposed to work in practice, but I figure when there is not much else going on it should let HTTP downloads reach at least 475 mbit as thats what configured as my bandwidth in the settings? It seems to be capping the bandwidth way too low if you ask me, at least considering there wasn't anything else hugging neither download or upload during the tests?

But I suppose this has nothing to do with 384.8 BETA1 and is just how the Adaptive QoS works and handles traffic to begin with? I tried to apply FreshJR Adaptive QoS script but the results are pretty much identical. I did also noticed that during the speed test one of the four cores on the RT-AX88U started to peak above 90% CPU so it might be hitting a processing wall as traffic is not able to be accelerated when using QoS and the traffic handling is just incapable of spreading across cores/threads so you are limited to the performance of a single core/thread and even the RT-AX88U is starting to limit your throughput at 300 mbps?
After changing out cables and coax I finally found that enabling qos or aiprotection cuts my download speeds in half on the rt-ax88u, stock firmware included
 
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