Added it to my config, will be included in the next upload.
@Kong -
downloaded kong-ipq806x-generic-netgear_r7800-squashfs-sysupgrade.bin for my R7800 to replace 21.02.1 - added irqbalance.
4 hours later both radios were down, LAN ethernet ports active, syslog a mess. box is somewhat up, down ... in a state of fux.
I'm back to 21.02.1
cheers,
M.
the final log to my local server is brief:
Jul 16 13:17:24 NineNet dnsmasq[2560]: possible DNS-rebind attack detected: ssl.google-analytics.com
Jul 16 13:19:24 NineNet dnsmasq[2560]: possible DNS-rebind attack detected: ssl.google-analytics.com
Jul 16 13:20:20 NineNet : luci: accepted login on / for root from 192.168.9.237
Jul 16 13:21:24 NineNet dnsmasq[2560]: possible DNS-rebind attack detected: ssl.google-analytics.com
Jul 16 13:21:47 NineNet dnsmasq[2560]: Cannot reconnect to UBus: Connection failed
Jul 16 13:21:47 NineNet dnsmasq[2560]: Cannot set UBus listeners: no connection
Jul 16 13:21:47 NineNet dnsmasq[2560]: exiting on receipt of SIGTERM
Interesting. I never used irqbalance on the R7800, since it makes zero sense on a dual core cpu. In certain benchmarks it may improve performance, but in general it does more harm to regular operation where you utilize both wireless and wired from multiple clients. Maybe it does a affect stability.
1 Like
Why does it make no sense to spread ISR service between 2 cores?
- the openwrt irqbalance wiki Here seems to show benefits for the R7800.
It only benefits, if you have special tasks. E.g. you have one Wireless device that transfers at full speed over wan. Then all wireless interrupts can stay on one core and ethernet interrupts on the other. Good for benchmarking. But in real life you have mutiple devices that transfer via lan,wireless you have cpu intensive tasks that also utilize these core. When both cores are utilized with several things the overhead that is introduced with transfering memory from one "core" to the other (context switches) will cause a negative effect. If you have a modern CPU with 4 or more Cores it is different, there you have enough cores which handle other tasks such a smb processing nat etc. there you want to make sure you have enough cpu power assigned for interrupt handling so you have handle the amount of interrupts, that come from ethernet, camera and other input devices, than you benefit is higher then the penalty that comes from shifting memory.between the caches etc.
If you would do a benchmark, with multiple devices from wan lan to wan and maybe have something a proxy (privoxy) running or smb to an attached drive, then you will definitely see, that the total throughput will be smaller. Otherwise you wouldn't need irqbalance, as it can only balance between 2 cores, you could easily set this your self, by pinning ether on core 0 and wireless on core 1. Which I have done for testing:-)
But as I said, this is only usefull if you want to achieve something special.
4 Likes
A striplined build with no extra packages will be great. Only wireguard and nlbwmon included. Unfortunately this is now running on 2-3 times more resources, CPU and memory, than other leading community build.
I acutally wrote that wiki sometime back on my github account. Although I don't use the R7800 anymore, switched to the WRT32X for the faster cpu (and an Rpi4 for experimenting) I still use irqbalance to move mwlwifi off cpu0 to cpu1, the 3 outputs are indeed from my devices over the years.
So it sounds like it's time to update the wiki with the dissent against irqbalance. @KONG is undoutably an authority on the matter 
(and all router matters, have followed him since the old days of R7000 on DD-WRT). I still think there is good reason to irqbalance in newer multicore devices like Rpi4 or R5S, which I think Kong is pointing out as well, where you would have the core headroom for interrupt handling.
edit: did quick update to the page adding a section on the concern, will add more later.
for the 'mwlwifi' interrupt on the R7800 are you referring to 2 ath10k_pci ISRs?
thanks!
No talking about still using it on my wrt32x, sorry for the confusion.
Hi all,
This is likely user error on my part and not a build related issue. Been using KONG 21 r16521+1-b1c3539868 build and other KONG builds prior to this one on my EA8500. Much appreciated for the efforts on all these builds!
For whatever reason, my 5Ghz channel tends to disable itself within a day or two . The 2.4Ghz channel operates just fine it the meantime. WHen the 5Ghz channel goes down, it shows 0 as signal but Noise value shows as -103. When its operational, i have these values:
Mode: Master | **SSID: SSID
BSSID: XX:xx:
Encryption: WPA2 PSK (CCMP)
Channel: 108 (5.540 GHz)
Tx-Power: 23 dBm
Signal: -26 dBm | Noise: -103 dBm
Bitrate: 6.0 Mbit/s | Country: US
Do i have incompatible settings somewhere? THe syslog below is where I believe the issue is occurring. Any thoughts?
Tue Jul 19 08:00:37 2022 daemon.notice hostapd: wlan1: DFS-RADAR-DETECTED freq=5540 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5530 cf2=0
Tue Jul 19 08:00:37 2022 daemon.notice hostapd: dfs_downgrade_bandwidth: no DFS channels left, waiting for NOP to finish
Tue Jul 19 08:00:37 2022 daemon.notice hostapd: wlan1: AP-DISABLED
Tue Jul 19 08:00:37 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED XX:XX:
Tue Jul 19 08:00:37 2022 daemon.err hostapd: 20/40 MHz: center segment 0 (=106) and center freq 1 (=5550) not in sync
Tue Jul 19 08:00:37 2022 daemon.notice hostapd: nl80211: deinit ifname=wlan1 disabled_11b_rates=0
Tue Jul 19 08:00:37 2022 kern.info kernel: [ 8915.074253] device wlan1 left promiscuous mode
Tue Jul 19 08:00:37 2022 kern.info kernel: [ 8915.074423] br-lan: port 2(wlan1) entered disabled state
Tue Jul 19 08:00:37 2022 daemon.notice netifd: Network device 'wlan1' link is down
Tue Jul 19 08:00:37 2022 daemon.notice hostapd: wlan1: interface state ENABLED->DISABLED
Tue Jul 19 08:00:38 2022 kern.info kernel: [ 8916.607739] br-lan: port 2(wlan1) entered blocking state
Tue Jul 19 08:00:38 2022 kern.info kernel: [ 8916.607774] br-lan: port 2(wlan1) entered disabled state
Tue Jul 19 08:00:38 2022 kern.info kernel: [ 8916.612409] device wlan1 entered promiscuous mode
Tue Jul 19 08:00:38 2022 daemon.notice hostapd: wlan1: interface state DISABLED->COUNTRY_UPDATE
Tue Jul 19 08:00:38 2022 daemon.notice hostapd: wlan1: interface state COUNTRY_UPDATE->HT_SCAN
Tue Jul 19 08:00:39 2022 daemon.err hostapd: could not get valid channel
Tue Jul 19 08:00:39 2022 daemon.notice hostapd: wlan1: interface state HT_SCAN->DFS
You're getting hit by stray radar ... Is your channel set to auto? I tried to use 1 fixed channel and kept losing my 5GHz. Switched to auto and it stays up.
The clue in your log is:
wlan1: DFS-RADAR-DETECTED freq=5540 ht_enabled=0 chan_offset=0 chan_width=3 cf1=5530 cf2=0
Tue Jul 19 08:00:37 2022 daemon.notice hostapd: dfs_downgrade_bandwidth: no DFS channels left, waiting for NOP to finish
Tue Jul 19 08:00:37 2022 daemon.notice hostapd: wlan1: AP-DISABLED
SOunds like user error then. Will change the wireless channel...not sure why i picked the DFS channel to begin with, other than there was less congestion there during initial setup. Thanks!
if it's any consolation - that's exactly how I hit this: by manually selecting the least-used channel ...!
I have an R7800 running Openwrt version 21, and have been running into an issue of my internet having crazy latency spikes (up to 1200ms on the Waveform bufferbloat test) and weird speed drops (stair-stepping) as shown in the picture. My internet is cable 600/20, and I don't have the issue when I plug straight into the modem. Help!
I've tried different versions of OpenWRT (even Hnyman's recent build) and it all acts the same. I have the performance governor in startup (same behavior with and without). I cloned the MAC address from the modem onto the WAN interface... Sheesh. Can't figure it out.
I have two spare EA8500's, and I swapped my R7800 out for one of them, and the problem is gone. Is my R7800 dead or dying?
Hello. I have a R7800 running a community build. Is it possible to flash this firmware (ipq806x-nss) through Sysupgrade?
Yes, no specials steps neede before, during or after the flashing process if you already have a recent OpenWRT running. Just flash ānā play.
Okay thanks for the response.
The same issue popped up on my EA8500. I'm starting to think that this is a ISP or modem-side issue. Disregard.