R7800 performance

As to the discussion around power consumption, I used a Kill-a-Watt P3 to measure it on my R7800 at various CPU speeds and with various governors. I found that the CPU frequency did not affect power consumption at least that could be detected with my Kill-a-Watt. Note that it does not report mW, just W without a decimal (ie 6 or 7 or 25 etc.).

Idle power consumption was 6 W irrespective of frequency (I tried each one from 384 MHz up to 1725 MHz). When the CPU was loaded with the SQM script with a wired client pulling all of my downstream bandwidth bounced between 6 and 7 W.

1 Like

maybe try setting rate_limit_us to 0

yep. 800000

You can reset stats by writing to:
echo 1 > /sys/devices/system/cpu/cpufreq/policy0/stats/reset
echo 1 > /sys/devices/system/cpu/cpufreq/policy1/stats/reset

Let it run for a while then you can look at:
cat /sys/devices/system/cpu/cpufreq/policy*/stats/time_in_state

1 Like

I'm more worried about temps and cooking the router if it runs very hot than what it costs to power it. Mine seems to stay under 60C in the summer so it's OK, even if it goes up another 10C. I have an Asus router that ran at >80C for a few years and it's still functional.

It looks like it does move between frequencies:

# cat /sys/devices/system/cpu/cpufreq/policy*/stats/time_in_state
384000 0
600000 0
800000 97069
1000000 100
1400000 61
1725000 82
384000 0
600000 0
800000 97064
1000000 90
1400000 54
1725000 66

I guess it doesn't stay in the higher frequencies long enough for collectd to catch it, I normally look at the graphs in the UI.

Update: It still doesn't look right to me, after a few hours, there's very little time spent above 800MHz. Either this governor is very good vs ondemand and doesn't think it needs to scale up or it doesn't work well. Given how tricky it is to get these governors working, I suspect there may be work required to make schedutil functional.

@wired - I think you want a measure that is more functional in nature rather than time spent at a particular frequency. For example, what is the most CPU intensive task you do with your hardware that can also be directly quantitated?

For me it's just running a speed test with SQM enabled. My connection is 225 Mbps down and that is enough to nearly saturate the CPU:

As I showed above, running the speed test a few times gives a decent average and shows a saturable effect with respect to the measured value. Above, I compared different lower thresholds with schedulit, but I also compared schedutil to ondemand to performance and found them to be really close perhaps within experimental error:

schedutil     197
schedutil     196
schedutil     200
ondemand      200
ondemand      200
ondemand      200
performance   195
performance   199
performance   198

I am not a fan of synthetic benchmarks just because they tend not to represent any real world workload, but perhaps you could select one and use it as a more sensitive measure of how effective the different governors function to scale the CPU.

1 Like

ended up revert back to ondemand as it's a bit more stable for me. schedutil is decent, has potential.

@darksky In a speed test or any test that saturates the CPU, wouldn't it be the case that the CPU ramps up to max and it just stays there, in effect making it just like using performance governor?

Just for fun, I switched it back to ondemand with the QCA settings and I noticed that the CPU only spends time in 3 states: 800000, 1000000, 1725000. It completely avoids 1400000. This makes sense based on the settings, as soon as load hits 50% it just jumps to max freq.

# cat /sys/devices/system/cpu/cpufreq/policy*/stats/time_in_state
384000 0
600000 0
800000 2526146
1000000 7243
1400000 0
1725000 17221
384000 0
600000 0
800000 2543273
1000000 1870
1400000 0
1725000 5444

It should but I find that I get the same speed result even though the governor does not hold the CPU freq to the max when I tested.

From the QCA settings comments, the impact of raising min freq to 800000 is about 40-45mW.

I have similar results,1.4ghz is never used. My CPU settings take place after the router boots up via /etc/rc.local (explaining the short periods of time at other frequencies).


root@OpenWrt:~# cat /etc/rc.local
# Put your custom commands here that should be executed once
# the system init finished. By default this file does nothing.

echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 800000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq
echo 20 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 60 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo 1000000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate

exit 0


root@OpenWrt:~# cat /sys/devices/system/cpu/cpufreq/policy*/stats/time_in_state
384000 1078
600000 109
800000 7410560
1000000 74
1400000 0
1725000 436982
384000 2240
600000 68
800000 7287366
1000000 82
1400000 0
1725000 559047

My conclusion from playing with the governors is that the best settings are:

echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo performance > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor
echo 800000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
echo 800000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_max_freq
sleep 1
echo 1725000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq
echo 1725000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_max_freq

I don't know if going thru 800000 matters, I've seen it mentioned somewhere that you can't go from 384 to max, you have to ramp up thru 800. It doesn't hurt anything to have it there.
My temps are about 1-2C higher with these performance settings. Noise really.

2 Likes

That bug was fixed in the spring. You just need to set the performance governor now.

Do you know if this fix has been applied to the ZyXEL NBG6817? It has the same hardware as the R7800.

It should be because as you said:

The main R7800 page (https://openwrt.org/toh/netgear/r7800) still says to do this.

echo 35 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor    

I haven't heard anyone mention this in awhile; is this still recommended/needed with the latest openwrt (19.07.3)?

2 Likes

Why not just run performance governor at max freq all the time and not search for the perfect settings anymore? Heat is not a problem on the R7800 but do monitor it:
cut -c1-2 /sys/devices/virtual/thermal/*/temp

With an aggressive ondemand up_threshold value you will pretty much spend most time at max frequency anyway, bouncing between min and max frequencies.

I don't think many realize what up_threshold means, it is not the load to step up to the next freq, but rather to jump up all the way to max freq. I tried it with min=800, max=1.7 and up_threshold=20 and it just flip-flops between 800 and 1.7, the frequencies in between (1.0, 1.4) are never used.

From the kernel documentation:
https://www.kernel.org/doc/html/v5.4/admin-guide/pm/cpufreq.html

up_threshold
If the estimated CPU load is above this value (in percent), the governor will set the frequency to the maximum value allowed for the policy. Otherwise, the selected frequency will be proportional to the estimated CPU load.

(useful to also read the explanation for sampling_down_factor)

After you make governor changes, you can:

# Reset stats
echo 1 > /sys/devices/system/cpu/cpufreq/policy0/stats/reset
echo 1 > /sys/devices/system/cpu/cpufreq/policy1/stats/reset

Then run it for a bit and:

# View stats
cat /sys/devices/system/cpu/cpufreq/policy*/stats/time_in_state
3 Likes

Why not just run performance governor at max freq all the time and not search for the perfect settings

To be clear, do you mean doing just this and skipping the other stuff?

echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo performance > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor

Exactly.
This is what I have in my /etc/rc.local so I can easily uncomment the governor I want to use and comment out the other 2:

# min scaling frequency: set to 800MHz because of L2 cache issues
echo 800000 > /sys/devices/system/cpu/cpufreq/policy0/scaling_min_freq
echo 800000 > /sys/devices/system/cpu/cpufreq/policy1/scaling_min_freq
sleep 1
# ondemand governor
#echo ondemand > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
#echo ondemand > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor
#echo 100000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
#echo 75 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
#echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
# schedutil governor
#echo schedutil > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
#echo schedutil > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor
#echo 100000 > /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us
# performance governor
echo performance > /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
echo performance > /sys/devices/system/cpu/cpufreq/policy1/scaling_governor
# Reset stats
echo 1 > /sys/devices/system/cpu/cpufreq/policy0/stats/reset
echo 1 > /sys/devices/system/cpu/cpufreq/policy1/stats/reset
3 Likes

Can anyone tell me where to check to figure out why my R7800 restarts randomly? For the third time it has restarted at the most inopportune time (conference call, middle of game, etc.). I am running hnyman's build - trying different "tuning" that people post, but the same thing always happens. I have looked in /var/log and found nothing. I looked at the kernel and system logs in the GUI and found nothing. Where do I go to see what is causing these crashes? Anyone know?

Thanks!
DeadEnd