autoCpuFreq - linux daemon controlling cpu-freq and vCore on demand

About:

autoCpuFreq is a python script that automatically adopts CPU frequency and voltage (vCore) depending on CPU-usage on NForce2 based mainboards. Furthermore autoCpuFreq has a basic overheat protection: if current temperature overshoots a limit, then daemon scales CPU-values down. How it works

This is a "quick & dirty" version, written for my own need (cause there is no linux version of hasw's 8rdavcore). A clean solution would be a kernel-module governor...

This script does not care of /sys/.../cpufreq/scaling_{max,cur,min}_freq. So if you use autoCpuFreq-daemon do not change that values, also do not change freq & vCore manually while daemon is running, otherwise system hangs or hardware damage is possible. That is because at switch-time wrong vCore-freq pairs are then possible.

The script requires hasw's NForce2 kernel-modules: cpufreq-nforce2 and atxp1 [http://hasw.net -> linux]

It works well with:

debian-sarge with debian-kernel 2.6.8
cpufreq-nforce2-0.2
atxp1-0.3

on my ABit NF7-S v2.0 with AMD Athlon XP 2500+

Download:

current version is 0.02a / 11 March 2005

autoCpuFreq.py - daemon script
autoCpuFreqRc - debian init script (*)

Download: autoCpuFreq - v0.02a

(*) about that strange module-load in autoCpuFreqRc:

In current debian-kernel the performance-governor is compiled in. So after loading cpufreq-nforce2 module the highest frequency is automatically been choosed. I run my System with a very low vCore but for that highest frequency it isn´t enough so my system hangs while loading cpufreq-nforce2 module with high max-fsb value. That is why I have to load the atxp1 module first and change vCore to valid value for this high frequency (save boot-time-vCore is needed, cause my system will not boot clean next time, if I do not restore correct boot-time vCore value before shutdown/reboot).

If you compile your own kernel, you can compile userspace-governor in your kernel, and load required modules in normal way. (probably)

Installation:

for installation you need superuser access (write access to /sys-interface)

<1> first correct paths & system-specific-values in both script-files (autoCpuFreqRc & autoCpuFreq.py).

Important are: (example values for my system)

path to set vCore: /sys/bus/i2c/devices/0-004e/cpu_vid
vCore and freq pairs

If you wish to watch temperature: (otherwise set DoTemp=False in py-script !)

paths to temperature files: /sys/bus/i2c/devices/2-0290/temp{2,1}_input # I watch CPU & system temps.
MAXtemp: max-temperature for each sensor (sys-sensor-value / 1000)
BUFtemp: better leave unchanged - buffer values to avoid fast oscillation
Ntemp: set correct names

!!! very important !!!
in autoCpuFreq.py: set the correct frequency-vCore pairs and FSB-multiplier at which your system works stable, otherwise system-hangs or maybe hardware damage are possible!!!

finally you can set time-values to specify reaction times and load-triggers [in %] to designate switch behavior. Default values works good (for me)...

<2> after setting all required system-specific [and
user-specific] values, test/run it:

for manual start (or if you wish first test the script with debug output (set DEBUG=True) ):

execute  autoCpuFreqRc load   # load
required modules & save boot-time-vCore

or load them manually

- are all modules well loaded, continue with

execute  autoCpuFreq.py

- and finally after terminating autoCpuFreq.py (if you exec.
"autoCpuFreqRc load")

execute  autoCpuFreqRc
reset  # restore boot-time-vCore &
boot-FSB

for auto-start on debian systems:

copy    
autoCpuFreq.py to
/usr/local/sbin

copy     autoCpuFreqRc to
/usr/init.d/

execute  update-rc.d
autoCpuFreqRc defaults

» Non debian:

since I have no experience on other Linux systems you have to write your own init scripts to autostart daemon.

here is a init-script for gentoo

how it works:

My FSB-vCore pairs are: <100,1.1> <133,1.1> <166,1.25> and <193,1.5>

<100,1.1> - low load: office-apps running.
- at the end of (1) I started avi playback with some heavy-weight filters.
- after some time, where usage was nearly 100% script sets highest pair.
<193,1.5> - CPU has much more power at 193MHz FSB; load is ca. 50%.
since 50% load is smaller then my down-trigger (60%) script chooses next smaller pair.
<166,1.25> - still smaller then 60% => so choose next pair.
<133,1.1> - at this configuration CPU usage is ca. 70%, and since this value lies between both trigger values, system stays here...

If you wish to test the temperature feature, set CPU max-temp. to some small meaningful value, enable debug-out, run script manually and then run a heavy-load test application e.g. mprime, after the temperature gets over the max-value system should change to next small pair, and so on ...

:: autoCpuFreq ::