What is considered hot? I don't see mine go above 55C on performance gov at max freq, but keep in mind I just use it as an AP, no other services running on it. But I would imagine if you run other processes that demand CPU, the CPU would stay at a high freq anyway.
Just to make it clear, I'm not arguing here, just trying to educate myself.
root@nbg6817:~# cat /sys/class/thermal/thermal_zone*/temp
99384
95856
95656
96932
100560
93327
94524
95656
100741
94524
101940
(thermal design (cooler size) of the nbg6817 is not quite as good as the r7800 - and this particular device is a bit on the high edge even relative to other nbg6817 devices)
Wowzers! Here's my R7800:
# cut -c1-2 /sys/devices/virtual/thermal/*/temp
51
48
50
48
51
48
51
49
49
45
52
Actually, looking closer at it, it seems as if nlbwmon would be running rampant, keeping the router (very) busy - it normally isn't that high (but it can easily reach those temperatures).
@slh when you see those temps, what freq do the cores run at? And are you using ondemand or performance?
On mine hostapd and softirq are the things that keep it busy. Though there is something that runs every 10 min. on the clock that makes the CPU freq go to max when running ondemand. Any ideas? I can't catch it in action but I suspect it might be ntpd that runs with nice -15
ondemand, but nlbwmon ramped it up to the max.
More 'normal' temperatures are:
# cat /sys/class/thermal/thermal_zone*/temp
85272
81744
82072
81930
85272
81106
82072
82072
83955
78676
87552
(yes, other nbg6817 are not that high, but those are regularly in the 70°C range as well)
I've settled on these settings for AP mode:
Move eth0/eth1 IRQs to CPU1 for a more balanced load between the cores:
echo 2 > /proc/irq/31/smp_affinity
echo 2 > /proc/irq/32/smp_affinity
Ondemand governor with 800MHz min freq and a bit of a boost when load shows up. Most of the time freq stays flat at 800MHz but there are occasional spikes. I noticed that otherwise it constantly bounces between 384-800MHz anyway.
echo ondemand > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo ondemand > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor
echo 800000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo 800000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq
echo 75 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
Temps are 50-53C, we'll see how it does in the summer when it gets warmer inside.
Unfortunately, this no longer works in master: the interrupts are not movable any more.
A scaling frequency back port fix was merged to 19.07 today, so the ondemand governor will work better now.
They sure do for eth0/1, but not for wifi.
# cat /proc/interrupts
CPU0 CPU1
...
31: 290372 474804 GIC-0 255 Level eth0
32: 12637013 23349424 GIC-0 258 Level eth1
...
Right. My LAN to WAN traffic is not existent, so I did not care about that and forgot. The command below splits the load between cores way better than assigning IRQs. I think all hard interrupts stay on the first core by default and all soft interrupts are on the second core.
find /sys/devices/ -name ""[x|r]ps_cpus"" | while read f; do echo 2 > $f; done
Hmm, but I already get 2 when I read from some of the queues. Maybe because I moved the interrupts?
# cat /sys/devices/platform/soc/*.ethernet/net/eth*/queues/*x-0/*ps_cpus
2
2
2
2
But for wlan I can't read from sysfs:
# cat /sys/devices/platform/soc/1b500000.pci/pci0000:00/0000:00:00.0/0000:01:00.0/net/wlan0/queues/tx-0/xps_cpus
cat: read error: No such file or directory
I guess it does not work in master....
To me it makes sense to keep related processing on the same core to take advantage of the L2 cache as much as possible. It appears some things like these queues are already set up to be on CPU1 for eth0/1 so the hardware interrupts would make sense to be handled there too.
But ... handling interrupts seems to be complex, between hardware interrupts, software interrupts (sriq), batching, rescheduling, etc. You can easily make it worse, you may get more load balancing between cores but slightly worse actual performance in practice. Too many tunables.
I also don't understand how traffic is processed, for example in AP mode there's a lot of wifi traffic that ends up on the wired ports, there's very little traffic wifi client to wifi client in my case. So there are wifi interrupts, then eth interrupts, then all the queuing for the wired ports and associated interrupts, etc. Lots of complexity to optimize anything. Then potential bugs.
Zyxel Armor Z2 NBG6817 - flow offloading - cpu on performance - etc. Somehow managed to run 600mbit constant with speedtest.
Running a speedtest for 15 minutes straight at 600mbit resulted into this for me so far:
root@OpenWrt:~# cut -c1-2 /sys/devices/virtual/thermal/*/temp
78
75
75
76
77
72
76
74
77
71
80
2 Likes
After upgrading to 19.07.2 it seems performacje of R7800 increased significantly.
On 19.07.1 it was max 24-25MB/s via 5Ghz and with 100% cpu1 load (and very high load on cpu0) now I got full link speed 300mbps (about 34-35MB/s) with about 50% load on both cores.
1 Like
This is good!.. BTW, Welcome!
I have up to 82MB/s on stock Wifi 5ghz, AP mode.
I am interested in performance figures for this router as a NAS. I.e. read/write speeds to USB or eSATA disk over SAMBA or NFS. Thanks.
There is no performance difference. (or there should not be...)
My currently latest 19.07 build (of commit e7f1313b) is a few commits ahead of 19.07.2 but nothing related to performance.
https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=e7f1313bbbf44e529e5de40045b191e026af6b7b
And there are no performance tweaks in my build.
1 Like