Yeah I think this is the fastest the chip will go on the router. If you want/need more perf, you'll need a more powerful router.
What frequency settings did you select?
The odd thing is, this problem didnt seem to exist on OpenWrt a year or two ago. That seems to imply its something outside of black box blobs, and should be fixable.
1 Like
720 to 920MHz overclock. 37 NINT for CPU, 19 for DDR PLL. Just enough to remove CPU bottleneck with couple of % left. It has been working fine for couple of days now. I could not really detect any extra energy consumption...Energy consumption measured by PoE went from 5.2 to 5.3W with 2.4GHz radio disabled.
What do you mean? Like the wifi speed was faster on an older build?
No, the apparently common wifi radio not responding issue. Either the 5ghz or more often the 2.4ghz, just stopping responding after a period of time.
5GHz radio in Archer C7 is rock solid. Never an issue. 2.4GHz is unusable. I have disable it and only use 5GHz. No congestion, more bandwidth.
At one point a while back I was experiencing only 5ghz radio problems with the 2.4ghz solid. Then, it was the 2.4ghz and the 5ghz has been no problem. 2.4 penetrates the many walls better in my house. I had 2.4 dropping out every 2-3 days, now with more recent snapshot, I have had 2.4 stable for a week or 2 if not longer. YMMV, I guess, though I don't know if you've tried the driver/firmware versions that was used for the April 3 snapshot.
Also I believe the Candela group has released an even newer -ct version in the past few days? Tried that?
I've sent out an email to Mr Greer in regards to the possibly when you max out the IRQ, possibly something gets stuck. We'll see.
I have run OpenWRT on C7's since 18.0.2. 2.4GHz has always been a issue.
5GHz has always worked flawlessly. I have tried new drivers for 5GHz (-ct) and they work well. But so does non -ct ones. Older drivers have slightly better throughput.
Regarding max sirq%: I do not believe something gets stuck, it is just that radio creates too much traffic for single-core MIPS CPU. But if you overclock it a bit it is just enough to keep radio working 100%.
Well, I guess it was an issue on YOUR C7. Seems MY C7's behaved differently, and differently over time as I updated into newer (or tried snapshot) versions.
Anyway, just trying to imagine mechanisms that might exist with known conditions, and result in a particular problem, for debugging purposes. Maybe a maxed out sirq could sometimes cause a radio to get into a unresponsive state. Maybe not. Thought it worth thinking about as a clue to solve the radio unresponsive bug.
For me, with my 300/30mbit cable connection, the speed isn't an issue, think I'll just run at 40mhz bandwidth, and know I'll have resources left over. A few too many bricking stories using different bootloaders in that thread...
Every now and then, I have a paging crash. Is it possible to say from log if it is ath10k driver that crashes or is something else (perhaps due to overclock)? I will try to change to -ct drivers and see if it cures the issue.
May 25 16:38:58 OpenWrt7 kernel: [78421.075639] ath10k_pci 0000:00:00.0: HTC Rx: invalid eid 128
May 25 16:39:09 OpenWrt7 kernel: [78432.032508] BUG: Bad page state in process swapper pfn:07128
May 25 16:39:09 OpenWrt7 kernel: [78432.038344] page:810eb120 count:-1 mapcount:0 mapping: (null) index:0x0
May 25 16:39:09 OpenWrt7 kernel: [78432.045134] flags: 0x0()
May 25 16:39:09 OpenWrt7 kernel: [78432.047703] raw: 00000000 00000000 00000000 ffffffff ffffffff 00000100 00000200 00000000
May 25 16:39:09 OpenWrt7 kernel: [78432.055895] page dumped because: nonzero _count
May 25 16:39:09 OpenWrt7 kernel: [78432.060479] Modules linked in: pppoe ppp_async ath10k_pci ath10k_core ath pppox ppp_generic nf_conntrack_ipv6 mac80211 iptable_nat ipt_REJECT ipt_MASQUERADE cfg80211 xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limit xt_conntrack xt_comment xt_TCPMSS xt_REDIRECT xt_LOG xt_FLOWOFFLOAD xt_CT slhc nf_reject_ipv4 nf_nat_redirect nf_nat_masquerade_ipv4 nf_conntrack_ipv4 nf_nat_ipv4 nf_nat nf_log_ipv4 nf_flow_table_hw nf_flow_table nf_defrag_ipv6 nf_defrag_ipv4 nf_conntrack_rtcache nf_conntrack iptable_mangle iptable_filter ip_tables crc_ccitt compat ledtrig_usbport nf_log_ipv6 nf_log_common ip6table_mangle ip6table_filter ip6_tables ip6t_REJECT x_tables nf_reject_ipv6 ehci_platform ehci_hcd gpio_button_hotplug usbcore nls_base usb_common
May 25 16:39:09 OpenWrt7 kernel: [78432.128121] CPU: 0 PID: 0 Comm: swapper Tainted: G B 4.14.171 #0
May 25 16:39:09 OpenWrt7 kernel: [78432.135350] Stack : 804fbf60 800b2ba4 80500000 804b05e0 00000000 00000000 00000000 00000000
May 25 16:39:09 OpenWrt7 kernel: [78432.143823] 00000000 00000000 00000000 00000000 00000000 00000001 87c07ba0 214d6831
May 25 16:39:09 OpenWrt7 kernel: [78432.152298] 87c07c38 00000000 00000000 00005498 00000038 80448498 00000008 00000000
May 25 16:39:09 OpenWrt7 kernel: [78432.160772] 0000010e 595fb6d6 0000010d 00000000 87c07b80 00000000 80660000 804fbfb4
May 25 16:39:09 OpenWrt7 kernel: [78432.169246] 804892b8 804fc3a0 00000008 00000003 00000000 8027ffd4 00000000 80630000
May 25 16:39:09 OpenWrt7 kernel: [78432.177721] ...
May 25 16:39:09 OpenWrt7 kernel: [78432.180194] Call Trace:
May 25 16:39:09 OpenWrt7 kernel: [78432.180201] [<800b2ba4>] 0x800b2ba4
May 25 16:39:09 OpenWrt7 kernel: [78432.186206] [<80500000>] 0x80500000
May 25 16:39:09 OpenWrt7 kernel: [78432.189756] [<80448498>] 0x80448498
May 25 16:39:09 OpenWrt7 kernel: [78432.193294] [<8027ffd4>] 0x8027ffd4
May 25 16:39:09 OpenWrt7 kernel: [78432.196830] [<8006a56c>] 0x8006a56c
May 25 16:39:09 OpenWrt7 kernel: [78432.200366] [<8006a574>] 0x8006a574
May 25 16:39:09 OpenWrt7 kernel: [78432.203895] [<800f6ee4>] 0x800f6ee4
May 25 16:39:09 OpenWrt7 kernel: [78432.207427] [<800f998c>] 0x800f998c
May 25 16:39:09 OpenWrt7 kernel: [78432.210969] [<800fa344>] 0x800fa344
May 25 16:39:09 OpenWrt7 kernel: [78432.214509] [<800fb008>] 0x800fb008
May 25 16:39:09 OpenWrt7 kernel: [78432.218046] [<80302c48>] 0x80302c48
May 25 16:39:09 OpenWrt7 kernel: [78432.221594] [<876393bc>] 0x876393bc [ath10k_pci@87638000+0x6270]
May 25 16:39:09 OpenWrt7 kernel: [78432.227684] [<87715e08>] 0x87715e08 [ath10k_core@87700000+0x4e3b0]
May 25 16:39:09 OpenWrt7 kernel: [78432.233960] [<87715cc0>] 0x87715cc0 [ath10k_core@87700000+0x4e3b0]
May 25 16:39:09 OpenWrt7 kernel: [78432.240226] [<8763977c>] 0x8763977c [ath10k_pci@87638000+0x6270]
May 25 16:39:09 OpenWrt7 kernel: [78432.246317] [<8763b340>] 0x8763b340 [ath10k_pci@87638000+0x6270]
May 25 16:39:09 OpenWrt7 kernel: [78432.252419] [<8773a8f0>] 0x8773a8f0 [ath10k_core@87700000+0x4e3b0]
May 25 16:39:09 OpenWrt7 kernel: [78432.258688] [<80500000>] 0x80500000
May 25 16:39:09 OpenWrt7 kernel: [78432.262223] [<8773a9f0>] 0x8773a9f0 [ath10k_core@87700000+0x4e3b0]
May 25 16:39:09 OpenWrt7 kernel: [78432.268500] [<8763b110>] 0x8763b110 [ath10k_pci@87638000+0x6270]
May 25 16:39:09 OpenWrt7 kernel: [78432.274587] [<800b83c4>] 0x800b83c4
May 25 16:39:09 OpenWrt7 kernel: [78432.278125] [<8031867c>] 0x8031867c
May 25 16:39:09 OpenWrt7 kernel: [78432.281662] [<800b42f0>] 0x800b42f0
May 25 16:39:09 OpenWrt7 kernel: [78432.285207] [<8044dfe8>] 0x8044dfe8
May 25 16:39:09 OpenWrt7 kernel: [78432.288736] [<800b8d94>] 0x800b8d94
May 25 16:39:09 OpenWrt7 kernel: [78432.292270] [<8022f100>] 0x8022f100
May 25 16:39:09 OpenWrt7 kernel: [78432.295802] [<800657d8>] 0x800657d8
May 25 16:39:09 OpenWrt7 kernel: [78432.299338]
OK, it seems like my aggressive overclocking of AHB made WiFi driver crash now and then.
Use following settings to make it work better:
CPU:24
DDR:16
It will yield 960MHz CPU, 640MHz DDR and 320MHz AHB.
What is AHB?
And what are the defaults (non-o/c) values for CPU, RAM and AHB?
Cheers.
Default values are: CPU: 720MHz, DDR: 600MHz, AHB: 200MHz, Ref: 40MHz
AHB is bus speed. It seems like raising bus speed from 200MHz to 380MHz was making it unstable. Who would know? 
But CPU is perfectly happy running at 960MHz, and bus speed can be kept @ 320MHz. This helps with OpenVPN speeds as well as routing (in case you use Archer C7 as main router. I only use it as an AP).
1 Like
AHB is the intra-SOC bus connecting the RAM controller, 2.4 GHz wifi subsystem and other integrated I/O blocks to the CPU. It is 32 bits wide, so the maximum bandwidth in bytes per second is 4 times the clock rate.
Since the DDR is 16 bits wide, it should be clocked twice as fast as the AHB to balance performance-- thus the default 400 / 200. Overclocking the RAM more than 2 x AHB probably won't see a performance increase overall, but it is something to experiment with.
3 Likes
Even 1000/600/300 I'm see 99% sirq usage what can I do?
My c7 is both ap and router
You have to understand that Archer C7 is using it's CPU for both NAR/routing and also for parts of WiFi driver. Thus, if you have fast Internet connection and are using 5GHz WiFi you might run into CPU bottleneck.
What you can do is to try to enable flow offload in Firewall general settings. That will yield best throughput possible. I do not know what C7 router performance on OpenWRT is but you should be able to hit at least 500Mbit/sec routing speed with wired client. Perhaps less with WiFi.
I get 400mbps wireless now.
Is it safe to oc cpu to higher values?