Yeah that is weird considering the Krait 300 CPU of the R7800 is clock for clock significantly more powerful than the Cortex A9 in the WRT1900ACS.
Is it though, because it was also booting slower. Even with the stock firmware. The Krait is faster because it's a quad core configuration with higher clocks. In this implementation it's a dual core with just 100MHz higher clock than the CPU of the ACS. The differences in everyday usage are quite staggering.
The IPQ8065 has dual Core CPU not Quad - ignore marketing because they include the 2 packet accelerators for 2.4/5Ghz. Difference is more than just MHz. Clock for a clock the IPQ is 35% faster for every MHz as it's based on a newer architecture close to the Cortex A15 (3.39 DMIPS/MHz) and the ACS uses an older Cortex A9 (2.5 DMIPS/MHz) based chip. So the dual core Krait @1.7 Ghz is theoretically ~44% faster than the A9 @1.6 Ghz in the ACS. Most noticeable in CPU intensive applications like OpenVPN. Kong, a DD-WRT dev did some SSL aes256 benchmarks which roughly correlates the above.
1 Like
So there was something wrong with both the manufacturer's firmware and all LEDE versions we tried then, because in all of them USB transfers were less than half than what they were with the ACS, and any type of QoS would bring his 200/10 connection to its knees, which is the complete opposite of what's happening with the ACS and bog-standard 17.01.2 LEDE.
Has anyone here actually tested the R7800 with a 150Mbit+ connection and a really fast USB3 drive?
In most reviews I have seen the WRT1900ACs do really well USB transfers wise, maybe it has better optimization in that area. The R7800 is a performs really well on 5Ghz (probably the best in 5Ghz performance in consumer market) and OpenVPN benchmarks but yeah it chokes on USB transfers for some reason. I can test again with Voxel's modified stock firmware, and get back to you, I mostly use a NAS so I don't use the USB ports much. EDIT: 40/20 MB/s Read/Write, test device was a OEM USB 3.0 Case with an Hitachi 5,400 RPM 2.5" Drive.
This fits our numbers. With SQM with cake/piece of cake the performance was abysmal. The connection is 200/10 with real speeds of 220/11. With the Netgear we were getting 130/8 with cake/piece of cake, and 80% CPU usage during the test.
With the 1900ACS and the exact same settings (190.000/9.500) we were getting 180/9, with 17% CPU usage. The UI is also faster and booting is at least twice as fast.
I'm trying to enable hardware crypto engine, but smth is wrong and it stalls during boot (no serial so I don't know the reason).
I've made this up upon OEM gpl:
ranges - https://github.com/paul-chambers/netgear-r7800/blob/eeac2e10190f6f45e32e4c7012c4babc351898d8/git_home/linux.git/sourcecode/arch/arm/mach-msm/devices-ipq806x.c#L2893
dma channels - https://github.com/dissent1/netgear-r7800/blob/master/git_home/linux.git/sourcecode/arch/arm/mach-msm/include/mach/dma.h#L231
Maybe im picking wrong interrupt? Or wrong engine? (There are 4 engines 0 - 3)
Building ipq806x is currently broken due to mtd changes in generic.
Fix in https://github.com/lede-project/source/pull/1192
Has anyone investigated on this matter and if it provides any gain in our case?
http://syuu.dokukino.com/2013/05/linux-kernel-features-for-high-speed.html
It is already available.
https://source.codeaurora.org/quic/qsdk/oss/lklm/qca-rfs/
You just have to figure out how to get it working on stock lede
Don't reinvent the wheel
What wheel? It's in kernel already and disabled by default.
https://www.mjmwired.net/kernel/Documentation/networking/scaling.txt#138
RPS is probably meant for x86, while RFS was made by Qualcomm for their Krait Cores
So which do you think is more optimized for your IPQ Processor?
1 Like
RFS functions on top of RPS
https://www.mjmwired.net/kernel/Documentation/networking/scaling.txt#225
How optimized qca-rfs could be doesn't matter as soon as it depends on qca-ssdk which depends on a bunch of other nss-* packages for ipq806x that require kernel modification.
Apart from that kernel inbuilt rps and rfs are generic and work on top of common linux stack
If I have had enough experience I would have built lede on top of msm QSDK kernel with all the needed packages, but that's not the case
There seem to be a hope that crypto engine in ipq806x can be enabled
https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/commit/?h=release/endive_preview_cc&id=c28823b60c4d8543c7006eadd5a80e8201fa1766
Let's give it a try....
Could you please help me with my wireless. It is unstable
If I download something or do a speed test, wireless will down.
[ 1268.169710] ------------[ cut here ]------------
[ 1268.174606] WARNING: CPU: 1 PID: 61 at compat-wireless-2017-01-31/net/mac80211/driver-ops.c:39 ieee80211_del_virtual_monitor+0x768/0x7a8 [mac80211]
[ 1268.179090] Modules linked in: pppoe ppp_async pppox ppp_generic nf_conntrack_ipv6 iptable_nat ipt_REJECT ipt_MASQUERADE xt_time xt_tcpudp xt_tcpmss xt_string xt_statistic xt_state xt_socket xt_recent xt_nat xt_multiport xt_mark xt_mac xt_limit xt_length xt_hl xt_helper xt_esp xt_ecn xt_dscp xt_conntrack xt_connmark xt_connlimit xt_connbytes xt_comment xt_TPROXY xt_TCPMSS xt_REDIRECT xt_LOG xt_IMQ xt_HL xt_DSCP xt_CLASSIFY ts_kmp ts_fsm ts_bm slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack_netlink nf_conntrack macvlan iptable_mangle iptable_filter ipt_ah ipt_ECN ip_tables imq crc_ccitt fuse sch_teql sch_sfq sch_red sch_prio sch_pie sch_gred sch_fq sch_dsmark sch_codel em_text
[ 1268.261934] em_nbyte em_meta em_cmp cls_basic act_police act_ipt act_skbedit act_mirred em_u32 cls_u32 cls_tcindex cls_flow cls_route cls_fw sch_tbf sch_htb sch_hfsc sch_ingress ath10k_pci ath10k_core ath mac80211 cfg80211 compat ledtrig_usbport xt_set ip_set_list_set ip_set_hash_netiface ip_set_hash_netport ip_set_hash_netnet ip_set_hash_net ip_set_hash_netportnet ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark ip_set_hash_ip ip_set_bitmap_port ip_set_bitmap_ipmac ip_set_bitmap_ip ip_set nfnetlink ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables x_tables nfsv3 nfs vfat fat ntfs lockd sunrpc grace nls_utf8 nls_iso8859_1 nls_cp950 nls_cp936 nls_cp437 usb_storage leds_gpio xhci_plat_hcd xhci_pci xhci_hcd dwc3 dwc3_of_simple ohci_platform ohci_hcd phy_qcom_dwc3 ahci ehci_platform sd_mod ahci_platform libahci_platform libahci libata scsi_mod ehci_hcd gpio_button_hotplug ext4 jbd2 mbcache crc32c_generic
[ 1268.348955] CPU: 1 PID: 61 Comm: kworker/1:1 Tainted: G W 4.9.34 #0
[ 1268.349219] Hardware name: Generic DT based system
[ 1268.356724] Workqueue: events_freezable ieee80211_restart_work [mac80211]
[ 1268.367796] [<c0215670>] (unwind_backtrace) from [<c0211f1c>] (show_stack+0x10/0x14)
[ 1268.368152] [<c0211f1c>] (show_stack) from [<c0396864>] (dump_stack+0x7c/0x9c)
[ 1268.375962] [<c0396864>] (dump_stack) from [<c021d860>] (__warn+0xbc/0xec)
[ 1268.382990] [<c021d860>] (__warn) from [<c021d934>] (warn_slowpath_null+0x1c/0x24)
[ 1268.389885] [<c021d934>] (warn_slowpath_null) from [<bf318970>] (ieee80211_del_virtual_monitor+0x768/0x7a8 [mac80211])
[ 1268.397472] [<bf318970>] (ieee80211_del_virtual_monitor [mac80211]) from [<bf3189c0>] (ieee80211_stop+0x10/0x18 [mac80211])
[ 1268.408123] [<bf3189c0>] (ieee80211_stop [mac80211]) from [<c04f383c>] (__dev_close_many+0x94/0xb8)
[ 1268.419107] [<c04f383c>] (__dev_close_many) from [<c04f38c0>] (dev_close_many+0x60/0xd4)
[ 1268.428133] [<c04f38c0>] (dev_close_many) from [<c04f73b4>] (dev_close+0x30/0x48)
[ 1268.436486] [<c04f73b4>] (dev_close) from [<bf2c9434>] (cfg80211_shutdown_all_interfaces+0x64/0xb0 [cfg80211])
[ 1268.443903] [<bf2c9434>] (cfg80211_shutdown_all_interfaces [cfg80211]) from [<bf33150c>] (ieee80211_reconfig+0x32c/0x9ac [mac80211])
[ 1268.453807] [<bf33150c>] (ieee80211_reconfig [mac80211]) from [<bf306180>] (ieee80211_restart_work+0x84/0x98 [mac80211])
[ 1268.465843] [<bf306180>] (ieee80211_restart_work [mac80211]) from [<c02310bc>] (process_one_work+0x1d4/0x310)
[ 1268.476661] [<c02310bc>] (process_one_work) from [<c0231da4>] (worker_thread+0x2d8/0x414)
[ 1268.486466] [<c0231da4>] (worker_thread) from [<c0235d04>] (kthread+0xd8/0xec)
[ 1268.494624] [<c0235d04>] (kthread) from [<c020ec78>] (ret_from_fork+0x14/0x3c)
[ 1268.501796] ---[ end trace 335bf02939b41094 ]---
And there are a lot of error log when boot.
[ 21.519366] Buffer I/O error on dev mtdblock0, logical block 0, async page read
[ 21.526352] blk_update_request: I/O error, dev mtdblock1, sector 0
[ 21.533433] blk_update_request: I/O error, dev mtdblock1, sector 8
[ 21.539643] blk_update_request: I/O error, dev mtdblock1, sector 16
[ 21.545770] blk_update_request: I/O error, dev mtdblock1, sector 24
[ 21.552043] Buffer I/O error on dev mtdblock1, logical block 0, async page read
[ 21.560747] Buffer I/O error on dev mtdblock1, logical block 0, async page read
[ 23.836099] Buffer I/O error on dev mtdblock0, logical block 0, async page read
[ 23.840803] Buffer I/O error on dev mtdblock0, logical block 0, async page read
[ 23.845024] Buffer I/O error on dev mtdblock1, logical block 0, async page read
[ 23.852593] Buffer I/O error on dev mtdblock1, logical block 0, async page read
Seems I've been at wrong point looking for qce base address. The address before seem to lead to nss cores and that's incorrect.
The correct address is here
And it seem to correspond to apq8064 data sheet (twin brother) and interrupts - it's pointing to ce3 core.
But what's the bam base address? It's safe to assume that bam base is QCE_0_BASE + 0x4000 = 0x11004000.
But what's the size of it? Couldn't find anywhere. Guess I've got to try size = 0x8000 (as in 8974 soc), 0x10000 (as qce size), 0x20000 (as in ipq4019), 0x22000 (as in nss crypto engines)
It seem to be really possible to enable crypto engine in ipq806x
The IPQ806x probably doesn't have a dedicated dma for the crypto then.
The constants DVM8064_ are defined in:
So you don't have cryptobam. Instead it's the adm_dma and qce 4.0. I guess you are looking at something like:
crypto@11000000 {
compatible = "qcom,crypto-v4"; // it's not 5.1
reg = <0x11000000 0x10000>;
clocks = <&gcc CE5_H_CLK>,
<&gcc CE5_SRC>,
<&gcc CE5_CORE_CLK>;
clock-names = "iface", "src", "core";
dmas = <&adm_dma 2 4>,
<&adm_dma 3 5>;
dma-names = "rx", "tx";
// status = "disabled"; Well it doesn't work. But there's no point in disabling it, since there is no driver.
};
However, I don't think it will work. The IPQ806x's crypto probably is older than 5.1. You could try to use the "qcom,crypto-v5.1" compatible string. But looking at the driver it will call -ENODEV for anything less than 5.1:
If you want you could move the debug print from this line:
in front of the version check. This way you'll know what version you are dealing with.
It's highly possible that it's qce40 really.
It's in k3.10 when qce40 got removed from msm kernel ...
https://source.codeaurora.org/quic/la/kernel/msm-3.10/commit/drivers/crypto/msm?h=msm-3.10&id=f06163e6d0b0c001ed79275cbe522d0b62ace3ed
Why did they do this to me?!
@hnyman
It seems there are a lot of fixes for our daily bugs, like peer unmap event failed, unknown vdev and some other crashes
https://source.codeaurora.org/quic/qsdk/oss/kernel/linux-msm/log/drivers/net/wireless/ath/ath10k?h=caf7/rel/msm-4.4
edit: mostly not appropriate for qca99xx as it addresses new qca chipset.
How do people find wireless range on this device? I'm coming from an Archer C7 which I am finding is poor in my house on 5GHz especially. Probably 5000 square feet to cover altogether.