Mein Laptop säuft: Eine Linux-Akku-Nebenquest mit Happy End

Ich hatte vorher praktisch keine Erfahrung mit Linux auf einem Laptop.

Also habe ich genau das getan, was man in so einer Situation vermutlich nicht tun sollte, wenn man einen ruhigen Einstieg möchte:

Ich habe Ubuntu installiert.

Dann Hyprland.

Dann Noctalia.

Dann noch meinen ganzen üblichen Arbeitskram darübergekippt.

Und weil das alles überraschend hübsch aussah und nicht sofort explodierte, dachte ich:

„Joa. Läuft doch.“

Technisch gesehen stimmte das sogar.

Es lief.

Nur eben nicht besonders lange.

Mein ThinkPad T14 Gen 2 AMD schaffte mit diesem Setup kaum zwei Stunden auf Akku. Einmal ging es von 100 Prozent auf 6 Prozent in ungefähr einer Stunde und 45 Minuten.

Das ist keine Akkulaufzeit.

Das ist eine sehr lange BIOS-Session mit Desktop-Effekten.

Also begann eine dieser typischen Nebenquests, bei denen man eigentlich nur wissen möchte, warum der Laptop so schnell leer ist, und ein paar Tage später plötzlich UPower-Historien auswertet, PCI-Geräte schlafen legt und eine eigene GTK-App baut.

Normaler Donnerstag also.

Mein erster Verdacht war natürlich der Akku

Wenn ein Laptop nach nicht einmal zwei Stunden Richtung Notabschaltung kriecht, ist der Akku ein ziemlich naheliegender Verdächtiger.

Das Gerät ist schließlich nicht neu.

Der Akku hatte zu diesem Zeitpunkt 398 Ladezyklen hinter sich. Seine ursprüngliche Kapazität lag bei 51 Wh, davon waren noch ungefähr 45 Wh nutzbar. Das entspricht grob 88 bis 90 Prozent Gesundheit.

Nicht fabrikneu.

Aber auch nicht kurz davor, sich in einen dekorativen Briefbeschwerer zu verwandeln.

Ein Akku mit 45 Wh sollte bei leichter bis mittlerer Nutzung deutlich länger als zwei Stunden durchhalten. Wenn er das nicht tut, gibt es zwei Möglichkeiten:

1. Der Akku lügt.
2. Irgendetwas zieht absurd viel Strom.

Der Akku wirkte in den Daten relativ glaubwürdig.

Also blieb Möglichkeit zwei.

Und die hatte offenbar mehrere Freunde mitgebracht.

Erst messen, dann den Paketkobold beschuldigen

Der wichtigste Schritt war rückblickend nicht irgendein magischer Kernelparameter.

Es war die Entscheidung, erstmal vernünftig zu messen.

Mit upower konnte ich den aktuellen Akkustand, die Entladerate und die geschätzte Restlaufzeit ansehen:

upower -i /org/freedesktop/UPower/devices/battery_BAT0

Die historischen Daten lagen unter /var/lib/upower/. Damit konnte ich nicht nur auf eine gerade schwankende Restzeitanzeige starren, sondern echte Sitzungen rekonstruieren.

Zwei davon sahen besonders unschön aus:

Das war also keine einmalige Laune der Anzeige.

Der Laptop hielt unter meiner damaligen Nutzung tatsächlich nur knapp zwei Stunden.

PowerTOP bestätigte das Bild. In einer frühen Messung lag die Entladerate bei ungefähr 24,8 Watt. UPower zeigte in derselben Phase oft um die 23 Watt.

45 Wh nutzbare Kapazität geteilt durch ungefähr 24 Watt.

Da muss man kein Elektrotechnik-Orakel sein.

Das Ergebnis lautet:

„Kiru, dein Laptop säuft.“

Wichtig dabei: PowerTOP kann den Verbrauch einzelner Programme und Geräte nicht perfekt messen. Viele seiner Wattangaben pro Prozess sind Schätzungen. Die gesamte Entladerate ist wesentlich brauchbarer als die Behauptung, irgendein einzelner Prozess habe exakt 2,731 Watt verbraucht.

Aber die Muster waren deutlich.

Und das Muster lautete ungefähr:

• Display sehr hell
• Codex Desktop als Electron-Anwendung
• GPU nicht besonders sparsam
• viele Wakeups
• fehlendes Runtime Power Management
• Firefox und WebContent
• Hyprland, Noctalia und Terminal natürlich ebenfalls mitten auf der Tanzfläche

Es war nicht der eine große Stromkobold.

Es war eine WG.

Der erste große Hebel war kein Kernelparameter

Am Anfang lief Codex als Desktop-App.

Also Electron.

Electron ist praktisch. Electron ist flexibel. Electron bringt Webtechnik auf den Desktop.

Electron bringt manchmal aber auch gefühlt ein kleines digitales Heizkraftwerk mit, nur damit irgendwo Text erscheint.

In den Messungen fiel Codex Desktop durch CPU-Last, Renderer, GPU-Prozess und viele Wakeups auf. Der Wechsel auf Codex CLI machte einen deutlich messbaren Unterschied.

Die groben Stufen sahen bei mir so aus:

Das sind keine Laborwerte mit identischer Last und weißem Kittel.

Das waren echte Arbeitssitzungen. Mal bewegte sich mehr auf dem Bildschirm, mal weniger. Mal arbeitete Firefox mit, mal Codex, mal beides.

Aber der Trend war nicht subtil.

Der Wechsel von Desktop-Codex auf die CLI war kein esoterischer Ein-Prozent-Tweak. Er nahm sichtbar Last aus dem System.

Und plötzlich war da diese leicht unangenehme Erkenntnis:

Nicht alles, was bequem aussieht, ist auf einem Laptop kostenlos.

Power-Saver war die Basis, aber nicht die Lösung

Natürlich habe ich das Systemprofil auf power-saver gestellt:

powerprofilesctl set power-saver

Das half.

Aber es war nicht dieser eine Schalter, nach dem der Laptop plötzlich sechs Stunden meditierend im Energiesparlotus saß.

Ein Power-Profil gibt CPU und Plattform eine Richtung vor. Es räumt aber nicht automatisch jeden einzelnen Verbraucher auf. Wenn die GPU wach bleibt, PCI-Geräte nicht schlafen, Electron fröhlich rendert und das Display kleine Sonnenaufgangssimulationen veranstaltet, kann auch power-saver nur danebenstehen und tief seufzen.

Auf meinem Ryzen 7 PRO 5850U lief immerhin bereits der moderne amd-pstate-epp-Treiber. Die Energy Performance Preference stand später auf power, das Firmware-Profil auf low-power.

Das war eine gute Grundlage.

Nur eben noch kein fertiges Haus.

Runtime PM: Geräte dürfen auch mal schlafen

PowerTOP meldete viele fehlende Runtime-PM-Tunings.

Runtime Power Management bedeutet vereinfacht: Ein Gerät, das gerade nichts zu tun hat, darf in einen sparsameren Zustand wechseln.

Klingt selbstverständlich.

Ist unter Linux aber wie so oft eine Mischung aus Kernel, Treiber, Firmware und der stillen Hoffnung, dass alle Beteiligten denselben Kalender benutzen.

Ich setzte die erreichbaren PCI-Geräte auf auto:

for control in /sys/bus/pci/devices/*/power/control; do
    echo auto > "$control"
done

Am Ende standen 35 PCI-Geräte auf automatischem Runtime PM.

Ethernet-Controller, Audio-Geräte, USB-Zweige und andere Komponenten konnten damit schlafen, wenn sie nicht gebraucht wurden.

Das war einer der größeren technischen Hebel.

Nicht spektakulär.

Keine hübsche Animation.

Nur sehr viele kleine Geräte, die endlich aufhörten, im Maschinenraum das Licht brennen zu lassen.

Die AMD-GPU wollte gelegentlich wieder auf die Bühne

Die integrierte AMD-GPU lief zeitweise im DPM-Zustand performance.

Auf einem Desktop ist das vielleicht okay.

Auf einem Laptop, der gerade versucht, länger als einen Spielfilm durchzuhalten, eher weniger.

Ich setzte den DPM-State auf battery:

echo battery | pkexec tee /sys/class/drm/card1/device/power_dpm_state

Das Problem war nur:

Manche Einstellungen blieben nicht zuverlässig so.

Nach einem Resume, Profilwechsel oder anderen Ereignissen konnte die GPU wieder zurückspringen. Deshalb baute ich zunächst ein kleines Skript, einen systemd-Service, einen Timer und udev-Regeln.

Der Timer zog die Einstellungen alle fünf Minuten nach.

Das funktionierte.

Es war aber auch der Moment, in dem aus „ich setze kurz ein paar Werte“ langsam ein kleiner Installer-Keller wurde.

Ein Skript hier.

Eine sysctl-Datei dort.

Ein Timer im Regal.

Eine udev-Regel hinter der Tür.

Und irgendwo ein Kiru, der drei Tage später garantiert nicht mehr weiß, welche Schraube jetzt eigentlich von wem gedreht wird.

NMI-Watchdog und Writeback: die kleineren Schrauben

PowerTOP schlug außerdem vor, den NMI-Watchdog abzuschalten:

kernel.nmi_watchdog = 0

Der Watchdog ist für bestimmte Diagnosefälle nützlich, erzeugt im Alltag aber zusätzliche Aktivität. Auf meinem normalen Arbeitslaptop brauchte ich ihn nicht dauerhaft.

Außerdem passte ich das Writeback-Intervall an:

vm.dirty_writeback_centisecs = 1500

Damit schreibt das System nicht bei jeder kleinen Gelegenheit sofort Daten zurück, sondern kann Vorgänge besser bündeln.

Das sind keine Maßnahmen, die allein zwei Stunden Laufzeit herbeizaubern.

Sie gehören eher in die Kategorie:

„Wenn ich schon aufräume, nehme ich die leeren Kaffeetassen gleich mit.“

Ja, das Display war natürlich auch beteiligt

Ich hätte gerne eine geheimnisvollere Antwort.

Irgendeinen versteckten Kernel-Bug.

Eine dramatische Firmware-Verschwörung.

Einen AMD-Dämon im Backlight-Treiber.

Aber nein.

Das Display stand teilweise auf 100 Prozent.

Und ein helles Laptop-Display braucht Strom.

Wer hätte das gedacht.

Das Reduzieren auf ungefähr 50 Prozent brachte die Entladerate in einer guten Messung auf rund 8,9 Watt. Später lag ich selbst bei etwa 80 Prozent Helligkeit zeitweise um 7,8 bis 8,4 Watt, wenn der Rest des Systems ruhig war.

Das Display war also einer der größten Hebel.

Aber nicht der einzige.

Das ist mir wichtig, weil „mach halt dunkler“ als alleinige Antwort ungefähr so hilfreich ist wie „schließ Programme“, wenn ein System ein echtes Energieproblem hat.

Ja, Helligkeit zählt.

Aber von knapp 25 Watt auf 8 bis 9 Watt kam ich nicht nur mit einem dunkleren Bildschirm.

Der WLAN-Fix, der das WLAN kaputtoptimierte

Und dann kam der Teil, den man in glattpolierten Erfolgsgeschichten gerne weglässt.

Ich aktivierte WLAN-Powersave.

PowerTOP empfahl es. Technisch klang es sinnvoll. Der Realtek-Adapter sollte weniger Energie verbrauchen, wenn gerade nicht viel übertragen wird.

Also an damit.

Ein paar Tage später war das Internet so langsam, dass normales Arbeiten keinen Spaß mehr machte.

Nicht ein bisschen gemütlich.

Richtig lahmarschig.

Die Messung zeigte schließlich:

• WLAN-Powersave war aktiv
• der Laptop hing im überfüllten 2,4-GHz-Band
• Empfangsrate: teilweise nur 11 Mbit/s
• Internet-Ping: Ausreißer bis 251 ms

Da hilft die schönste Akkulaufzeit nichts, wenn jede Webseite genug Zeit zum Nachdenken bekommt.

Also WLAN-Powersave wieder aus.

Nicht diskutiert.

Nicht schöngeredet.

Weg damit.

Zusätzlich pinnte ich die Verbindung auf den 5-GHz-Zugangspunkt desselben WLANs. Danach sah es so aus:

• ungefähr 155 Mbit/s Empfangsrate
• Router-Ping um 2 ms
• Internet-Ping stabil um 15,5 ms
• WLAN-Powersave aus

Das ist für mich eine der wichtigsten Erkenntnisse aus der ganzen Aktion:

Ein Energiespar-Tweak ist nur dann gut, wenn der Rechner danach noch vernünftig benutzbar ist.

Ein Laptop, der fünf Stunden durchhält, aber beim Laden einer Webseite innerlich einen Antrag beim Betriebsrat stellt, ist nicht optimiert.

Er ist nur anders kaputt.

Von 1,85 Stunden auf realistische vier bis fünf

Nach den Änderungen sahen die späteren Sitzungen deutlich besser aus:

In ruhigen Momenten zeigte UPower sogar Werte, die rechnerisch Richtung 5,5 bis 6 Stunden gingen. Eine konkrete Messung lag bei 7,842 Watt. Mit ungefähr 45,1 Wh nutzbarer Kapazität ergab das rechnerisch rund 5,75 Stunden.

Das ist aber keine Garantie.

Sobald Codex arbeitet, Firefox mehrere Tabs jongliert, das Terminal viel neu zeichnet oder Hyprland und Noctalia mehr zu tun bekommen, steigt der Verbrauch wieder.

Eine spätere komplette Sitzung lief von 100 auf 45 Prozent in zwei Stunden und neun Minuten. Hochgerechnet waren das knapp vier Stunden.

Und ehrlich?

Das ist für mein echtes Setup ziemlich okay.

Nicht Weltrekord.

Nicht die zwölf Stunden, die irgendein Hersteller mit lokalem Video, ausgeschaltetem WLAN und einem Bildschirm auf Kerzenscheinhelligkeit verspricht.

Aber ein Sprung von ungefähr 1,85 Stunden auf vier bis fünf Stunden ist kein Rundungsfehler.

Das ist der Unterschied zwischen:

„Wo ist die nächste Steckdose?“

und:

„Ich kann den Laptop tatsächlich benutzen.“

Das Problem mit meinen ganzen Fixes

Technisch funktionierte das Tuning.

Praktisch hatte ich danach mehrere Stellen, die Einstellungen veränderten:

• ein Shell-Skript
• eine sysctl-Datei
• ein systemd-Service
• ein systemd-Timer
• udev-Regeln
• NetworkManager-Einstellungen
• einzelne Werte in /sys

Das ist okay, solange man gerade mitten im Thema steckt.

Drei Wochen später wird daraus schnell digitale Archäologie.

Warum steht die GPU auf battery?

Wer schaltet WLAN-Powersave wieder ein?

Warum passiert das alle fünf Minuten?

Welche Datei muss weg, wenn ich den Ursprungszustand zurückhaben möchte?

Und genau da entstand die Idee für Hybruntalia Power.

Nicht als großes Optimierungsmonster.

Nicht als „Ein Klick und Linux hält für immer“-Schlangenöl.

Sondern als kleine GTK4-Oberfläche, die sichtbar macht, was ich eigentlich tue.

Hybruntalia Power: ein Schalter braucht auch einen Rückweg

Hybruntalia Power ist aktuell ein kleines lokales Werkzeug auf GTK4- und libadwaita-Basis.

Die Oberfläche läuft als normaler Benutzer. Nur wenn wirklich eine Systemeinstellung geändert wird, startet ein eng begrenztes Backend über Polkit.

Also genau so, wie ich es auf meinem System haben möchte:

Kein komplettes GUI-Programm als Root.

Kein Passwort im Terminal.

Kein Backend, dem man beliebige Shell-Befehle hinwerfen kann.

Die App zeigt unter anderem:

• Akkustand und momentane Leistungsaufnahme
• aktives Power-Profil
• Zustand von PCI Runtime PM
• WLAN-Powersave
• AMD Panel Power Savings
• ob der automatische Akkumodus aktiv ist

Dazu gibt es drei Profile:

Der wichtige Teil ist aber nicht das Einschalten.

Der wichtige Teil ist das Entfernen.

Vor der ersten Änderung speichert das Backend den erkannten Ausgangszustand unter:

/var/lib/hybruntalia-power/original-state.json

Die Datei gehört Root und ist nur für Root lesbar. Gesichert werden Power-Profil, PCI-Zustände, GPU-Modus, WLAN-Powersave und AMD-Panelwerte.

Mit „Ausgangszustand wiederherstellen“ lassen sich diese Werte zurückschreiben.

Außerdem erkennt das Tool meine alte kiru-laptop-power-tune-Installation und kann Skript, Timer, Service, sysctl-Datei und udev-Regel wieder entfernen.

Das klingt vielleicht nach einem kleinen Detail.

Für mich ist es aber der Unterschied zwischen einem brauchbaren Werkzeug und einem weiteren Script, das irgendwo im System wohnt und nachts Geräusche macht.

Was der automatische Akkumodus macht

Wenn der automatische Modus aktiviert wird, installiert Hybruntalia Power einen kleinen systemd-Service und einen Timer.

Alle fünf Minuten wird geprüft, ob der Laptop gerade auf Akku läuft. Nur wenn BAT0 wirklich Discharging meldet, werden die Werte angewendet:

• Power-Profil auf power-saver
• PCI Runtime PM auf auto
• AMD-GPU auf battery
• AMD Panel Power Savings auf Stufe 1
• WLAN-Powersave ausdrücklich auf off

Ja, ausdrücklich auf off.

Der Realtek-Zwischenboss hat einen bleibenden Eindruck hinterlassen.

Die App setzt nicht einfach alles um, was PowerTOP theoretisch hübsch findet. Sie bildet die Einstellungen ab, die sich auf diesem Laptop in der Praxis bewährt haben.

Und sie tut das nachvollziehbar.

Das passt für mich auch ziemlich gut zu Hybruntalia.

Hybruntalia soll keine eigene Distribution werden, die alles verschluckt und den Schlüssel wegwirft. Es soll ein modularer, offener Desktop-Layer für Ubuntu, Hyprland und Noctalia sein.

Nur Hyprland.

Nur Noctalia.

Oder das ganze Paket.

Je nachdem, was man möchte.

Hybruntalia Power folgt derselben Idee: Komfort, aber mit sichtbaren Schrauben und einem Rückweg.

Was am Ende wirklich geholfen hat

Wenn ich die ganze Aktion auf die wichtigsten Punkte herunterbreche, waren die großen Hebel:

1. Display nicht dauerhaft auf 100 Prozent betreiben.
2. Codex Desktop durch Codex CLI ersetzen.
3. PCI Runtime Power Management aktivieren.
4. AMD-GPU auf Akku im battery-Zustand halten.
5. power-saver als vernünftige Basis verwenden.
6. Einstellungen nach Resume und Profilwechsel zuverlässig nachziehen.

Mittlere und kleinere Hebel waren:

• NMI-Watchdog deaktivieren
• Writeback-Intervall anpassen
• Terminal, Firefox-Tabs und Noctalia-Polling im Auge behalten
• unnötige Dienste und Geräte schlafen lassen
• AMD Panel Power Savings vorsichtig nutzen

Und die wichtigste Nicht-Empfehlung lautet:

WLAN-Powersave nicht blind aktivieren, nur weil PowerTOP „Good“ daneben schreiben möchte.

Testet Änderungen einzeln.

Messt danach.

Und wenn das Internet plötzlich durch Sirup läuft, nehmt den Tweak wieder zurück.

Linux ist kein Charaktertest.

Man muss nicht unter einer schlechten Einstellung leiden, nur weil sie technisch Energie spart.

Mein Fazit

Ich dachte zuerst, der Akku sei einfach durch.

War er aber nicht.

Er hatte noch ungefähr 88 bis 90 Prozent seiner ursprünglichen Kapazität. Das eigentliche Problem war mein Setup.

Oder genauer:

Die Summe aus meinem Setup.

Ubuntu war nicht schuld.

Hyprland war nicht allein schuld.

Noctalia war nicht allein schuld.

Codex Desktop war nicht allein schuld.

Das Display war nicht allein schuld.

Es waren viele kleine und einige größere Verbraucher, die gleichzeitig beschlossen hatten, dass Akkubetrieb nur eine unverbindliche Empfehlung sei.

Das Spannende daran ist, dass sich Linux an dieser Stelle nicht magisch selbst repariert.

Aber es lässt sich beobachten.

Man kann die Historie lesen.

Man kann messen.

Man kann Hypothesen ausprobieren.

Man kann einen Fix wieder verwerfen, wenn er das WLAN ruiniert.

Und man kann aus dem ganzen Chaos am Ende sogar ein kleines Werkzeug bauen.

Mein ThinkPad hält heute unter meiner realen Nutzung nicht plötzlich zwölf Stunden.

Aber es hält grob vier bis fünf statt knapp zwei.

Das ist mehr als doppelt so viel nutzbare Zeit.

Und ich habe dabei nicht nur gelernt, wie man einen Laptop sparsamer bekommt.

Ich habe auch etwas sehr Typisches über Linux gelernt:

Wenn es brennt, ist nicht immer das System kaputt.

Manchmal hat man einfach Ubuntu, Hyprland, Noctalia, Electron, ein sehr helles Display und 35 hellwache PCI-Geräte in einen Raum gestellt und sich dann gewundert, warum es warm wird.

Tja.

Jetzt haben die Geräte Schlafenszeit.

Und ich ein GTK-Tool mit Rückgängig-Knopf.

Eigentlich ein ziemlich gutes Ende für eine Nebenquest, die mit 7 Prozent Akku begann.