Linux Projektvorstellung: TLP – Linux Stromsparen

Linux Betriebssystem
linrunner

linrunner

Ubuntuversteher
Themenstarter
Registriert
22 Juni 2007
Beiträge
13.276
Nachdem im Forum öfters nachgefragt wird, wie man Linux die Feinheiten des Stromsparens beibringt, habe ich mich vor einiger Zeit entschlossen, meine Skriptsammlung in eine allgemein benutzbare Form zu bringen. Das Ergebnis möchte ich Euch an dieser Stelle vorstellen.

Dokumentation ist auf der offiziellen Website https://linrunner.de/tlp/ zu finden (die Infos in unserem Wiki werden von mir nicht mehr gepflegt und sind veraltet).

Fragen und Probleme einfach hier im Thread posten.

Für die erste Analyse benötige ich bitte stets den kompletten Output von
Code: 
sudo tlp-stat
Anmerkung: ich fordere oft in der weiteren Analyse Teilausgaben an - das sollt ihr jedoch nicht selbstständig tun! Immer zuerst die vollständige Ausgabe.

Bitte auch die FAQ beachten!

Rückmeldungen der Art "alles funktioniert" sind natürlich auch gern gesehen ... :cool:
 
Zuletzt bearbeitet:
Hi,
danke für den Reminder, hatte es noch gar nicht mitbekommen... ich bin schau mir die Sache gleich mal an...
Viele Grüße!
 
Good News: TLP funktioniert auch nach dem Update von glibc problemlos!

Vorerst empfehle ich folgende Vorgehensweise:
- TLP deinstallieren:
Code: 
pacman -Rs tlp
- glibc updaten:
Code: 
pacman -Syu
- TLP wieder installieren:
Code: 
pacman -S tlp

Grund für diese Unannehmlichkeit ist, das TLP Dateien in /lib hinterlegt. Teil es glibc-updates ist es, /lib zu löschen und durch einen symlink nach /usr/lib zu ersetzen. Wenn TLP deinstalliert ist, dann klappt das glibc update. Anschließend kann TLP über den symlink neu installiert werden. Alles funktioniert problemlos und euer config-file /etc/default/tlp bleibt als /etc/default/tlp.pacsave erhalten und kann anschließend über
Code: 
mv /etc/default/tlp.pacsave /etc/default/tlp
wiederhergestellt werden!

Randnotiz: andere Projekte wie openafs und tp_smapi blockieren das glibc update auch, da hilft ebenso nur deinstallieren, update, installieren...

Viele Grüße!
 
Zuletzt bearbeitet:
Servus,

ich habe unter Fedora 17 x64 mit dem neuesten Kernel 3.4.4.5 bei installierten tlp beim booten Kernel-Panics. Bei 3.3.4.5 geht alles normal.
Hardware ist ein T400. Hat jemand eine Idee, bzw. welche Logs werden benötigt.

Tlp-Conf:
Code: 
--- TLP 0.3.6 --------------------------------------------

+++ Configured Settings: /etc/default/tlp
TLP_ENABLE=1
DISK_IDLE_SECS_ON_AC=0
DISK_IDLE_SECS_ON_BAT=2
MAX_LOST_WORK_SECS_ON_AC=15
MAX_LOST_WORK_SECS_ON_BAT=60
SCHED_POWERSAVE_ON_AC=0
SCHED_POWERSAVE_ON_BAT=1
NMI_WATCHDOG=0
DISK_DEVICES="sda sdb"
DISK_APM_LEVEL_ON_AC="254 254"
DISK_APM_LEVEL_ON_BAT="128 128"
DISK_IOSCHED="noop cfq"
SATA_LINKPWR_ON_AC=max_performance
SATA_LINKPWR_ON_BAT=min_power
RADEON_POWER_PROFILE_ON_AC=high
RADEON_POWER_PROFILE_ON_BAT=low
WIFI_PWR_ON_AC=1
WIFI_PWR_ON_BAT=5
WOL_DISABLE=Y
SOUND_POWER_SAVE=1
SOUND_POWER_SAVE_CONTROLLER=Y
BAY_POWEROFF_ON_BAT=0
BAY_DEVICE="sr0"
RUNTIME_PM_ON_AC=on
RUNTIME_PM_ON_BAT=auto
USB_AUTOSUSPEND=1
RESTORE_DEVICE_STATE_ON_STARTUP=0
DEVICES_TO_DISABLE_ON_STARTUP="bluetooth wwan"
DEVICES_TO_DISABLE_ON_LAN_CONNECT="wifi wwan"
DEVICES_TO_DISABLE_ON_WIFI_CONNECT="wwan"
DEVICES_TO_ENABLE_ON_LAN_DISCONNECT="wifi"
DEVICES_TO_ENABLE_ON_UNDOCK="wifi"


+++ System Info
System = LENOVO ThinkPad T400 2767WC8
BIOS = 7UET91WW (3.21 )
Release = "Fedora release 17 (Beefy Miracle)"
Kernel = 3.3.4-5.fc17.x86_64 x86_64
/proc/cmdline = BOOT_IMAGE=/vmlinuz-3.3.4-5.fc17.x86_64 root=UUID=1f3180fe-98ed-4d5b-b7d6-cf4358a4faee ro rd.md=0 rd.lvm=0 rd.dm=0 SYSFONT=True rd.luks=0 KEYTABLE=de-latin1-nodeadkeys LANG=en_US.UTF-8 rhgb quiet pcie_aspm=force i915.i915_enable_rc6=1


+++ System Status
TLP power save = enabled
power source = ac


+++ Processor
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor = ondemand
/sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq =   800000 [kHz]
/sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq =  2267000 [kHz]
/sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies =  2267000 2266000 1600000  800000 [kHz]


/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor = ondemand
/sys/devices/system/cpu/cpu1/cpufreq/scaling_min_freq =   800000 [kHz]
/sys/devices/system/cpu/cpu1/cpufreq/scaling_max_freq =  2267000 [kHz]
/sys/devices/system/cpu/cpu1/cpufreq/scaling_available_frequencies =  2267000 2266000 1600000  800000 [kHz]


/sys/devices/system/cpu/sched_mc_power_savings = 0
/proc/sys/kernel/nmi_watchdog = 0


+++ Undervolting
PHC kernel not available.


+++ ThinkPad Temperatures
/proc/acpi/ibm/thermal = temperatures:	38 50 33 -1 50 -128 28 -128 37 47 36 -128 -128 -128 -128 -128
/proc/acpi/ibm/fan     = speed:         2912


+++ File System
/proc/sys/vm/laptop_mode = 0
/proc/sys/vm/dirty_writeback_centisecs = 1500
/proc/sys/vm/dirty_expire_centisecs = 1500
/proc/sys/vm/dirty_ratio = 60
/proc/sys/vm/dirty_background_ratio = 1
/proc/sys/fs/xfs/age_buffer_centisecs = (not available)
/proc/sys/fs/xfs/xfssyncd_centisecs = (not available)
/proc/sys/fs/xfs/xfsbufd_centisecs = (not available)


+++ Storage Devices
/dev/sda:
          Model     = OCZ-VERTEX2                             
          Firmware  = 1.37    
          APM Level = none/disabled
          scheduler = noop


        SMART info:
            9 Power_On_Hours_and_Msec   =     2657 [h]
          194 Temperature_Celsius       =       30 (Min/Max 30/30)  [°C]


/dev/sdb:
          Model     = ST95005620AS                            
          Firmware  = SD23    
          APM Level = 254
          scheduler = cfq


        SMART info:
            4 Start_Stop_Count          =    18862 
            5 Reallocated_Sector_Ct     =        0 
            9 Power_On_Hours            =     4312 [h]
          190 Airflow_Temperature_Cel   =       39 [°C]
          193 Load_Cycle_Count          =    18905 
          194 Temperature_Celsius       =       39 (0 12 0 [°C]




+++ SATA Aggressive Link Power Management
/sys/class/scsi_host/host0/link_power_management_policy = max_performance
/sys/class/scsi_host/host1/link_power_management_policy = max_performance
/sys/class/scsi_host/host2/link_power_management_policy = max_performance
/sys/class/scsi_host/host3/link_power_management_policy = max_performance


+++ PCIe Active State Power Management
/sys/module/pcie_aspm/parameters/policy = performance


+++ Intel Graphics
/sys/module/i915/parameters/powersave = 1
/sys/module/i915/parameters/i915_enable_rc6 = 1
/sys/module/i915/parameters/i915_enable_fbc = -1
/sys/module/i915/parameters/lvds_downclock = 0
/sys/module/i915/parameters/semaphores = -1


+++ Wireless
bluetooth = off (software)
wifi      = on
wwan      = off (software)


wlan0(iwlwifi): power management = off


+++ Audio
/sys/module/snd_hda_intel/parameters/power_save = 1
/sys/module/snd_hda_intel/parameters/power_save_controller = Y


+++ Battery
ThinkPad extended battery info not available (missing tp_smapi kernel module).
/sys/class/power_supply/BAT0/manufacturer = Panasonic
/sys/class/power_supply/BAT0/model_name = 42T4532
/sys/class/power_supply/BAT0/cycle_count = 0
/sys/class/power_supply/BAT0/energy_full_design = 84240 [mWh]
/sys/class/power_supply/BAT0/energy_full = 76920 [mWh]
/sys/class/power_supply/BAT0/energy_now = 72190 [mWh]
/sys/class/power_supply/BAT0/power_now = 7014 [mW]
/sys/class/power_supply/BAT0/status = Charging


+++ Runtime Power Management
/sys/bus/pci/devices/0000:00:00.0/power/control = on [Host]
/sys/bus/pci/devices/0000:00:19.0/power/control = on [Ethernet]
/sys/bus/pci/devices/0000:00:1b.0/power/control = on [Audio]
/sys/bus/pci/devices/0000:03:00.0/power/control = on [Wireless]
/sys/bus/pci/devices/0000:15:00.1/power/control = on [Firewire]
/sys/bus/pci/devices/0000:15:00.2/power/control = on [SD]
/sys/bus/pci/devices/0000:15:00.4/power/control = on [Card]
/sys/bus/pci/devices/0000:15:00.5/power/control = on [Card]


+++ USB
tlp usb autosuspend = enabled
tlp usb blacklist = (not configured)


Bus 001 Device 001 ID 1d6b:0002 control = auto, autosuspend_delay_ms =  2000 -- Linux Foundation 2.0 root hub (hub)
Bus 002 Device 001 ID 1d6b:0002 control = auto, autosuspend_delay_ms =  2000 -- Linux Foundation 2.0 root hub (hub)
Bus 003 Device 001 ID 1d6b:0001 control = auto, autosuspend_delay_ms =  2000 -- Linux Foundation 1.1 root hub (hub)
Bus 004 Device 001 ID 1d6b:0001 control = auto, autosuspend_delay_ms =  2000 -- Linux Foundation 1.1 root hub (hub)
Bus 005 Device 001 ID 1d6b:0001 control = auto, autosuspend_delay_ms =  2000 -- Linux Foundation 1.1 root hub (hub)
Bus 006 Device 001 ID 1d6b:0001 control = auto, autosuspend_delay_ms =  2000 -- Linux Foundation 1.1 root hub (hub)
Bus 007 Device 001 ID 1d6b:0001 control = auto, autosuspend_delay_ms =  2000 -- Linux Foundation 1.1 root hub (hub)
Bus 008 Device 001 ID 1d6b:0001 control = auto, autosuspend_delay_ms =  2000 -- Linux Foundation 1.1 root hub (hub)
Bus 009 Device 001 ID 1d6b:0002 control = auto, autosuspend_delay_ms =  2000 -- Linux Foundation 2.0 root hub (hub)
Bus 010 Device 001 ID 1d6b:0003 control = auto, autosuspend_delay_ms =  2000 -- Linux Foundation 3.0 root hub (hub)
Bus 001 Device 002 ID 17ef:1004 control = auto, autosuspend_delay_ms =  2000 -- Lenovo Integrated Webcam (uvcvideo)
Bus 001 Device 004 ID 05ac:1290 control = auto, autosuspend_delay_ms =  2000 -- Apple, Inc. iPhone (usbfs, ipheth)
 
@MasterMito: eine Kernel Panic ist mE immer ein Bug im Kernel, denn der Kernel muß im Zweifel jeden Unfug abkönnen den das Userland veranstaltet. Du solltest also bei Fedora einen Bugreport eröffnen.

Um eine Umgehungslösung zu finden, müsstest Du alle Einstellungen von TLP durchprobieren.

Ich würde zuerst testen ob, es nur an Netzteil oder Akku auftritt. Falls ja, kannst Du dir die Einstellungen vornehmen die nach AC/BAT unterscheiden und einzeln auf den Wert der Stromquelle setzen wo das Problem nicht auftritt. Tritt das Problem bei beiden Stromquellen auf, dann die anderen Einstellungen ausschalten.

Hier gibt es übrigens einen ähnlichen Fall: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/952310/

ps. über den 3.4er lese ich hier in letzter Zeit hauptsächlich Schlechtes ... :(
 
Zuletzt bearbeitet:
Moin Moin

@MasterMito
Update ist in der Pipeline. Das müsste das Problem beheben. Kommt die Tage.

@linrunner
Ich tippe nicht auf einen Kernelbug. Das dürfte noch das Problem mit dem upower sein.

RomanX
 
Moin Moin

Das Update für Fedora 16 und Fedora 17 ist fertig.
Versionsnummer ist 0.3.6-6.fc17
Das Paket entspricht der Testversion (0.3.6-5.1.fc17).

Für diejenigen, die ein Problem haben, hilft ein:
Code: 
yum makecache
yum update
damit yum das update sofort findet.

Alle anderen können einfach einen Tag abwarten.

RomanX
 
Der Patch funktioniert astrein. Danke RomanX!!

Was haste den genau angepasst (als ewiger Neugieriger)?
 
Er hat das Kommando zum Starten des upowerd aus dem Systemstartskript entfernt.

Schön dass es gelöst ist. Ich werde das trotzdem weiter als Kernelbug ansehen :D.
 
http://www.aselabs.com/news.php?id=33877&asesessid=832adb513b439e4ed57b41724700d3c34e370085
"SuperMUC is many times more efficient than its predecessor. Where it makes sense we use frequency scaling, a Linux kernel function delivered with SUSE Linux Enterprise, which allows us to run applications at their optimal operating point. This means we use, wherever possible, newly developed energy efficiency mechanisms in Linux," said Dr. Herbert Huber, head of high-performance systems at the LRZ.
Zum Vergrößern anklicken....
Er meint doch wohl nicht etwa TLP? ;)
 
Moin,

erstmal: Vielen Dank für die Software! Ich habe eine Frage dazu. Vorweg die Eckdaten: Ich nutze ein X200s mit Ubuntu 12.04, tlp 0.3.6-2~precise, habe im regelmäßigem Wechsel einen 56Wh-6-Zeller und einen 94Wh-9-Zeller im Einsatz und benutze außerdem eine Ultrabase.

Wenn ich es richtig verstanden habe, dann schreibt TLP die Ladeschwellen direkt in die Akkuelektronik. Dazu passt, dass mein Rechner in der Ultrabase steckend auch ausgeschaltet nicht über die gesetzte Ladeschwelle hinaus lädt bzw. dass ich ihn mit einer Live-CD starten kann, ohne dass der Akku etwa auf 100% geladen werden würde.

Wenn ich nun aber einen Akku von außen an den Ladeport der Ultrabase zum Laden hänge, wird der Akku gnadenlos auf 100% geladen. Wenn ich den geladenen Akku dann wieder in den Laptop stecke, entlade, und dann samt Laptop auf die Ultrabase lege, lädt der Akku gar nicht mehr. cat /proc/acpi/battery/BAT0/state gibt dann "charged" aus, unabhängig vom absoluten Ladezustand. Erst mit sudo tlp setcharge kann ich den Akku wieder zum Laden bewegen.

Kann es sein, dass der externe Port der Ultrabase gnadenlos alle Einstellungen mit irgendeinem Unsinn überschreibt?
 
Moin

Die Ladeschwellen werden nicht in der Akkuelektronik gespeichert. Es existiert auch nur 1 Datensatz (pro Akkuport) für die Ladeschwellen.
Sobald Du den Akku entnimmst, werden die Ladeschwellen gelöscht und müssen neu gesetzt werden.

Was sagt denn tlp-stat (der Teil mit den Battery-Stats), wenn Du den in der Ultrabase geladenen Akku wieder in den Laptop einsetzt?

Für tlp gibt es noch keine Lösung, das nach einem Akkuwechsel automatisch zu machen.

RomanX
 
Danke für die Antworten. Die Ausgabe liefere ich voraussichtlich morgen nach.
 
So, es hat etwas gedauert, weil ich das Phänomen nicht reproduzieren konnte. Heute ist es wieder aufgetreten, allerdings mit einer anderen Vorgehensweise: Ich hatte das Thinkpad samt 6-Zeller für längere Zeit in der Ultrabase liegen. Der Ladestand entsprach der eingestellten Ladeschwelle. Gestern habe ich es dann entnommen und den Akku genutzt. Später habe ich ihn dann auf Standby gesetzt und dann in die Ultrabay zum Laden gelegt. Als ich heute aufwecke, empfängt mich der Akku mit einem Ladestand von 44,6%.

Code: 
sudo tlp-stat -b

Code: 
+++ ThinkPad Battery (Main)
/sys/devices/platform/smapi/BAT0/manufacturer = LGC
/sys/devices/platform/smapi/BAT0/model = 42T4648
/sys/devices/platform/smapi/BAT0/manufacture_date = 2009-11-21
/sys/devices/platform/smapi/BAT0/first_use_date = 2010-03-26
/sys/devices/platform/smapi/BAT0/cycle_count = 35
/sys/devices/platform/smapi/BAT0/design_capacity = 56160 [mWh]
/sys/devices/platform/smapi/BAT0/last_full_capacity = 56630 [mWh]
/sys/devices/platform/smapi/BAT0/remaining_capacity = 25440 [mWh]
/sys/devices/platform/smapi/BAT0/remaining_percent = 45 [%]
/sys/devices/platform/smapi/BAT0/remaining_running_time_now = not_discharging [min]
/sys/devices/platform/smapi/BAT0/remaining_charging_time = not_charging [min]
/sys/devices/platform/smapi/BAT0/force_discharge = 0
/sys/devices/platform/smapi/BAT0/power_now = 0 [mW]

/sys/devices/platform/smapi/BAT0/start_charge_thresh = 75 [%]
/sys/devices/platform/smapi/BAT0/stop_charge_thresh = 85 [%]

Komisch, nicht?
 
In den Ausgaben ist nichts auffälliges zu erkennen. Das Symptom, dass das X200 beim Andocken im Suspend-Status nicht anfängt zu laden, kenne ich von meinem. Ist aber nicht immer.

Was Du beschreibst sind mE allesamt Bugs in der Firmware des EC (Embedded Controller). Ich kann da mit TLP nichts dran tun. Ist das BIOS aktuell?
 
Mal ne Frage halb abseits von TLP: Ich dachte immer, wenn man Hauptakku und Ultrabayakku drin hat, wird immer zuerst der teure Ultrabayakku leergelutscht? Und, auch wenn man das möchte (->TLP), es gibt keine Möglichkeit außer Akkuentfernung, um das zu verhindern?

Mir ist gestern schon aufgefallen, dass nach meinen 2 Tagen Abwesenheit vom Netzteil (hauptsächlich Sleepmode) größtenteils der Hauptakku belastet wurde. Über Nacht hab ich beide leersaugen lassen und vorhin vollgeladen, da mir komische Werte bezüglich max. Ladung absolut und prozentual ausgegeben wurden. Nebenbei wollte ich noch wissen, ob der neugekaufte uralt-Akku irgendwelche Schwächen zeigt - aber der ist besser als der damals fast fabrikfrische Neunzeller. Danach Stecker wieder raus, laufen lassen - als ich eben wieder dran dachte, sah es so aus:

Code: 
+++ ThinkPad Battery (Main)
/sys/devices/platform/smapi/BAT0/manufacturer = SANYO
/sys/devices/platform/smapi/BAT0/model = 42T4644
/sys/devices/platform/smapi/BAT0/manufacture_date = 2011-03-30
/sys/devices/platform/smapi/BAT0/first_use_date = 2011-08-01
/sys/devices/platform/smapi/BAT0/cycle_count = 22
/sys/devices/platform/smapi/BAT0/design_capacity = 84240 [mWh]
/sys/devices/platform/smapi/BAT0/last_full_capacity = 81230 [mWh]
/sys/devices/platform/smapi/BAT0/remaining_capacity = 69810 [mWh]
/sys/devices/platform/smapi/BAT0/remaining_percent = 86 [%]
/sys/devices/platform/smapi/BAT0/remaining_running_time_now = 303 [min]
/sys/devices/platform/smapi/BAT0/remaining_charging_time = not_charging [min]
/sys/devices/platform/smapi/BAT0/force_discharge = 0
/sys/devices/platform/smapi/BAT0/power_now = -13831 [mW]

/sys/devices/platform/smapi/BAT0/start_charge_thresh = 80 [%]
/sys/devices/platform/smapi/BAT0/stop_charge_thresh = 90 [%]

+++ ThinkPad Battery (Ultrabay/Slice)
/sys/devices/platform/smapi/BAT1/manufacturer = SONY
/sys/devices/platform/smapi/BAT1/model = 41U4890
/sys/devices/platform/smapi/BAT1/manufacture_date = 2007-10-10 <--!
/sys/devices/platform/smapi/BAT1/first_use_date = 2012-07-20 <--!
/sys/devices/platform/smapi/BAT1/cycle_count = 3
/sys/devices/platform/smapi/BAT1/design_capacity = 29160 [mWh]
/sys/devices/platform/smapi/BAT1/last_full_capacity = 29160 [mWh]
/sys/devices/platform/smapi/BAT1/remaining_capacity = 29160 [mWh]
/sys/devices/platform/smapi/BAT1/remaining_percent = 100 [%]
/sys/devices/platform/smapi/BAT1/remaining_running_time_now = not_discharging [min]
/sys/devices/platform/smapi/BAT1/remaining_charging_time = not_charging [min]
/sys/devices/platform/smapi/BAT1/force_discharge = 0
/sys/devices/platform/smapi/BAT1/power_now = 0 [mW]

/sys/devices/platform/smapi/BAT1/start_charge_thresh = 80 [%]
/sys/devices/platform/smapi/BAT1/stop_charge_thresh = 90 [%]
 
Es ist ja die Frage, ob TLP doch was daran schrauben kann, oder mein TP das aus unerfindlichen Gründen so macht. Also, Chef? :D
 
Hi, ich muß einfach mal ein Lob an linrunner los werden

TLP ist ein super Tool - ich hab gerade nen Installationsmarathon hinter mir, mehrere TPs wurden auf *buntu 12.04 umgestellt.
Somit hatte ich Gelegenheit, mal den (geschätzten) Stromverbrauch mit und ohne TLP zu beobachten - der Unterschied ist echt gewaltig.

Beispiel:
X220 ohne TLP ca 7,5 Std -> mit TLP fast 12 Std und damit mehr als das parallel installierte Win7 (10,5 Std)
X41 ohne TLP ca 2,5 Std -> mit TLP ca. 4,5 Std

auf nem W500, nem T410 und 2 R500 TPs verhält es ähnlich - im Schnitt 3-5 Std längere Akku-Laufzeit.

Darum nochmal: herzlichen Dank für das tolle Tool :thumbup:

Grüßle

Frieder
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben