CPU Frequency adjustement policy on A20 (Debian)

Started by mossroy, February 06, 2014, 04:54:47 PM

Previous topic - Next topic


Hi all,

I'm trying to tweak the CPU frequency policy of my A20 olinuxino board.
Do you have any feedback on that topic?

My goal is to find a right balance between power consumption and performance.
Of course, I know there is no universal answer to that question. It really depends on how you want to use the board.

In my case, I want to use it as a headless server. It is always plugged to AC electricity and Ethernet.
Its main purpose is to expose services on the Internet (blogs or other HTTP web sites, jabber, caldav etc)
Most of the time, the CPU will be almost unused, and might be at a relatively low frequency.
But when a user accesses a web site (for example), I would like the CPU to quickly reach a high frequency, so that pages are quickly sent (at least since the second page...)

By default, with the Debian SD-card bought from Olimex, the scaling_governor is set to "fantasy" and the frequency seems to move between 60MHz and 912MHz.
But I found some other suggestions :
- on http://linux-sunxi.org/Cpufreq , they suggest to use "ondemand" governor, with some other tweaks :

echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 336000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 1008000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 40 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 200000 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate

(I suppose you also have to set the same values for cpu1, as the A20 has 2 cores)

- on my SD-card, there is a file /root/tune.sh with the following content (I suppose it has been created by someone from Olimex) :

echo performance > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

echo 1008000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 912000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

echo performance > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor

echo 1008000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq
echo 912000 > /sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq

Regarding power consumption, I measured the consumption of my board when idle :
- at 1008MHz, it consumes 1.6W
- at 912MHz, it consumes between 1.5W and 1.6W
- at 336MHz, it consumes 1.4W
- at 120MHz, it consumes 1.4W
- at 60MHz, it consumes between 1.3W and 1.4W
When both CPUs are at 100% at 1008MHz, it consumes between 2.6W and 3.1W

Here are the available governors :
root@A20:~# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors
interactive ondemand fantasy performance

If I understood well, the "performance" governor always keeps the CPU at its highest frequency. In my case, it's probably a bit overkill.
I have no info on the "interactive" governor. The "fantasy" one seems to be the default, but I did not find a lot of info on it, too.
Based on their names, I'm tempted to use the "ondemand" settings from linux-sunxi.org. I have set them in a script called by my /etc/rc.local


I suppose the chip is smart enough and halts the unused parts of the silicon. That is why the power consumption difference between 1 GHz and 60 MHz is so small. Linux sunxi kernel is based on the leaked Allwinner Android kernel so fantasy governor is most probably just one of the many Android governors and I don't think it is that useful for Linux desktop or server applications. My suggestion is to use either performance or tweaked ondemand governor. I have read somewhere (probably here: https://groups.google.com/forum/#!topic/linux-sunxi/SVZDqag7J_g) that the best governor to use at the moment is performance, especially if you are not running on battery.
Note that the default max speed for A20 is 912 MHz, so 1008 MHz means overclocking ...  ;)
But don't worry, most chips are running stable at up to 1.15 GHz w/o voltage increase :)


OK, thanks for the advice.
I've lowered the maximum frequency to 912 MHz for both CPUs.
Life span of my board is more important to me than a few more MHz. And I suppose overclocking might lower this life span...