Most if not all of the undervolting, underclocking, and monitoring software tools used by SPCRers are for Windows. What equivalent tools are available in GNU/Linux? I am aware of lm_sensors but that is all. Are there any tools to undervolt and underclock other than through the BIOS?

Someone posted a link to http://www.linuxpowertop.org/index.php this tool just a couple weeks ago on this forum, can't remember who.

Now even though you know about sensors, I'll tell this anyway so that anyone else drawn in by the topic would see it.

Running "apt-cache search --names-only sensor" on my debian box lists


So basically there's this libsensors library which can read sensors, and then there are many different user interface frontends that use that library. The actual sensor hardware is supported by configuring and compiling your kernel to support the devices that are on your mobo, or just having lots of modules and letting sensors-detect tell you what you need to load to see them.

Having support for ACPI on newer systems and APM on older systems configured in your kernel enables some basic power management.

There are speed governors, also configured in the kernel, that represent different kinds of dynamic voltage/frequency management profiles.

It's all pretty much just configuring and compiling your own kernel, preferably as recent version as possible, to enable all kinds of power management stuff, that can then be configured through the standard ways any drivers usually are.

Good keywords for searches are cpufreq and governor. I hope someone is able to give much more exact information.

There is the cpu frequency selector applet (/usr/bin/cpufreq-selector) which
will enable you to choose a governor (conservative, on demand, etc.) or
you can lock in a specific speed. This is all from the ACPI info retrieved
from the BIOS, pretty much. No recompiling required.

Undervolting lower than the standard voltage for a given frequency will
require patching and recompiling the appropriate kernel module (different
ones for various Intel and AMD processor families). I've undervolted
my Merom (T7400), can't speak for AMD processors, but it required
downloading kernel source, applying a third-party patch to a module,
and then because the patch doesn't support Core / Core 2 Duo, adding
a couple of tables myself (straightforward C programming, once you suss out the structure).

Some links on work done with Intel processors, if you want to pursue this further:

http://ubuntuforums.org/showthread.php?p=2428463
https://wiki.ubuntu.com/UndervoltingHowto
http://gentoo-wiki.com/HOWTO_Undervolt_a_Pentium_M_CPU#Finding_the_best_voltage_settings

Oh, BTW, once lm_sensors is set up, the utility gkrellm is great for
displaying your temps, voltages, fan rpm, etc.

Additionally, KDE users can use KSysguard. Both KSysguard and gkrellm need to have lm_sensors fully operational before adding sensor display options. I just got done playing with that about a week ago.

BTW, yesterday I stumbled across mprime, the GNU/Linux equivalent to Prime95. Command line only, but serves the purpose of maxing the CPU for various tests.


I did some surfing into the topic. Undervolting is not yet supported for AMD chips, but there is the powernow daemon project. The developer interest seems to exist to get these concepts into the mainstream, so perhaps a year from now SPCRers who use GNU/Linux will have the same batch of tools to tweak motherboards.

Mainstream would be great. A hacked module means you have to go through
a re-implementation of one's hack each time your distro sends you a
new kernel. So far I've had to do only one re-implement , but it is a pain.

The 2 applets below come with standard with Ubuntu Linux (no kernel compilation required.)

Gnome Frequency Applet (cpu speed/policy control):


Gnome Sensors applet configuration:

For a kernel patch for AMD k8 undervolting look at this thread:
http://forums.gentoo.org/viewtopic-t-245197.html

Also take a look at linux-phc https://www.dedigentoo.org/trac/linux-phc, a kernel patch project for undervolting. Currently it only supports intel processors, but amd support is planned.

Last is a userspace utility that does not need kernel compiling, cpupw: http://www.tuxamito.com.es/cpupw/index.php
Unfortunately for me it did not work but you could give it a try.

I like the way Ubuntu is evolving. I have yet to test that distro, but the focus seems to be on end-users, not developers. The more that distros like Ubuntu evolve to provide GUI front-ends to the same types of tools Windows users expect as normal, the more that will create pressure for other distro maintainers to follow. I hope!

Based upon what bogus posted, I found the following:

kima
kpowersave

Looks like development is active too.

I agree ! Linux biggest weakness is too many GUI's, no standard one and its diversity actually. And that almost for everything "advanced " you need to use CLI. Now I know that CLI is MUCH more powerfull thag GUI but memorizing hundreds of comands....bull****....

I agree. I accept that there always will be design differences between the three major desktops (KDE, GNOME, Xfce), but many features should be shared. The Free Desktop effort is one step in that direction.

I also think all developers need to rethink how they develop software. I believe the underlying structure of a program should be portable so that the desktop people can merely adapt the software to their desktops. I think this probably is already doable, but the NIH (Not Invented Here) Syndrome usually takes effect and what might be a good program in one desktop never sees the light of day in another desktop. Desktops always will be subjective to individual end-users, but there is little reason why they all can't have access to the same programs.

Getting back on topic . . . the gnome-sensors applet and the cpufreq scaling monitor work quite nicely, as long as you have the proper support in lm_sensors. Sometime in the last few months fan speed control for my chip was added to the in-kernel driver, so if I actually had my CPU fan plugged into the motherboard header, I could control it from the desktop.

As it is, I don't bother; I use a Silverstone FP33B. Sensor readings are working just fine though; I have the full range of CPU/mobo/GPU temperatures, CPU/mobo/RAM voltage, CPU frequency control, and the like. As far as undervolting goes, I don't know what all the hubbub is about dynamic/on-demand CPU undervolting. I just set it in BIOS when I first built my box late last year and left it. It's at a little over 1.025V, iirc. It shouldn't ever need to be adjusted, unlike CPU frequency stepping.

I think the applet is good enough that whatever commands you'd run from the CLI can be done via gnome-sensors, with the exception of monitoring HDD temps. For some reason even though it's compiled against hddtemp, the applet isn't picking up my hard disks at all. Prolly they're not in the hddtemp database.