Could use performance locked at max all the time and monitor the temps for a bit, if not running very hot, good enough. People ask about power consumption but in the grand scheme of things in a house it doesn't really matter.
Did you change /sys/devices/system/cpu/cpufreq/schedutil/rate_limit_us from the 10000 default? Android phones seem to set it to 0.
how to tell?
no it stays at 10000
I don't think schedutil works. Do you see the frequency change at all? Mine has been flat at 800MHz for the past couple hours (that's what I set the min freq to). With ondemand it goes up once in a while. I can make it spike briefly when I log in to the UI or ssh in.
Setting the min frequency to 800 MHz gives the best performance at minimal CPU freq with schedutil when speedtest-netperf.sh -H netperf-west.bufferbloat.net -p 1.1.1.1 --sequential -t 20 and measuring downstream throughput with SQM enabled on the router.
I tried varying the min frequency then running the speed test. Here is my result:
Freq MHZ Downstream Mbps
384 184
384 181
600 191
600 189
800 200
800 197
1000 201
1000 198
1400 199
1400 200
1725 200
1725 201
You can see that 800 MHz seems in the sweetspot of maximal throughput at minimal lower boundary for CPU frequency. I am away from my laptop now or I would show a nice little plot of these two.
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.
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: