Es ist also dringend an der Zeit sich um das Gerät zu kümmern: Mit einem neuen Lüfter ist endlich wieder Ruhe im Karton. Ein neuer Akku sorgt wieder für 2 Stunden Strom und mit den richtigen Settings hält der Akku sogar knapp an die 3:30 Stunden. Es lohnt sich also ein wenig Zeit in Intels Stromspar-Analyse-Tool Powertop zu investieren. Dabei müsst ihr nicht gleich den Akku tauschen, auch Nutzer eines neuen Laptops profitieren von den durch Powertop empfohlenen Stromsparmaßnahmen.

Generell möchte ich hier jetzt keine große Umbauanleitung geben, da ihr speziell beim Dell Vostro vor keinen großen Problemen steht. Neue zum Vostro V130 kompatible Lüfter gibt es bei Ebay für weniger als 17 Euro und auch neue Akkus kosten nur knapp um die 50 Euro. Für wenig mehr als 65 Euro lässt sich das Notebook somit fast komplett generalüberholen. Bei meinen Bestellungen kam der Lüfter per Luftpost direkt aus China — ohne dass der Zoll sich über die Sendung mokierte. Der Akku wurde dagegen direkt aus Deutschland ausgeliefert.

Neuer Lüfter und Akku

Der Aufwand beim Umbau hält sich beim Vostro V130 in Grenzen: Mit einem konventionellen kleinen Phillips-Schraubendreher aka Kreuzschlitzschraubenzieher lassen sich sämtliche Schrauben auf der Rückseite und die zwei auf der schwarzen Hinterseite herausdrehen. Danach gilt es nur noch die Blende für den SD-Kartenslot rauszunehmen und den Rückendeckel zur Vorderseite hin abzuziehen. Lüfter und Akku lassen sich dann ebenso problemlos austauschen wie das Gerät öffnen, es müssen wieder nur ein paar simple Schrauben gelöst werden.

Direkt nach dem Umbau läuft der Lüfter wieder seidenweich und auch die Akkulaufzeit kann sich mit 2 Stunden wieder sehen lassen. Allerdings sind diese zwei Stunden beileibe nicht das Ende der Fahnenstange. Mit den richtigen Werkzeugen kitzelt ihr locker 50 Prozent mehr Laufzeit aus eurem Linux-Laptop, ohne dass ihr dabei allzu viel Aufwand treiben oder auf Komfort verzichten müsst. Die Akkulaufzeit meines frisch renovierten Dell Vostro V130 ließ sich von den besagten 2 Stunden auf knapp 3:15 Stunden steigern — es lohnt sich also ein wenig in die Thematik einzusteigen.

Akkulaufzeit mir Powertop optimieren

Die 2 Stunden Akkulaufzeit sind im Gegensatz zu den anfänglichen 20 bis 30 Minuten zwar toll, doch nach wie vor nicht wirklich überragend. Von dem integrierten 30 Wh/2700 mAh großen Akku kann man zwar keine Wunder erwarten, doch Dell spricht von über 4 Stunden Laufzeit und der Test bei Notebookcheck berichtet von einer Laufzeit von etwa 2:30 beim Surfen über WLAN beziehungsweise knapp 4:30 im Leerlauf bei geringster Bildschirmhelligkeit. Von daher ist es an der Zeit sich auch etwas mit dem Optimieren der Akkulaufzeit zu beschäftigen.

Dabei hilft euch das von Intel entwickelte Analysewerkzeug Powertop. Es reduziert selber nicht den Stromverbrauch, stattdessen analysiert Powertop das System bis ins letzte Detail und verrät die größten Stromschlucker abseits des Displays und anderer essentieller Funktionen. Doch damit nicht genug: Powertop spuckt gleich die passenden Kommandos aus, mit denen sich die hungrige Hardware ohne großen Einbußen an Komfort und Leistung bändigen lässt. Mit ein bisschen Geduld, lässt sich so die Akkulaufzeit des Laptops daher unter Linux wesentlich verbessern.

HINWEIS: Als Arch-User habe ich die Aktion natürlich mit Arch Linux durchgeführt. Selbstverständlich funktioniert das Tutorial aber auch mit anderen Linux-Distributionen wie Debian oder Ubuntu — Der größte Unterschied liegt in der Installation der Pakete und der Ausführung des Powertop-Skripts während des Bootvorgangs. Für User mit den erwähnten Distributionen gibt es im Ubuntuusers-Wiki auch eine tolle Anleitung. Ich für meinen Teil konzentriere mich hier an dieser Stelle auf Arch Linux und lasse auch mal Beispiele für Ubuntu aus, da ich den Vorgang eben nur unter Arch getestet habe.

Powertop-Tipps unter Arch Linux umsetzen

Im ersten Schritt müsst ihr Powertop mitsamt dem Ethtool und dem Gnome Power Manger installieren. Der Power Manager ist nicht unbedingt von Nöten, allerdings zeigt er den Verlauf des Ladezustands schön übersichtlich als Graph an und liefert zudem zahlreiche andere Informationen zum Stromverbrauch des Systems unter Linux. Braucht ihr kein optisches Feedback eurer Aktion oder setzt ihr auf eine anderen Desktopumgebung als Gnome, dann lasst den Power Manager einfach weg und erspart euch so eventuell die Installation von zahlreichen Abhängigkeiten, die ihr sonst gar nicht braucht.

$ sudo pacman -S powertop ethtool
$ sudo pacman -S gnome-power-manager

Nun ruft ihr mit sudo powertop das Analysewerkzeug zum ersten mal aus einem Terminal heraus auf. In der Übersicht seht ihr ganz oben die aktuelle Entladungsrate in Watt und die von Powertop geschätzte restliche Akkulaufzeit. Merkt euch besonders die aktuelle Entladungsrate, denn die gilt es zum Verlängern der Akkulaufzeit abzusenken. Wichtig ist auch die Anzahl der Aufwachvorgänge/Sekunde. Je öfter der Prozessor aus dem Tiefschlaf geholt wird, desto weniger Zeit verbringt er im Stromsparmodus. Beobachtet beide Ausgaben mal eine Weile und notiert euch die Werte, ihr zieht sie am Ende der Aktion zum Vergleich heran.

### Powertop im Terminal aufrufen und testen
$ sudo powertop
### Powertop-Report erstellen und im Browser öffnen
$ sudo powertop --html=powertop-report.html
$ xdg-open powertop-report.html

Um im Inhalt der Ausgabe zu scrollen, drückt ihr einfach auf die Pfeiltasten eurer Tastatur. Per Tabulator-Taste wechselt ihr von der Übersicht, zum Leerlauf-Status, der Frequenz- und Gerät-Statistik sowie zu den Abstimmbaren Optionen. Hier ist besonders der letzte Punkt Abstimmbare Optionen von Interesse. Die Tabelle zeigt Rechts Systemeinstellungen, die sich auf den Stromverbrauch auswirken. Linksbündig sagt die Ausgabe „Gut“ oder „Schlecht“, ob der entsprechende Punkt bereits behoben ist. Wählt ihr mit den Pfeiltasten einen der schlechten Punkte an, könnt ihr mit oft mit [Eingabe] die entsprechenden Konfiguration optimieren. Die linke Spalte sollte dabei von Schlecht auf Gut wechseln.

Diese Änderung ist nun aber nicht permanent, sodass es sich an dieser Stelle gar nicht lohnt, weiter manuell einen Eintrag nach dem Anderen zu optimieren. Das ist aber auch gar nicht nötig, denn die Einstellungen lassen sich auch direkt im System vornehmen, sodass Powertop nichts mehr zu meckern hat. Erzeugt euch dazu wie im oberen Listing beschrieben einen Powertop-Report powertop-report.html und öffnet diesen im nächstbesten Browser. Auf der Powertop-Seite tippt ihr dann auf den Reiter Tuning. Er enthält gesammelt alle wichtigen Optionen die Akkulaufzeit zu verlängern.

Die Befehle aus dem PowerTop-Report müsstet ihr nun eigentlich direkt übernehmen können. Doch aber auch das macht einiges an Arbeit. Mit ein bisschen Shell-Magie lassen sich die Aufrufe zu wenigen Kommandos kombinieren, die ihr dann in ein extra Powertop-Skript packt, das ihr am Ende dann beim Start des Systems ausführen lässt. Erstellt dazu mit einem beliebigen Texteditor und Root-Rechten die Datei /usr/local/sbin/powertop.sh und fügt den Inhalt aus folgendem Listing ein.

#!/bin/bash
for i in /sys/class/scsi_host/host[012345]/link_power_management_policy; do echo min_power >$i; done
echo '1500' > '/proc/sys/vm/dirty_writeback_centisecs';
echo '1' > '/sys/module/snd_hda_intel/parameters/power_save';
echo '0' > '/proc/sys/kernel/nmi_watchdog';

## Runtime PM for PCI Device
find /sys/bus/pci/devices/*/power -name control -exec echo auto >{} \;
for i in $(find /sys/devices/pci0000\:00/0* -maxdepth 3 -name control); do
    echo auto > $i;
done
find /sys/bus/pci/devices/*/power -name control -exec echo auto >{} \;
for i in $(find /sys/devices/pci0000\:ff/0* -maxdepth 3 -name control); do
    echo auto > $i;
done

Achtet bitte darauf, dass ihr das Skript mit sehr hoher Wahrscheinlichkeit noch an euer System anpassen müsst. Orientiert euch dabei an den Ausgaben des Powertop-Reports oder an den Tipps des Ubuntuusers-Wiki. Meist werdet ihr in der ersten Zeile die Anzahl der SCSI-Hosts korrigieren („[012345]“), eventuell den Powersave-Modus des Intel-HDA-Soundchips rausnehmen oder auch die das Runtime Power Management anpassen müssen. Am Ende speichert ihr die Datei ab und beendet den Editor. Arbeitet ihr wie hier im Beispiel mit Nano, geschieht dies mit [Strg]+[O], [Eingabe] und [Strg]+[X]. Danach macht ihr das Skript noch mit chmod +x ausführbar, sonst fehlen Systemctl nachher die Rechte das Skript beim Booten zu starten.

$ sudo nano /usr/local/sbin/powertop.sh
$ sudo chmod +x /usr/local/sbin/powertop.sh

Wie schon erwähnt, benutzt Arch Linux Systemd als Init-System. Dieses sorgt unter anderem dafür, dass beim Booten die wichtigsten Prozesse in der richtigen Reihenfolge gestartet werden — an dieser Stelle unterscheidet sich der Vorgang noch von vielen Distributionen, die noch nicht auf Systemd aufbauen. Auch Powertop können wir in dieses System einklinken. Erstellt dafür wieder mit einem Editor und Root-Rechten die Datei /etc/systemd/system/powertop.service und fügt den folgenden Inhalt ein. Diesen müsst ihr dieses mal nicht anpassen. Die Datei sorgt dafür, Systemd das von euch erstellte Powertop-Skript beim Booten ausführen wird.

[Unit]
Description="PowerTop Tuning"
ConditionPathExists=/usr/local/sbin/powertop.sh

[Service]
Type=oneshot
RemainAfterExit=yes
KillMode=none
ExecStart=/usr/local/sbin/powertop.sh
ExecStop=exit

[Install]
WantedBy=multi-user.target

Nun könnt ihr eure Powertop-Optimierungen testen… ob ihr wirklich richtig steht, seht ihr wenn das Licht angeht. Ruft dazu mit systemctl start den powertop.service auf, mit systemctl status prüft ihr danach den Erfolg der Aktion nach. Auch ein Blick auf sudo powertop lohnt sich. Dort sollte der Tab Abstimmbare Optionen deutlich weniger mit „Schlecht“ markierte Einträge aufführen. Bei mir bleibt eigentlich nur noch das AutoSuspend für die USB-Geräte und der Wake-On-LAN-Status des im Laptop verbauten Ethernet-Adapters zurück.

$ sudo systemctl start powertop.service
$ systemctl status powertop.service
● powertop.service - "PowerTop Tuning config"
Loaded: loaded (/etc/systemd/system/powertop.service; enabled; vendor preset: disabled)
Active: active (exited) since Di 2015-06-02 12:11:49 CEST; 10min ago
Process: 319 ExecStart=/usr/local/sbin/powertop.sh (code=exited, status=0/SUCCESS)
Main PID: 319 (code=exited, status=0/SUCCESS)
CGroup: /system.slice/powertop.service

Jun 02 12:11:49 estrellita systemd[1]: Starting "PowerTop Tuning"...
Jun 02 12:11:49 estrellita systemd[1]: Started "PowerTop Tuning".
$ sudo powertop

AutoSuspend für USB-Geräte solltet ihr generell vermeiden, da sonst Mäuse und andere USB-Geräte immer wieder aussetzen und um Wake-On-LAN kümmern wir uns im nächsten Schritt getrennt vom Powertop-Skript. Ein Laptop hängt selten per Kabel-Ethernet im Netzwerk und muss auch noch seltener per Wake-on-LAN über das Netzwerk geweckt bzw. gebootet werden. Es macht daher Sinn Wake-on-LAN zu deaktivieren, da die Funktion im Standby und Ruhezustand zusätzlichen Strom verbraucht. Unter Arch gibt es mehrere Wege Wake-on-LAN zu steuern, der einfachste geht über eine simple Udev-Regel, die ihr in Form der Datei /etc/udev/rules.d/70-disable_wol.rules mit folgendem Inhalt anlegt.

ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*", RUN+="/usr/bin/ethtool -s %k wol d"

Funktioniert alles wie gewünscht, dann aktiviert mittels systemctl enable den Powertop-Booteintrag powertop.service und startet euren Rechner anschließend noch einmal neu durch. Habt ihr sauber gearbeitet, dann sollte Powertop kaum mehr einen Task mit „Schlecht“ kennzeichnen. Perfekt läuft es, wenn wirklich nur noch AutoSuspend für eure USB-Geräte als Verbesserungspotential übrig bleibt — diesen Punkt würde ich allerdings wie schon beschrieben nicht korrigieren. Damit solltet ihr nun eurem Linux-Laptop eine deutlich verbesserte Akkulaufzeit verpasst haben.

$ sudo systemctl enable powertop.service
$ sudo reboot

Bei meinem Dell Vostro V130 geht die Entladungsrate im Leerlauf bei aktiviertem WLAN und gleicher Helligkeit des Displays auf 9.10 W bis 9.30 W zurück. Damit verlängert sich im selben Zug auch die Akkulaufzeit von knapp über 2 Stunden auf locker mehr als 3 Stunden — ohne dass ich dabei an Komfort verliere oder irgendwelche Hardware-Komponenten nicht mehr funktionieren. Würde ich WLAN und Bluetooth abschalten sowie die Helligkeit des Displays auf ein erträgliches Minimum reduzieren, wären locker 4 Stunden Akkulaufzeit drinnen. Mehr verspricht Dell für das Gerät auch nicht in den technischen Spezifikationen.

Im Endeffekt ist das Ganze relativ leicht umzusetzen. Erfahrenen Linux-Usern müsste ich nur die Schlagworte hdparm, die Option -S XX und die Konfigurationsdatei hdparm.conf nennen. Wer ausführliche Informationen möchte, der sollte einfach weiterlesen  Erstmal muss man dazu die Daten der Platte herausfinden, die man bei Nichtgebrauch abschalten möchte. Am einfachsten geht dies über die Laufwerksverwaltung von GNOME, die ihr über das Menü unter Einstellungen | System aufrufen könnt. Dort müsstet ihr einfach nur eure Platte raussuchen und euch das entsprechende Gerät /dev/sdXY merken.

In meinem Beispiel arbeite ich also mit der Platte /dev/sdc. Wahrscheinlich handelt es sich bei euch um ein anderes Gerät, von daher müsst ihr die folgenden Hinweise an eure Situation anpassen. Für KDEler gibt es alternativ sicherlich auch in der KDE SC ein entsprechendes Werkzeug, und wenn alle Stricke reißen, hilft auf jeden Fall ein sudo fdisk -l weiter.

Nun überprüft ihr am besten erst einmal, ob sich eure Platte überhaupt in den Leerlauf schicken lässt. Alle halbwegs aktuellen Platten und Controller sollten dazu eigentlich in der Lage sein, aber bevor ihr euch später wundert, warum das nicht funktioniert, solltet ihr erstmal einen kleinen Test machen. Ruft dazu hdparm mit der Option -C auf…

$ sudo hdparm -C /dev/sdc
/dev/sdc:
 drive state is:  active/idle

Man sieht, dass hdparm den Status korrekt abrufen konnte und die Platte läuft – man sollte dies auch an ihrem Betriebsgeräusch erkennen können. Nun könnt ihr die Platte einmal von Hand abschalten…

$ sudo hdparm -y /dev/sdc

…der Erfolg der Aktion sollte hörbar sein. Optional könnt ihr erneut mit der Option -C nachprüfen, ob die Platte auch wirklich in den Standby geschickt werden konnte.

$ sudo hdparm -C /dev/sdc
/dev/sdc:
drive state is:  standby

Sobald ihr wieder auf die Platte zugreift (bspw. über den Dateimanager), wird die Platte wieder automatisch anlaufen und ihre Daten preisgeben. Nun wäre es recht umständlich, die Platte immer von Hand abzuschalten. Besser wäre es, wenn sich die Platte nach einer gewissen Zeit ohne Zugriffe automatisch abstellen könnte.

Dazu gibt es die Option -S XX von hdparm. Über sie könnt ihr eine Zeitspanne definieren, ab der die Platte abgeschaltet wird. Der Zahlenwert hinter dem Schlüssel drückt nicht direkt die Zeit aus, sondern dient nur als Multiplikator. Ich zitiere einfach mal die man-Page…

Values from 1 to 240 specify multiples of 5 seconds, yielding timeouts from 5 seconds to 20 minutes. Values from 241 to 251 specify from 1 to 11 units of 30 minutes, yielding timeouts from 30 minutes to 5.5 hours. A value of 252 signifies a timeout of 21 minutes. A value of 253 sets a vendor-defined timeout period between 8 and 12 hours, and the value 254 is reserved. 255 is interpreted as 21 minutes plus 15 seconds. Note that some older drives may have very different interpretations of these values.

Ein Wert von bspw. 60 entspricht daher 60*5 Sekunden, also 300 Sekunden oder fünf Minuten. Zu kurz sollte man das Timeout nicht wählen, da zu häufiges Runter- und wieder Hochdrehen des Motors die Lebensdauer der Platte beeinträchtigen kann.

$ sudo hdparm -S 60 /dev/sdc

Damit das Ganze automatisch beim Start des Systems ausgeführt wird, solltet ihr diese Einstellung in der Konfigurationsdatei /etc/hdparm.conf speichern. Am besten arbeitet ihr in dem Fall mit UUIDs, sodass sich der Eintrag immer auf die gewünschte Platte bezieht, selbst wenn sich eure Plattenkonfiguration einmal ändern sollte. Bestimmt die UUID über bspw…

$ sudo blkid
[...]
/dev/sdb1: LABEL="data-intern" UUID="ff7f1cdd-431a-4e47-8b90-49737cec82b3" TYPE="ext4"
/dev/sdc1: LABEL="datengrab" UUID="4c9dca33-e3e1-4a6a-a7d4-110cdbb4cfbe" TYPE="ext3"

…und fügt dann einfach euren gewünschten Eintrag an das Ende der hdparm.conf an…

$ sudo gedit /etc/hdparm.conf
[...]
/dev/disk/by-uuid/4c9dca33-e3e1-4a6a-a7d4-110cdbb4cfbe {
	spindown_time = 60
}

…ab dem nächsten Neustart sollte die Einstellung automatisch aktiv sein und eure Platte bei Nichtgebrauch abgeschaltet werden. Abschließend noch der Hinweis, dass ihr beim Arbeiten mit hdparm wirklich euer Hirn einschalten müsst. Bei der „Schlaffunktion“ müsst ihr – wie bereits erwähnt – bedenken, dass zu häufiges Hochdrehen der Platte die Lebensdauer reduzieren kann. Setzt das Intervall daher auf keinen Fall zu kurz. [UPDATE 13.07.2012: Ich habe den Beitrag auf die aktuelle Syntax der hdparm.conf umgestellt, damit dürften einige Rückfragen aus den Kommentaren geklärt sein.]

Dafür braucht Y5 Battery Saver kein ebenso stromfressendes GPS-Signal. Das Programm bestimmt über die Cell ID an welchem Sendemast das Telefon gerade eingebucht ist. Verbindet man sich zu einem WLAN, dann merkt sich Y5 Battery Saver diese Cell ID. In Zukunft wird dann das WLAN immer dann automatisch eingeschaltet, sobald sich das Telefon an diesem Sendemast eingebucht ist. Verlässt man das Empfangsgebiet des Sendemastes, dann wird das WLAN wieder wie von Geisterhand abgeschaltet.

Natürlich ist die Positionsbestimmung über die Cell ID nicht super genau, doch darum geht es ja gar nicht. Meist ist beispielsweise der Arbeitsplatz weit genug von Zuhause entfernt, so dass das WLAN spätestens nach ein paar hundert Metern auf dem Weg zum Arbeitsplatz, zur Uni oder wohin auch immer automatisch deaktiviert wird. Auf meinem alten Samsung Galaxy mit Android 1.5 funktioniert das Programm recht gut und zuverlässig. Und der erzielte Stromspareffekt kann sich durchaus sehen lassen.

Nun baut Ubuntu jedoch seit Jaunty die dafür nötigen Kernel-Module fest in den Kernel ein. Dadurch ist es nicht mehr möglich nur das eine Kernel-Module zu patchen, es muss leider der gesamte Kernel neu kompiliert werden… Vor einigen Monaten habe ich bereits über eine Paketquelle mit einem „PHC-Kernel“ geschrieben, in der Hoffnung dass mit der Quelle die Kernel-Kompiliererei ein Ende hat, doch bislang war ich vom linux-phc Team etwas enttäuscht. Das PPA hat meiner Erinnerung nach, während der bisherigen Lebenszeit von Jaunty gerade mal ein Update erfahren.

Mit Ubuntu Karmic ändert sich das Vorgehen mal wieder etwas. Das PPA enthält nun einen Kernel, der die SpeedStep-Module komplett fehlen, so kann man sich die Kernelmodule selber erzeugen…

PHC-Kernel installieren

Den Anfang macht die Installation des angepassten Kernels, man kann den Kernel sowie die nötigen Bibliotheken und Tools für das Kompilieren des Kernelmoduls via…

$ sudo add-apt-repository ppa:linux-phc/ppa
$ sudo apt-get install build-essential linux-generic-phc linux-headers-generic-phc

…herunterladen und installieren. Nach der Installation startet man am besten den Rechner neu. Beim Booten steht jetzt ein zusätzlicher Kernel, der mit -phc endet, zur Verfügung. Speed-Stepping sollte mit diesem Kernel erstmal nicht funktionieren, wundert Euch also nicht wenn die CPU vorerst immer mit maximaler Taktrate läuft.

Kernelmodule erzeugen

Nun könnt Ihr euch aus dem Forum von linux-phc.org bereits gepatchte Kernelmodule herunterladen. Es gibt zwei Varianten, einmal phc-k8*.tar.gz für AMD X2, AMD Turion64 und AMD Turion X2 Prozessoren und einmal phc-intel*.tar.gz für Intel Mobile Centrino, Atom (N2xx) und Intel Core/Core2 CPUs. Ihr müsst das passende Kernelmodul wählen.

Ich habe hier ein Gerät mit einem alten Intel Centrino, daher führe ich das am Beispiel des gerade aktuellen Moduls phc-intel-0.3.2-8.tar.gz durch… Habt Ihr das Modul heruntergeladen, so müsst Ihr es entpacken und in das entstandene Verzeichnis wechseln…

$ tar -xzf phc-intel*
$ cd phc-intel*

Nun könnt ihr das Modul erzeugen, kompilieren und installieren. Dies könnt Ihr via…

$ make prepare
$ make
$ sudo make install
$ sudo modprobe phc-intel

…durchführen. Solltet ihr Schwierigkeiten dabei haben, so liefert die im Archiv enthaltene README Datei weitere Informationen. Den Erfolg könnt Ihr wieder via…

$ cat /sys/devices/system/cpu/cpu0/cpufreq/phc_controls
16:33 14:33 12:20 10:14 8:6 6:4 

…ausprobieren. Ist das Modul erfolgreich gebaut worden und habt Ihr es via modprobe geladen, dann zeigt die Ausgabe von cat etwas an, falls die Ausgabe nichts bringt, dann hakt es irgendwo. Damit das Kernelmodul von nun an automatisch geladen wird, steckt ihr es in die Datei /etc/modules. Öffnet dazu die Datei in einen Editor mit Root-Rechten…

$ sudo gedit /etc/modules

und fügt die Zeile…

phc-intel

…ein. Speichert die Datei abschließend. Ihr seid damit noch nicht fertig… Ihr müsst noch passende Spannungswerte ermitteln und die Einstellungen permanent in Eurem System verankern. Seit Jaunty hat sich das Vorgehen nicht verändert. Informationen dazu findet Ihr im älteren Artikel PPA für Jaunty mit gepatchtem Kernel zum Undervolten.

Governor ohne PolicyKit-Abfrage ändern

Abschließend noch ein kleiner Tipp, der mit dem Thema hier nicht direkt etwas zu tun hat. In den Kommentaren zu Ubuntu Karmic Koala 9.10 aus meiner Sicht hat Christoph Wickert Hinweise gegeben, wie man auch mit PolicyKit-1 von GNOME aus Karmic die Taktrate bzw. den Governor ohne Passwortabfrage ändern kann. Ich füge dazu alle Benutzer, die den Governor ändern können sollen, in die Gruppe „users“ ein…

$ sudo adduser $USER users

(Kleiner Hinweis: Ihr müsst euch einmal aus und wieder einloggen. Erst dann werden die Gruppenzugehörigkeiten neu eingelesen) Danach könnt Ihr via…

$ sudo gedit /var/lib/polkit-1/localauthority/50-local.d/gnome-cpufreq.pkla

…die nötige Konfigurationsdatei erstellen. Als Inhalt fügt Ihr…

[Allow users to set the CPU frequency]
Identity=unix-group:users
Action=org.gnome.cpufreqselector
ResultAny=no
ResultInactive=no
ResultActive=yes

…ein. Danach könnt Ihr die Taktrate ohne die Eingabe eines Passwortes ändern.

Dies soll über Ultraschall-Signale geschehen, die über von einer Software generiert werden, über die Boxen des Computers abgespielt und von ein Mikrofon aufgenommen werden. Die Signale mit über 20kHz sollen vom menschlichen Ohr nicht wahrnehmbar sein. Für Windows gibt es fertige ausführbare Dateien des Sonar Power Managers, unter Linux muss man sich sonarPM selber kompilieren…

Den Quellcode könnt Ihr von der Homepage herunterladen und anschließend entpacken. In der README findet Ihr dann eigentlich alle nötigen Informationen um sonarPM zu installieren. Ich gebe Euch trotzdem alle Infos Schritt für Schritt, so könnt Ihr auch ohne große Basteleien sonarPM austesten…

$ tar -xzf SonarPM*.tar.gz
$ cd sonar_dist/

Um sonarPM nun kompilieren zu können, braucht ihr folgende Bibliotheken.So wie ich das sehe, müsste es diese Bibliotheken für alle Ubuntu-Versionen und Debian ab Lenny geben.

$ sudo apt-get install portaudio19-dev libxss-dev libwxgtk2.8-dev

Habt Ihr die Bibliotheken installiert, könnt Ihr Euch dran machen sonarPM zu kompilieren. Ihr könnt direkt make ausführen, ein configure-Skript wird nicht benutzt…

$ make sonar_gui
$ make sonar_tui

Da das Programm nicht in der Lage ist für seine Konfigurationsdateien im Home-Verzeichnis einen Ordner anzulegen, müsst Ihr das machen.

$ mkdir ~/.sonarPM

Nun seid Ihr fertig und könnt die GUI von sonarPM via…

$ ./sonar_gui

… starten. Bei diesem ersten Start müsst Ihr die passenden Audio-Geräte auswählen. Unter Ubuntu Karmic funktionierte PulseAudio recht gut. Das Mikrofon habe ich jedoch direkt ausgewählt.

Anschließend startet sonarPM und fängt an Signale auszugeben. Anfangs hört man noch deutlich Signale, die nach und nach verschwinden. Nach rund 30 Sekunden Kalibrierung blieb sonarPM für mein Höhrempfinden (fast) lautlos.

Bei mir klappte das Abschalten des Bildschirmes, allerdings nicht wirklich zuverlässig. Manchmal ging der Bildschirm aus, obwohl ich noch vor dem Rechner saß. Manchmal bleibt er an, obwohl ich nicht am Rechner sitze. Eventuell liegt das am Mikrofon meiner Webcam, das leider einen etwas zu dumpfen Klang liefert. Vielleicht entstehen die leisen Klicks, die ich ab und zu höre, auch durch das schlechte Mikrofon. Auch scheinen die Boxen mancher Laptops zu limitiert zu sein. Oft können die Brüllwürfel billiger Laptops die nötigen 20kHz nicht liefern. sonarPM eignet sich daher eher zum rumspielen und ausprobieren, am besten ist sowieso der schnelle Griff zum Ein-/Aus Schalter des Monitors.

Dazu gibt es in GNOME das CPU Frequency Applet, das den Benutzer durch die Option „Powersave“ schnell dazu verleitet diese Einstellung im mobilen Betrieb zu verwenden. Öfters liest man Support-Anfragen in dieser Art…

Ich würde gerne mein Ubuntu 9.04, das auf einem Notebook läuft, so konfigurieren, dass es die CPU-Policy auf „Powersave“ stellt, wenn es per Akku betrieben wird und auf „OnDemand“ schaltet, wenn es an der Steckdose hängt.

Wie Eingangs angesprochen ist die Taktrate der CPU nur ein kleines Zahnrad im Räderwerk des Energiemanagements einer CPU. Viel wichtiger sind die Schlafmodi der CPU, in die ein Prozessor jedoch nur fallen kann, wenn es nichts mehr zu tun gibt. Im Normalfall (d.h. „normaler“ Betrieb: Keine Spiele, keine andauernden Berechnungen) spart man mit „Powersave“ KEINE Energie. Auch wenn diese Option fälschlicherweise „Powersave“ heißt, der Akku geht damit eher schneller zur neige.

Ich zitiere mal Making sure we do power management the right way von Matthew Garrett. Matthew ist ein Angestellter von Canonical und dort unter Anderem für den Kernel zuständig.

Weitere Informationen und ein anschauliches Beispiel gibt Arjan van de Ven, der Kopf eines Teams bei Intel, das sich um Power Management und die Performance von Linux auf Intel Hardware kümmert.

Will heißen, je schneller die CPU wieder in Tiefschlaf fallen kann, desto mehr Energie wird sie sparen. Indem man sie nun zwingt immer mit niedrigster CPU-Rate zu laufen, verhindert man dass sie möglichst schnell wieder Einschlafen kann. Mit Powersave spart man nur dann Energie, wenn die CPU sowieso bei jeder Taktrate voll ausgelastet wäre (also bspw. bei 3D-Spielen oder Berechnungen). Im normalen Betrieb, egal ob Akku oder Netz, sollte man OnDemand benutzen um Energie zu sparen.

Ich persönlich benutze Powersave um den Lärm, den der Lüfter meines Laptops macht, zu kontrollieren. Arbeitet man mit Anderen in einer leisen Umgebung, so ist ein permanent hochdrehender Lüfter doch arg nervig. Weitere interessante Ideen bzgl. Energiesparen bei Computern im Allgemeinen und Laptops im Speziellen findet man auf thinkpad-wiki.org unter Linux Stromsparen und Vista Stromverbrauch senken.

[UPDATE 30.05.09: Seit Ubuntu „Jaunty Jackalope“ 9.04 hat sich das Verfahren geändert. Man kann nicht mehr so einfach das Kernelmodul ändern. Informationen hierzu findet man unter PPA für Jaunty mit gepatchtem Kernel zum Undervolten hier in meinem Blog.] Für den Ubuntu-Kernel benötigt man den Linux-PHC Patch, der das Ändern der Spannungswerte durch Schreiben in eine Systemdatei erlaubt. Dabei wird lediglich das für die CPU-Steuerung zuständige Kernel-Modul (eine Datei) verändert. Informationen dazu findet man im Wiki von ubuntuusers.de. Das Vorgehen ist unabhängig von der eigenen Hardware.

Hat man den Patch eingespielt muss man nun für jede Taktstufe der CPU die Spannung individuell anpassen. Die Spannung sollte so weit wie möglich gesenkt werden. Senkt man sie jedoch zu weit ab, so hängt sich der Rechner auf. Leider muss man zum Teil recht lange probieren, bis man brauchbare Werte findet. Um anderen die Arbeit zu ersparen veröffentliche hier die Daten für „mein“ FSC Lifebook S-6120. Am einfachsten realisiert man die Absenkung der CPU-Spannung über ein init-Skript, so wird die Spannung automatisch beim Booten abgesenkt. Die Skripte habe ich bereits vorbereitet.

$ sudo mkdir /etc/phc-config/
$ sudo wget http://linuxundich.de/static/undervolt.config -o /etc/phc-config/undervolt
$ sudo wget http://linuxundich.de/static/undervolt.init -o /etc/init.d/undervolt
$ sudo chmod +x /etc/init.d/undervolt
$ sudo update-rc.d undervolt defaults

Dies lädt das Skript /etc/phc-config/undervolt sowie die Konfigurationsdatei /etc/phc-config/undervolt herunter und verlinkt das Skript in den Runleveln. Von nun an wird die Prozessorspannung automatisch abgesenkt. Sollte es nun zu Abstürzen kommen, so muss die Prozessorspannung wieder angehoben werden. Dazu muss man die /etc/phc-config/undervolt bearbeiten und die Wert erhöhen. Informationen dazu findet man wieder im Wiki von ubuntuusers.de.

CUSTOM_VTABLE="33 33 20 14 6 4"

$ xset dpms force off

Dazu legt man den Starter mittels Rechtsklick auf ein Panel und Zum Panel hinzufügen | Benutzerdefinierter Anwendungsstarter an, gibt als Befehl das Kommando von oben an und nutzt als Icon beispielsweise /usr/share/icons/gnome/32x32/apps/xscreensaver.png Von nun an kann man mit einem Klick den Bildschirm komplett abschalten.