Der Akku-Thread zum Razr i: Akkulaufzeiten, -Probleme und mehr

  • 2.336 Antworten
  • Letztes Antwortdatum
Die Automatische Helligkeit funktioniert bei mir einwandfrei. Wenns draussen sehr hell ist, dann ist es vorteilhaft, wenn das Gerät die Helligkeit automatisch auf maximum schraubt, damit man überhaupt was sieht und wenn man im dunkeln ist, dann ist sie eben auf Minimum :) Ansonsten den Tag über, subjektiv gesehen genau in der Mitte.

Ob sich das jetzt allerdings negativ auf die Akkuleistung auswirkt, müsste man langzeittesten, aber ich denke eher nur geringfügig.

Die Analyse mit CPU Spy betrifft im übrigen NUR! die CPU und keine anderen Komponenten. So kann man zumindest schauen auf welchen Frequenzen die CPU am häufigsten läuft. Wenn sie eh mehr auf Minimum oder DeepSleep läuft, dann hat Telefon reichlich wenig zu tun. Ist schon mal ein guter Ansatz dafür, dass Apps nicht Zombiemässig rumlaufen und die CPU sinnloserweise belasten.

Ja, auch solche Apps gibt es in der Tat. Aufwendiger ist es jedoch die Laufzeit von jeder einzelnen App zu zerlegen. Denn wenn nämlich viel synchronisiert werden muss, dann wird auch das GSM Modem respektive das WLAN Modul beansprucht und das kostet, wie man vielleicht vermuten lässt, ebenfalls Akkupower.

GPS kann man eh getrost anlassen, weil der Chip automatisch ausgeht, wenn er nicht gebraucht wird. Von daher zieht man hier keinen Nutzen.

Was man auch noch ausprobieren kann, ist, in den Entwickleroptionen sozusagen bisschen am System rumzuspielen. Dort kann zum Beispiel einstellen, dass Fensteranimationen jeglicher Art nicht die CPU, sondern die GPU übernehmen soll. Ob sich die Akkuleistung verbessern würde, müsste man ausprobieren.

Wenn beide Komponenten allerdings ungefähr gleich viel Strom fressen würden, wäre der Vorteil nahezu null. Aber hier heisst es testen.

Ansonsten kann man nicht mehr viel machen. Höchstens noch die radikale Methode: Telefon zurücksetzen und garnix installieren und dann schauen :D
 
hallo Leute,
also zum Thema automatische Helligkeit habe ich weiter oben schon mal ne Rechnung angestellt.
Es kommt natürlich immer drauf an, aber der Verbrauch im Helligkeitsbereich 50% und mehr ist auf jeden Fall über proportional höher gegenüber dem Verbrauch einer unteren Stufe.
Und das Thema Deepsleep: wenn ihr hier nur etwa 40% Anteil habt, dann solltet Ihr wirklich mal prüfen wie aktiv die ein oder andere app ist, wenn das Handy mal nicht benutzt wird.

Für meine Nutzung haben sich folgende Werte als Orientierung ergeben:
Deepsleep Anteil: 90%
nachts (wlan und daten aus) in ca. 8Std.: 2-3%
displayOn: ca. 1Std. je 25% bei ca. 2Tagen Laufzeit
 
Hallo,

ich takte mit Tasker bei "Display State off" auf 600 MHZ (Min und Max) und als Exit-Task dann "min 600 und max 1400 MHZ".

Das sieht dann so aus: Screenshot_2013-04-29-19-01-25.png

Denke damit fahre ich bezüglich Akkuausdauer ganz gut und habe auch keine merkbaren Geschwindigkeitsverluste.
Zwischen 23:50 und 6:00 Flugmodus und W-Lan aus.

Gruß
matsches
 
Erfahrungen (hier im forum) haben gezeigt das das runter takten null einfluss auf die akku lebensdauer hat...
 
Hi,

Akkulebensdauer (defekt) oder Akkulaufzeit (muss geladen werden)?

Habe beim "Subwaysurfen" ohne runtertakten gemerkt, dass das Gehäuse schon ziemlich warm wird. Mit max 1400 MHz bilde ich mir ein, dass dies nicht der Fall ist. Von daher denke ich schon, dass es etwas bewirken könnte.

Ist natürlich ein subjektiver Eindruck, aber solange alles flüssig läuft habe ich zumindest ein gutes Gefühl dabei ;)

Andererseits frage ich mich dann schon, welchen Sinn die "Governors" haben wenn dies eh nichts bringt.

Gruß
matsches
 
TrippleT schrieb:
Erfahrungen (hier im forum) haben gezeigt das das runter takten null einfluss auf die akku lebensdauer hat...

Das kommt drauf an, wie weit man runtertaktet und ob man auch mit einberechnet, dass man die vSel mit runtersetzen muss und nicht nur den Takt :o
 
Hallo,
ich habe den Akku gestern mal bewusst nicht ganz voll geladen und folgende Einstellungen über Nacht vorgenommen:
Flugzeugmodus, Lautlos. Mit Smartaction um 22 Uhr auomatisch eingestellt.

Akku stand gestern Abend bei 92%
Heute Morgen mache ich das Handy an und es steht bei 86%, nach ein paar Sekunden auf 85%

Das sind 7% Verlust in 7,5 Std.

Ich habe 2 Screenshots gemacht, danach sieht aber alles sehr gut aus, Handy war die meiste Zeit im Schlafmodus.

Ist das denn normal? 1% verlust in 1 Std. ?

Gruß
 

Anhänge

  • Screenshot_2013-04-30-05-29-18.png
    Screenshot_2013-04-30-05-29-18.png
    17,9 KB · Aufrufe: 283
  • Screenshot_2013-04-30-05-29-30.png
    Screenshot_2013-04-30-05-29-30.png
    17,7 KB · Aufrufe: 224
Bei mir sieht es genau so aus wie bei dir. Mein RAZR i braucht über Nacht auch 1% je Stunde. Denke also dass das ganz okay ist. Hätte zwar auch lieber die 0,2% je Stunde über Nacht wie andere hier, aber irgendwie klappt das nicht.
Mein Deep Sleep liegt auch über Nacht wie bei dir so zwischen 98 und 99% und das ist ja auch schon eigentlich perfekt. Warum wir dann trotzdem noch so einen "hohen" Verbrauch über Nacht haben ist mir dann trotzdem ein Rätsel. :(
 
In 1h 1% ist doch akzeptabel. Wenn der Wert so dauerhaft sinken würde, würde das Telefon über 4 Tage durchhalten, was nicht machbar ist ;)
 
es nur zum Teil auf zu laden bringt natürlich nichts. Dann ziehst du den Stecker bei Bei Ladespannung und noch recht hohem Ladestrom. Zu diesem Zeitpunkt fällt die Spannung bei disconnect wieder recht stark ab sodass sich die Akkuanzeige wieder nach unten ein pendelt. Gerät aufladen, normal bis wenig benutzen bis es auf unter 90% ist und dann mal mindestens fünf Stunden liegen lassen.
 
OK, das werde ich dann mal Heute so machen....

Gruß
 
Ich möchte die Taktraten nochmal kurz aufgreifen: Taktet bei irgendwem das Handy unter JB (!) auch nur EINMAL auf 1.400, 1.600 oder 1.800 MHz? Das hat es bei mir noch NIE wieder unter JB! Bei ICS war es minimal, aber es war dort wenigstens mal.
 
die 3 States werden unter JB überhaupt nicht genutzt, zumindest nicht laut CPU Spy ;) Wieso auch immer...

Was bisschen verwunderlich ist, denn die Schritte gehen ja: 600, 900, 1200 und dann direkt auf 2GHZ. Wenigstens 1600 und 1800 hätte man ja noch mit einbeziehen können.

Die Frage jetzt, ob die States überhaupt jemals aktiv waren oder nur unter JB nicht genutzt werden.
 
Die nächste Frage wäre, ob diese Taktfrequenzen überhaupt was bringen. Wenn sich dadurch nämlich die Kernspannung nicht reduzieren lässt, dann sind diese Taktraten unsinnig. Evtl. ist die Einsparung aber auch nur so minimal dass man sich dafür entschieden hat, gleich die höchste Taktrate für den letzten Sprung zu verwenden, um die Performance noch etwas zu verbessern.

Jedenfalls kann ich mir nicht vorstellen, dass der Energieverbrach großartig durch diese Zwischenzustände sinken würde.
 
Viper schrieb:
Ich möchte die Taktraten nochmal kurz aufgreifen: Taktet bei irgendwem das Handy unter JB (!) auch nur EINMAL auf 1.400, 1.600 oder 1.800 MHz? Das hat es bei mir noch NIE wieder unter JB! Bei ICS war es minimal, aber es war dort wenigstens mal.

Ja?
Ich denke es ist sehr wichtig dazu zu schreiben welcher governor und scheduler benutzt wird.

Ich habe InteractiveX und row.


Die Taktfrequenzen werden bei mir wenn zwar auch wenig, aber benutzt. Gibt keins, was unbenutzt ist!
 
Ich vermute er spricht von Stock, also ondemand und dieser neigt ja sowieso dazu die mittleren Taktraten nicht zu benutzen.
 
Ich spreche ebenfalls von Stock und unroot, so wie es sich auch gehört. Was man unter einem gerootetem Telefon mit einer x86 CPU macht, ist unerheblich. Dazu müsste man nämlich auch wissen, ob der Intel Atom die States, die bei Stock geblockt werden, überhaupt direkt unterstützt, oder ob des nur "Fake"-States wären.
 
  • Danke
Reaktionen: Viper
Hier mal 3screens von mir, 3 Tage “normal “ genutzt! Allerdings mit 2g.. Zwischendurch 2reboots und in der ersten Nacht mit den power-off-Knopf in den Ruhezustand versetzt...

WLAN nur kurz an, mit WLAN bekomme ich nur 2 Tage hin! Wurde ja auch schon hier diskutiert, das WLAN scheinbar extrem an Akku zieht...
 

Anhänge

  • uploadfromtaptalk1367360611816.jpg
    uploadfromtaptalk1367360611816.jpg
    44,7 KB · Aufrufe: 266
  • uploadfromtaptalk1367360620525.jpg
    uploadfromtaptalk1367360620525.jpg
    2,4 KB · Aufrufe: 268
  • uploadfromtaptalk1367360628875.jpg
    uploadfromtaptalk1367360628875.jpg
    40,7 KB · Aufrufe: 261
Also ich hab mich mal eben umgesehen auf dem RAZR i. Musste bisschen suchen, aber okay.

Hoffe ich bekomm das auch alles hin. Wenn mich nicht alles täuscht, läuft die CPU im interactive Mode. Das bekommt man raus, da man ja mittels Shell nach:

/sys/devices/system/cpu/cpufreq/
gehen kann. Dieses ist ein Verzeichnis, macht ja aber nix. Wenn es andere Modis geben würde, würden die wahrscheinlich hier stehen. Egal, passt schon.

Dort sind einige Dateien drin:

shell@smi:/sys/devices/system/cpu/cpufreq/interactive $ ls -la
-rw-rw---- system system 4096 2013-04-30 23:37 above_hispeed_delay
-rw-rw---- system system 4096 2013-04-30 23:37 boost
--w------- system system 4096 2013-04-30 23:37 boostpulse
-rw-rw---- system system 4096 2013-04-30 23:37 go_hispeed_load
-rw-rw---- system system 4096 2013-04-30 23:37 hispeed_freq
-rw-rw---- system system 4096 2013-04-30 23:37 input_boost
-rw-r--r-- root root 4096 2013-05-01 12:50 io_is_busy
-rw-rw---- system system 4096 2013-04-30 23:37 min_sample_time
-rw-rw---- system system 4096 2013-04-30 23:37 timer_rate
shell@smi:/sys/devices/system/cpu/cpufreq/interactive $


Die man so aber alle nicht auslesen kann. Zumindest nicht ohne root und da man hier von Stock redet, muss man damit aber leben. Soweit so gut.

Gehen wir 2 Verzeichnisse zurück und schauen uns mal den Ordner cpu0 an:

shell@smi:/sys/devices/system/cpu/cpu0 $ ls -la
drwxr-xr-x root root 2013-05-01 12:55 cache
drwxr-xr-x root root 2013-05-01 11:21 cpufreq
drwxr-xr-x root root 2013-05-01 12:55 cpuidle
-r-------- root root 4096 2013-05-01 12:55 crash_notes
drwxr-xr-x root root 2013-05-01 12:55 topology
shell@smi:/sys/devices/system/cpu/cpu0 $

Da gibt es ebenfalls einen Ordner cpufreq. Die interessanten Dateien sind:

  • scaling_available_frequencies
  • scaling_available_governors

Die erste enthält die verfügbaren Frequenzen für die CPU, die folgende beinhaltet:

le_frequencies <
2000000 1800000 1600000 1400000 1200000 900000 600000
shell@smi:/sys/devices/system/cpu/cpu0/cpufreq $

Es sieht so dämlich aus, weil die Shell da mittendrin abschneidet, die Breite stimmt nicht, macht aber nichts. Hier sieht man, dass die FEHLENDEN! Freqs auf jedenfall eingetragen sind und auch genutzt werden KÖNNTEN! Warum das nun in JB nicht der Fall ist, ist eine Frage.

Die verfügbaren Governors sind: userspace und interactive, wie oben schon erwähnt, denn diese beiden stehen eben in dieser Datei.

Es gibt auch um genau zu sein 2 Treiber, die die skalierung übernehmen, dass sind: scaling_driver und sfi-cpufreq.

Nun, soweit bin ich noch nicht um da reinzuschauen, da kommt bestimmt noch ein edit oder ein neuer Post.

Das gleiche ist auch exakt in cpu1 enthalten.

Nun stellt sich die Frage: Wer blockiert nun eigentlich die nicht genutzten Frequenzen? Der Treiber, oder Android? Denn verfügbar sind sie auf jedenfall :/

Und ja, dass ganze ist nachgeschaut mit Stock und unroot ;) Sogar die Busybox ist verfügbar!
 
Otandis_Isunos schrieb:
Ich spreche ebenfalls von Stock und unroot, so wie es sich auch gehört. Was man unter einem gerootetem Telefon mit einer x86 CPU macht, ist unerheblich. Dazu müsste man nämlich auch wissen, ob der Intel Atom die States, die bei Stock geblockt werden, überhaupt direkt unterstützt, oder ob des nur "Fake"-States wären.

Was - "sich auch so gehört" ..?

Ich lese hier nichts von Stock aus dem threadtittel!


So wie es sich gehört - nicht zu wissen, wie die governors arbeiten :winki:




*langweilig*
 

Ähnliche Themen

P
Antworten
11
Aufrufe
2.826
iieksi
iieksi
A
Antworten
1
Aufrufe
2.434
anakin94
A
W
Antworten
8
Aufrufe
2.275
iieksi
iieksi
Zurück
Oben Unten