XT320 und funktionierender ondemand-governor

[Bernd.Defy]

Hallo zusammen,

standardmäßig ist unser Defy Mini auf den CPU-Governor "performance" eingestellt. Das heißt, dass die CPU entweder mit vollen 600MHz läuft oder im Tiefschlaf (deepsleep) verharrt. Gut nachzuvollziehen mit der App "CPU Spy". Da ich mutmaße, dass die CPU bei geringerem Takt weniger verbraucht, war ich auf der Suche nach alternativen Einstellungen, bevorzugt "ondemand", also CPU-Leistung bei Bedarf, wobei ich Wert auf schnelles Hochtakten legte.

Nach einigen Tests mit "CPUTuner" und "No Frills CPU Control" musste ich feststellen, dass eine funktionierende Governor-Einstellung auf "ondemand" nicht möglich war. Ich hatte reproduzierbar nach längeren ScreenOff-Phasen das Problem, dass die CPU bei 122 MHz hängen blieb und nicht mehr hochtaktete! Unbenutzbar, übrigens.

Meine Lösung nun: ein eigenes kleines Script, was beim Boot alle Einstellungen vornimmt. Zum automatischen Start des Scripts ist eine App notwendig - mit dem passenden Namen "Autostart(root)" (playstore, kostenlos). Das Scipt "autostart.sh" müsst ihr dann unter /data/opt/ ablegen. Wichtig: Berechtigung 750 setzen (rwx-r-r).

Hier der Script-Inhalt:

#!/system/bin/sh

# SCHEDULER AUF NOOP UMSTELLEN
echo "noop" > /sys/block/mmcblk0/queue/scheduler

# log entfernen
rm /dev/log/main

# governor konfigurieren. Teile aus /system/etc/init.qcom.post_boot.sh
echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor

# bei 65% hochtakten
echo 65 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/up_threshold
chown system /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate

# niedrigste freq. 245Mhz
echo 245760 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
# Prueffrequenz für governor
echo 10000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate_min
echo 10000 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/sampling_rate
# niceload nicht ignorieren
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load
# bei 5% Last runtertakten
echo 50 > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/powersave_bias
# I/O glt als Last
echo 1 > /sys/devices/system/cpu/cpufreq/ondemand/io_is_busy
# geklaut aus irgendeinem xda-Thread
echo 5 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

Ich hänge die Datei noch an, da Linux andere Zeilenumbrüche als Windows kennt. Kaputtmachen könnt ihr aber ohnehin nichts.

Bei mir läuft das jetzt seit einigen Tagen problemlos, mit CPUSpy sieht man, das 245 und 480 MHz meistgenutzt sind, die Bedienung ist aber ebenso flüssig wie vorher.

Probiert's mal, wenn ihr mutig seid, und berichtet von euren Erfahrungen.

Viele Grüße!

 

[spammemad]

Hallo Bernd,

danke für das Script.

Ich werde das demnächst probieren (und Meldung erstatten), aber ich verspreche mir davon erst einmal keine messbar längere Laufzeit. Der S1-Prozessor ist ja relativ genügsam. Manche Apps verbrauchen durch ihre häufigen Aktualisierungen sicher wesentlich mehr -> Energiesparplan | heise mobil

FG

 

[Bernd.Defy]

Hi spammemad,

ja, Laufzeitsprünge erwarte ich auch nicht. Danke auch für den Heise-Link!

Ich denke aber, wenn der GPS-Tracker oder MP3-Player oder ein anderer recht konstanter Prozess mitläuft, macht's am Ende vielleicht doch eine viertel oder halbe Stunde aus... Läßt sich leider nicht sinnvoll testen, hängt halt vom Nutzerprofil ab.

Vielleicht gibt's ja sowas wie einen Batteriebenchmark, der durchschnittliche nutzung simuliert (also nix was 100% Leistung benötigt). Ich werde mal Frau google fragen.

Andere Telefone mit der gleichen Snapdragon-Plattform haben offensichtlich gleiche Probleme mit dem ondemand-Governor und haben (aus meiner Sicht für diesen Governor sinnfreie) extrem hohe Minimalfrequenzen. Dieser Post bei XDA-Developers beschriebt übrigens das von mir initial betrachtete Phänomen, dass der Prozessor nicht hochtaktet: xda-developers - View Single Post - [Q] CPU frequencies

Viele Grüße!

 

[spammemad]

Hallo Bernd,

bei den xda-developers geht es um einen MSM7227 (65 nm, < 800 MHz), im XT320 werkelt ein MSM7225A (45 nm, < 800 MHz).

Außerdem - und erscheint mir viel wichtiger - spart eine niedrige Taktfrequenz nahezu keinen Strom. Die Taktrate wird nur gesenkt, damit man die Spannung verringern kann. Denn der Stromverbrauch steht etwa im quadratischen Verhältnis zur Spannung. Das Senken der RAM- und der Core-Spannung führt zu wesentlichen Einsparungen. Wenn Du die Spannung aber nicht einstellen kannst, bringt das Absenken der Taktrate eigentlich nichts. Denn die Taktfrequenz verändert nur annähernd linear den Stromverbrauch und gleichzeitig ist auch eine proportional längere Zeit zur Verarbeitung erforderlich. Oder anders gesagt: Doppelte Zeit halber Stromverbrauch bringt keine Ersparnis.

Beim GPS-Tracking zieht das GPS-Modul mächtig Strom und bei vielen anderen Anwendungen das Rendern der Anzeige. Wie sich der Prozessor beim Abspielen von MP3 (oder ähnlichem) verhält, weiß ich nicht - aber da brauchen vermutlich schon etliche Kopfhörer wesentlich mehr Saft.

Freundliche Grüße

 

[Bernd.Defy]

Hallo spammemad,

Danke für Deine Antwort!

bei den xda-developers geht es um einen MSM7227 (65 nm, < 800 MHz), im XT320 werkelt ein MSM7225A (45 nm, < 800 MHz).

Naja, zumindest ist Qualcomm der Hersteller. Da war ich wohl mit Blindheit geschlagen.

Außerdem - und erscheint mir viel wichtiger - spart eine niedrige Taktfrequenz nahezu keinen Strom.
[...]
Das Senken der RAM- und der Core-Spannung führt zu wesentlichen Einsparungen. Wenn Du die Spannung aber nicht einstellen kannst, bringt das Absenken der Taktrate eigentlich nichts.

Hmmm. Und genau hier hatte ich die Annahme, dass die CPU / der Kernel / wer auch immer weiß, dass bei 245 Mhz z.B. nur 0.5V, bei 600Mhz dagegen 1.0V Core-Spannung anliegen. Analog zu den x86-Prozessoren, dort reicht ja auch eine Frequenzänderung, um die Core-Spannung anzupassen (FID/VID). Ist das bei den Snapdragoniern nicht so?

Die echte Auswirkung der Aktion auf die Laufzeit läßt sich halt nicht nachprüfen. Es würde mich dennoch interessieren, denn ansonsten sollte man ja jeden Androiden auf "performance" einstellen, wenn die Stromsparpotentiale der anderen Governors so gering sind.

Viele Grüße!

 

[spammemad]

Hallo Bernd,

bei mir hat die Einstellung "ondemand" zu mehreren Problemen geführt: Ein Timer hat statt nach 12 erst nach mehr als 20 Minuten geklingelt und gleichzeitig wurde der Pattern Lock-Screen oft zäh wie Kaugummi.

Ich habe dann mit dem "schnörkellosen" CPU-Control experimentiert (geht schneller und schreibt vermutlich ähnliche Scripte) - aber ohne Erfolg. Auch bei "interactive" ist der Pattern Lock-Screen manchmal nur mit großer Geduld zu bewältigen.

Dabei ist mir der Verdacht gekommen, dass die CPU manchmal von 122 MHz nicht mehr hochtaktet, weil der Berechnungs-Prozess (für den erforderlichen Prozessortakt) vielleicht nur eine geringe Priorität hat und erst nach einem sowieso schon quälend langsam laufenden Prozess gestartet wird?

In einem Beitrag auf xda-developers (CPU Governors explained - xda-developers) werden 28 verschiedene Regelungs-Techniken beschrieben - ganz so einfach ist es offenkundig nicht, ohne anderweitig spürbare Einbußen Strom zu sparen. Und zur "performance"-Regelung steht dort sinngemäß, dass vieles darauf hinweist, dass die "race-to-idle"-Variante doch gar keine so schlechte Idee ist.

Bei der Einstellung "performance" braucht es keine komplizierten Algorythmen, der Prozessor kann umso schneller in den wirklich sparsamen Ruhezustand schalten. Anscheinend ist auch hier weniger mehr. Und darum sind wohl auch einige Android-Geräte einfach auf "performance" eingestellt.

Und das Stromspar-Potenzial ist bei Snapdragon-Prozessoren auch nur gering: Snapdragon Presents: The Bug Circus Generator - YouTube

Schließlich bin ich mit der Ausdauer von dem Defy mini so oder so sehr zufrieden. Bei dem Gerät kann man sich die Einstellung "performance" ohne weiteres erlauben, denke ich.

Freundliche Grüße

 

[Bernd.Defy]

Hallo spammemad,

bei mir hat die Einstellung "ondemand" zu mehreren Problemen geführt: Ein Timer hat statt nach 12 erst nach mehr als 20 Minuten geklingelt und gleichzeitig wurde der Pattern Lock-Screen oft zäh wie Kaugummi.

So war es bei mir mit dem Lockscreen auch - mit Tools wie CPUTuner oder dem frill-freien CPU-Control. CPUTuner kann den up-Threshold und den powersave_bias noch einstellen, beide Tools setzen aber die "I/O gilt als Beschäftigung"-Option nicht. Erst diese hat bei mir das Zäh-wie-Kaugummi-Phänomen beseitigt.
Das mit dem Timer ist interessant - konnte das verhalten aber noch nicht beobachten.

Dabei ist mir der Verdacht gekommen, dass die CPU manchmal von 122 MHz nicht mehr hochtaktet, weil der Berechnungs-Prozess (für den erforderlichen Prozessortakt) vielleicht nur eine geringe Priorität hat und erst nach einem sowieso schon quälend langsam laufenden Prozess gestartet wird?

Ich denke, deshalb wird schon in den Original-Scripten für fast jede Plattform die Minimalfrequenz auf 245 MHz angehoben. Andererseitz ist die Auslastungs-Prüfung standardmäßig auf alle 50ms eingestellt - ich habe es auf 10ms runtergenommen.

"Race-To-Idle" heißt doch aber, dass es nur die Zustände "Full-Speed und maximaler Stromverbrauch" oder "minimaler Stromverbrauch" gibt. Wenn ich den Performance-Governor einstelle, bedeutet dass doch aber, dass, solange der Bildschirm an ist, die CPU mit 600MHz läuft, auch, wenn z.B. nur eine Webseite angezeigt wird und sonst recht wenig Leistung benötigt wird, die CPU also primär vor sich hin-idle-dt. Und ist es nicht genau dann doch irgendwie vorteilhaft, wenn die CPU sich nur mit 245 Mhz (und entsprechend weniger Core-Spannung) langweilt, statt mit voller Kraft und bei 600MHz?

Zum Potential dieser ganzen Aktion: Ich habe nirgends mal eine Auflistung gefunden, bei welcher Frequenz der CPU welche Spannung anliegt. Dann könnte man ja tatsächlich mal das Potential bewerten. Ich bleib mal noch ein Weilchen bei den Einstellungen aus dem ersten Post, mal sehen, wie's sich entwickelt.

Schönes Video!

Viele Grüße
Bernd

 

[spammemad]

Hallo Bernd,

... beide Tools setzen aber die "I/O gilt als Beschäftigung"-Option nicht. Erst diese hat bei mir das Zäh-wie-Kaugummi-Phänomen beseitigt.

das solltest Du den Entwicklern von den Tools unbedingt mitteilen. So gesehen war mein Vergleich dann auch nicht "fair", oder besser, eigentlich gar nicht aussagefähig.

Das mit dem Timer ist interessant - konnte das verhalten aber noch nicht beobachten.

Das ist bei mir auch nicht zuverlässig reproduzierbar gewesen - aber einmal hat mir gereicht. Und der Pizza auch ...

"Race-To-Idle" heißt doch aber, dass es nur die Zustände "Full-Speed und maximaler Stromverbrauch" oder "minimaler Stromverbrauch" gibt.

Ja, so verstehe ich das auch.

Wenn ich den Performance-Governor einstelle, bedeutet dass doch aber, dass, solange der Bildschirm an ist, die CPU mit 600MHz läuft, auch, wenn z.B. nur eine Webseite angezeigt wird und sonst recht wenig Leistung benötigt wird, die CPU also primär vor sich hin-idle-dt.

Nein, es gibt sicher auch für die kleinen Displays einen Framebuffer und die CPU fällt immer mal wieder in "Tiefschlaf".

Und ist es nicht genau dann doch irgendwie vorteilhaft, wenn die CPU sich nur mit 245 Mhz (und entsprechend weniger Core-Spannung) langweilt, statt mit voller Kraft und bei 600MHz?

Eben nicht, weil die Peripherie, solange der Prozessor verarbeitet, nicht in Schlaf versetzt werden kann (https://lesswatts.org/projects/applications-power-management/race-to-idle.php). Abgesehen davon braucht die "race-to-idle"-Variante nahezu keine Rechenleistung - die meisten anderen Einstellungen dagegen schon und auch andauernd.

Zum Potential dieser ganzen Aktion: Ich habe nirgends mal eine Auflistung gefunden, bei welcher Frequenz der CPU welche Spannung anliegt. Dann könnte man ja tatsächlich mal das Potential bewerten.

Das wird vielleicht sogar CPU-intern geregelt, aber solange man dem Speicher und z.B. Controller nicht auch die Spannung absenken kann, bleibt halt nur geringes Spar-Potenzial.

Wer z.B. seine Wetter-App (deren tieferer Sinn sich mir sowieso nicht erschließt, weil es doch preiswerte und gute Wetterstationen gibt) alle zehn Minuten die aktuellen Daten abfragen lässt, braucht sich über den CPU-Governor m.E. keine Gedanken zu machen. Wenn man seine verschiedenen Apps zur (zeitlich) gemeinsamen Synchronisation zwingt, GPS nur bei Bedarf einschaltet und die permanente - aber oft total unsinnige - automatische Suche nach einem vermeintlich besseren Netz unterbindet, kann man wohl wesentlich mehr als das, was der Prozessor in dem Zeitraum insgesamt verbraucht, sparen.

Quasi wir jammern hier auf höchstem Niveau.


Freundliche Grüße

 

[Bernd.Defy]

So, ich habe es heute mal getestet:

2h Musik abspielen im Flugzeugmodus, einmal mit Governor "performance", einmal mit "ondemand", jeweils screen off. 2h sind wenig, aber eine Tendenz sollte sich nach der Zeit schon zeigen. Habe den Batteriezustand mit "Battery spy" geprüft und hoffe, dass sich die Spannung des Akkus halbwegs linear zur Restkapazität senkt.

"Performance" war wie erwartet nur bei 600 MHz, kein deepsleep. "Ondemand" war ungefär 50% der Zeit in 245Mhz, ~40% in 480MHz und den Rest in 600MHz unterwegs.

Sowohl der angezeigte Batterydrain vom Batteryspy (5%) als auch die Differenz der Spannung (mV zu Beginn - mV zum Ende) waren bei beiden Varianten identisch. Das heißt, ausser einer definitiv schlechteren Performance bringt eine Governor-Umstellung auf dem Defy-Mini keine signifikante Batterielaufzeit.

Mist.

Viele Grüße,
Bernd

 

[spammemad]

Hallo Bernd,

danke für den Test. Wer mit dem Mini länger Musik hören möchte, sollte also besser Kopfhörer mit größerer Impedanz probieren ...

...
Mist.

Aber doch nur insofern, dass man an der Stelle nichts mehr verbessern kann.

FG