[Info] Akkuverbraucher des Galaxy S2

[payce]

Hallo an Alle!

Wer mich kennt, weiß, was ich als Erstes immer ganz gerne mache, wenn ich ein neues Phone bekomme.

Vergleiche hier:
https://www.android-hilfe.de/forum/...os-ladekurven-leistungsverbraucher.73360.html
und hier:
https://www.android-hilfe.de/forum/dell-streak-5.142/info-akkuverbraucher-des-dell-streak.91013.html

Nun, das SGS2 habe ich jetzt seit zwei Wochen, also wirds Zeit auch diesen mal bezüglich des Akkuverbrauchs einzelner Komponenten unter die Lupe zu nehmen. Und eines kann ich gleich vorweg nehmen: Interessante Geschichte!

Ich werde hier keine allgemeinen Aussagen zum Akku treffen (Lade/Entladekurve, Alterung, "Akkutraining"-Mythos etc.), da dies HIER bereits absolut erledigt ist!

BITTE LESEN:
Hier werden keine allgemeinen Fragen zur Akkulaufzeit beantwortet ("Mein Akku läuft nur 4 Stunden, wenn ich SuperGrafikMassaker-MMORPG-online-super-plus zocke! Warum?"). Das hier ist ein -> [INFO] Thread. D.h. Posts mit Infos, Anregungen, Kritik und vor Allem Diskussionen sind herzlich willkommen. Posts mit Fragen zur Akkulaufzeit ganz allgemein (Kernels, Custom-ROMs, Apps etc) sind hier viel, viel besser aufgehoben: https://www.android-hilfe.de/forum/...26/der-grosse-akkulaufzeit-thread.100574.html
Und vorher *immer* hier einlesen: https://www.android-hilfe.de/forum/...ng-galaxy-s2.659/f-a-q-akku-guide.149042.html <- dort sind 90% aller Fragen bereits beantwortet und man weiß zukünftig, wie man sich selbst hilft!
​

ANMERKUNG: Da ich meine Phones ganz gerne personalisiere und daher "neutrale" Bezeichnungen ("das SGS2") ungerne verwende, nenne ich es im Text jetzt einfach mal SIGGI. Also "der SIGGI". Ich hoffe, Ihr verzeiht mir diese kleine Finte. Vielmehr hoffe ich, dass der Text dadurch stellenweise vielleicht sogar amüsanter wird! (^_^)


Inhalt:
1 Vorgehen und Messaufbau
2 Messung der Akkukapazität inkl. Diskussion
3 Ergebnisse in der Übersicht
4 Diskussion der allgemeinen Akkuverbraucher
5 Diskussion des CPU-Akkuverbrauchs
6 Verbräuche im StandBy-Betrieb


1 Vorgehen und Messaufbau

Der Akku von SIGGI (im Bild die 2000 mAh Variante) wird in eine dafür vorgesehene Halterung eingespannt (Bild 1 unten, Bild 2 links), welche die einzelnen vier Pins des Akkus herausführt. Zwei der Pins dienen der eigentlichen Versorgung (von "links" gezählt Pin 2 und 4).
Die beiden anderen Pins sind noch etwas fraglich in Ihrer Funktion: Pin 1 (ganz links) scheint gar keinen Nutzen zu haben (keinerlei Beschaltung und auch keine Änderung in SIGGI, wenn ich diesen Pin weglasse). Pin 3 *scheint* eine Kennung der Akkukapazität mitzuliefern: Im 1650 mAh Akku ist hier ein Widerstand zur Masse von 1,5 kOhm (in nachgekauften Akkus mit 1650 mAh anscheinend 4,7 kOhm - Danke an Thomas_ !), beim 2000 mAh Akku von 27 kOhm zu messen (*alles* original Samsung Akkus).
btw: So könnt Ihr oft auch gefälschte Akkus entlarven: Der Pin 3 ist dann meistens nicht beschaltet, hat also einen "unendlich" hohen Widerstand zu Pin 2 (Minuspol).
Wenn hier jemand noch mehr Messwerte weiterer Akkus hat, immer her damit!
​

Zur Messung der Kapazität wird der Akku über ein externes LiPoly Ladegerät ge- und entladen ("gezykelt") und die Kapazität mittels Coulomb Counter gemessen (Bild kommt noch).
​

Zur Messung der einzelnen Leistungen der typischen Verbraucher im Phone wird ein "Dummy-Akku" (vgl. Bild 2 rechts) in SIGGI eingesetzt, der wiederum die 4 Akku-Pins herausführt. Die 4 Pins von Phone und Akku werden auf einer Laborkarte verschaltet (Bild 1 Mitte), wobei jeweils Pin 2 von Phone und Akku (der Minuspol) direkt miteinander verbunden sind, während bei Pin 4 (Pluspol) ein Strommessgerät dazwischen geschaltet wird. So ist es möglich, jederzeit die momentan verbrauchte Leistung zu messen (Leistung = Strom * Spannung).
​

Messgeräte: Spannungsmessung mit einem Voltcraft VC404 (Bild 1 Mitte), Strommessung mit einem Grundig DM60 (Bild 1 links), Kapazitätsmessung mit einem Swallow Charger/Discharger
​

Mein Galaxy S2: Stock-ROM 2.3.6 (KK2) mit Siyah-Kernel 2.5
​

Anmerkungen:
​

• In Kap. 2 geht es um die Akkukapazität, also verwende ich dort i.A. die Angaben mA und mAh. Anders in den folgenden Kapiteln: Dort geht es um die verbrauchte Leistung, d.h. ich verwende die Werte mW und mWh (bzw. W, Wh). Das ist durchaus sinnvoll, da SIGGI die Akkuspannung immer auf das benötigte Niveau konvertiert (3,3 V und/oder 5 V). D.h. es wird kein konstanter Strom aus dem Akku gezogen, sondern eine näherungsweise konstante Leistung (= Strom * Akkuspannung).
  Zur Info: Li-Poly und Li-Ionen Akkus haben eine Nennspannung von ~ 3,7V. D.h. der Standardakku mit 1650 mAh hat 6,1 Wh bzw. der größere Originalakku von Samsung mit 2000 mAh hat 7,4 Wh.
• Bei einem gechätzten Kontaktstellenwiderstand von in Summe 0,5 Ohm ergibts sich bei hohen Strömen (im SGS2 bis zu 1 A!) ein rechnerischer Messfehler von max. 12,5% *bei hohen Leistungen*! Bei niedrigen Leistungen sollte der Messfehler geringer sein (unter Berücksichtigung der Messgerätungenauigkeit < 5%).
  Dieser Messfehler beeinflusst hauptsächlich die Spannung des Akkus. SIGGI misst und sieht also eine geringere Spannung als der Akku tatsächlich noch hat.
• Das Entnehmen des Akkus aus SIGGI hatte enormen (negativen) Einfluss auf die 2G/3G Empfangsstärke! Ich kann mir bisher nicht erklären, an was das liegen kann. Der LiPoly Akku ist zum Schutz mit Alu umschirmt, die Antenne relativ nahe daneben (unterer Part von SIGGI, um den Freisprech-Lautsprecher herum). Evtl. ist die Antenne genauso designt, dass sie mit Akku am Besten funktioniert.
• Erläuterung USB-Ladung:
  Wenn SIGGI an das Netzteil gehängt wird, saugt es entsprechend des Anschlusstyps (USB oder Power (also ein echtes Netzteil)) ~ 450 mA (USB) bzw. ~ 650 mA (Power) und "lädt" damit den Akku. Lädt steht deswegen in Anführungszeichen, da konstant diese Strommenge gezogen wird, egal ob SIGGI selbst gerade mehr oder weniger Strom benötigt. D.h. wenn SIGGI gerade 500 mA benötigt (bspw. ein 3D-Spiel oder Video), wird der Akku nur noch mit 150 mA geladen (Power) oder sogar mit 50 mA weiter entladen (USB). Das sollte man wissen, wenn man sich wundert, warum das Akku laden so ewig dauert.

2 Messung der Akkukapazität inkl. Diskussion

Die Messung der Kapazität wird mit einem Swallow Li-Ionen Charger/Discharger überprüft, also einem externen Ladegerät. Folgende Specs:

• Ladung mit 1A Spitzenstrom, 4,2 Volt Spitzenspannung und 100 mA Abschaltstrom
• Entladung mit 500 mA bzw. 200 mA bis 3,1 Volt Schlussspannung

Die Unterschiede zur Ladung in SIGGI: Der Abschaltstrom bei Ladung ist in SIGGI stock 200 mA. D.h. die Kapazität wird in diesen Messungen etwas zu gut geschätzt (ist nicht viel - vllt. 20 mAh mehr). Auch die Schlussspannung liegt etwas höher - ca. 3,3 Volt. Das macht aber so gut wie nichts aus. Der Spannungseinbruch findet eh schon bei ~ 3,4 Volt statt und macht vllt. 5 bis 10 mAh maximal aus.


1650 mAh Akku original Samsung:
(nur zwei Wochen verwendet, korrekt gelagert, also quasi neu)

• Entladung mit 500 mA (~ C/3): 1670 mAh
• Entladung mit 200 mA (C/8): 1695 mAh
• Ladung: 1620 mAh

2000 mAh original Samsung:
(ca. 2 Monate in Gebrauch, also evtl. schon leichtester Verschleiß)

• Entladung mit 500 mA (C/4): 2030 mAh
• Entladung mit 200 mA (C/10): 2065 mAh
• Ladung: 1990 mAh

Fazit:
Die Originalakkus erfüllen alle Erwartungen: Die Kapazität passt (ist sogar minimal größer), überaus stromstabil (d.h. die Kapazität geht bei höheren Strömen nicht in die Knie - was bspw. bei Billigakkus mit schlechten Elektroden sehr gerne passiert) und eine wirklich sehr gute Coloumb-Effizienz (das was reingesteckt wird, kommt auch wieder raus) - laut Messung kommt sogar mehr raus, als reingesteckt wird. Natürlich ein Messfehler aufgrund der Kontaktwiderstände.


Unterschied 2000 mAh -> 1650 mAh Akku:
Oft fragen die Leute, wie groß denn der Unterschied jetzt ist... ob man ihn "spürt". Laut obigen Messdaten:
2065 mAh/1695 mAh = 1,22
Auf deutsch: Man hat ungefähr 22% mehr Laufzeit. Punkt.
Lief der Stein bisher ~ 36 h kann man mit einem 2000 mAh Akku ~ 44 h erwarten.
(Abgesehen davon hat die neue Halterung laut vielen Leuten einige Vorteile: Die Kamera ist "versenkt" statt hervor stehend und die komische Beule unten dran (beim USB-Anschluss) verschwindet)

 

[payce]

3 Ergebnisse in der Übersicht

VGL. BILD 1 im Anhang! (Ist etwas zu groß, um es direkt einzubinden)

Im Anhang findet Ihr die Ergebnisse der Messungen. Angegeben ist jeweils die von SIGGI verbrauchte Leistung in mW für die *jeweils einzelne Komponente*. Um das etwas ausführlicher zu formulieren:

• Deep Sleep Leistung wurde direkt gemessen
• Die Werte der Displayleistung sind exklusive der Deep Sleep Leistung angegeben
• Die Leistungen von LED, Kamera, BT, GPS, WLAN, 2G/3G, CPU sind jeweils exklusive der Displayleistung angegeben

Bei fast allen Messungen wurde eine "idle" Messung und eine "aktiv" Messung durchgeführt, um ausschließlich die Leistung der einzelnen Komponente zu erfahren - d.h. das jeweilige Programm zur Messung (bspw. Speedtest.net oder SetCPU) wurde zwar gestartet, aber die Messung zunächst nicht aktiviert (idle). Der Messwert bei aktiver Messung abzüglich des idle-Messwertes ergibt dann den hier angegebenen, tatsächlichen Messwert. (Ausnhame Kamera: Hier war eine idle-Messung nicht möglich)

Telefonieren:
Die Leistung beim Telefonieren ist nicht mit im Balkendiagramm aufgeführt, da sie erst etwas später durchgeführt wurde. Hier aber trotzdem die Ergebnisse:
(2G-Netz, voller Empfang, *inklusive* Bildschirm 1% Helligkeit - also keine IDLE Messung)

• 790 mW bei normaler Nutzung
• 560 mW wenn Bildschirm aus ist (Proxi Sensor aktiv)

HIER gibts übrigens eine kleine, feine Übersicht von jonathand145 zu den Spezifikationen des Funkmoduls.

​

4 Diskussion der allgemeinen Akkuverbraucher

VORAB EINE ANMERKUNG: Es geht hier *ausschließlich* um den aktiven Verbrauch. Das hat mit den StandBy Verbräuchen erstmal herzlich wenig am Hut, da im StandBy sehr viel mehr passiert! Dazu bitte eher Kap. 6 zu Rate ziehen und/oder den fabelhaften Akku-Guide.

Deep Sleep:

Top. Wäre SIGGI immer im Deep Sleep, würde er mit 3G Empfang 31 Tage durchhalten. (Annahme: Keine Anrufe, keine Updates, kein GAR NIX - aber auch keinen Spaß mit SIGGI ^^)
​

Display:

Interessanterweise verbraucht die reine Display- (und CPU-)bereitschaft bereits satte 370 mW. Solange der Display komplett schwarz ist, bleibt es näherungsweise auch bei diesem Wert (die Helligkeit hat also bei schwarzem Bildschirm keinen Einfluss auf den Leistungsverbrauch - dank AMOLED).
Bei komplett weißem Bildschirm nimmt der Leistungsverbrauch recht linear von 1% Helligkeit (450 mW) zu 100% Helligkeit (960 mW) zu. Vergleiche hierzu Bild 3 mit dem Diagram, welches Euch zeigt, was der Display bei komplett weißem Bild typisch verbraucht. Pro Prozentpunkt Helligkeit kann man 5,2 mW rechnen (bei komplett weißem Display). Die genaue Formel lautet 453 mW + 5,2 mW/(% Helligkeit).
​

Zum Vergleich: LCD-Displays verbrauchen bei voller Helligkeit 600 mW - 800 mW. Ein AMOLED spart also nur dann Akku, wenn er vergleichsweise dunkle Bilder darstellt (Hintergrundbild!)!
​

Die Buttonbeleuchtung geht komplett unter: 40 mW sind verschwindend wenig.
​

Fazit Display: Man kann die Buttonbeleuchtung ruhig durchlaufen lassen, stört den Akku kaum. Aber man sollte tatsächlich beim AMOLED Display einen dunklen Hintergrund wählen! Erfahrungsgemäß kann man mit einem schwarzen Hintergrund einen Weiß-Füllgrad von durchschnittlich etwa 30% annehmen (Icons, Homescreen...). Bei voller Helligkeit spart das folglich bis etwa 400 mW ein!
​

Komponenten und Peripherie:

Die LED-Lampe liegt mit 1,3 W im typischen Bereich. Gleiches gilt für die Kamera mit 0,7 W. Also keine Überraschungen. BT und GPS Scan sind beide überraschend sparsam(110 mW bzw. 180 mW), andere Phones schlagen hier locker mit dem doppelten Wert zu Buche! Und hier ebenfalls nochmal eine Aufklärung: Solange BT und GPS im StandBy sind, ist keine zusätzliche Leistungsaufnahme zu verzeichnen. Man muss also nicht *zwingend* immer alles abschalten.
​

Telefonieren:

Mit jeweils 790 mW (Bildschirm aktiv bei 1% Helligkeit) bzw. 560 mW (Bildschirm aus wegen Proxi Sensor) ist SIGGI echt sparsam - mag an meinem guten Netz liegen. Aber vor Allem auch daran, dass ich SIGGI während der Tests natürlich nicht am Hirn hatte. Dann wird einiges von der Antenne abgedeckt und SIGGI schluckt mehr als diese Werte.
Theoretisch könnte ich mit vollem 1650 mAh Akku ungefähr 7 - 9 Stunden telefonieren - vorausgesetzt ich habe durchgängig ein so gutes Netz. Realistischer ist es natürlich von 5 - 6 Stunden auszugehen.
Bitte diese Messwerte zum telefonieren auch nur als grobe Hausnummer verstehen - habe hier wirklich gutes Netz. In jedem anderen Fall dürfte das schlechter ausfallen.
​

Datenverkehr:

Hier muss angemerkt werden, dass die angegebenen Werte recht starken Schwankungen unterliegen - seid Ihr neben einem Sendemast ist der Verbrauch sehr gering. Ist der nächste Sendemast mehrere km entfernt, schnellt er in die Höhe. Also bitte mit Vorsicht geniesen.
​

Eine Aussage kann man trotzdem treffen (diese deckt sich auch mit anderen Untersuchungen von mir): HSDPA upload benötigt irre viel Leistung (2 W!). Habt Ihr also die Möglichkeit, WLAN zu verwenden, solltet Ihr dieses dem HSDPA durchaus bervorzugen! Nicht nur zwecks 1 GB-Surfgrenze ( ), sondern auch bezogen auf die Akkulaufzeit bei Downloads von größeren Datenmengen (StandBy -> vgl. Kap. 6).
​

Und noch etwas: Ja, EDGE (2G) verbraucht i.d.R. weniger Leistung, spart aber imho kaum Akku (außer Eure Empfangssituation ist entsprechend mies). Denn man muss bedenken, dass der selbe Download über EDGE sehr viel mehr Zeit beansprucht und daher aufintegriert doch mehr Energie verbraucht, als wenn er über HSDPA gelaufen wäre.
​

2G/3G Switcher (bspw. bei Screen Off -> 2G, bei Screen On -> 3G) sind sinnfrei! Nicht nur dauert es länger, dass SIGGI in den DeepSleep geht, der Wechsel zwischen den Netzen selbst schluckt auch noch einen gehörigen Anteil Energie, da eine neue Basisstation gefunden werden muss! Bezogen auf download und Deep Sleep Leistungsverbrauch ist der Unterschied zwischen 2G/3G i.d.R. so gering, dass 2G/3G Switcher sich letztendlich immer als Akkufresser entpuppen! Ein normaler 2G/3G Wechsel zieht für etwa 7 sek. ~ 800 mW. Passiert das die ganze Zeit (bspw. bei automatisierten Lösungen nach Screen Off/On) ist schnell Schicht im Akku.
​

Kein Empfang: Vorab: Wie gesagt, ich hatte derbe Probleme, einen Empfang herzustellen, wenn der Akku entfernt wird, daher bitte die folgenden Aussagen mit gesunder Skepsis betrachten. Wenn ich den Empfang von SIGGI absichtlich unterbinde, versucht er ca. alle 5 sek. sich erneut in das Netz einzuwählen (dauert nicht lange - vllt. jeweils 800 mW über 1 sek) - ein derber, ordentlicher Stromschlucker. Wenn Ihr also keinen Empfang habt, vielleicht tatsächlich eher auf Flugmodus stellen.
​

Zu fast dormancy konnte ich bei aktiven Phone leider keinen Einfluss messen. Das hat aber eher damit zu tun, dass ich kaum Empfang habe, wenn ich den Akku entferne. Damit kann ich zwischen fast dormancy enabled/disabled leider keine klaren Aussagen treffen. Ganz anders im StandBy! Vgl. Kap. 6. Im StandBy kann fast dormancy zum Akkusauger mutieren.
​

Beispiele für verschiedene Verbrauchswerte:
Vgl. Bild 2 Balkendiagramm. (Auch recht groß )

In einem Balkendiagramm wird etwas leichter klar, wer bei SIGGI tatsächlich Hauptverantwortlicher für den Verbrauch ist. Android selbst will einem ja im "Akkuverbrauch" weiß machen, dass immer der Bildschirm daran Schuld ist, dass nur noch 20% Akku übrig sind. Naaaajaaa...
​

Von links nach rechts:
​

Immer dabei: StandBy (8 mW, sieht man nicht), Button-Beleuchtung (der schmale, violette Balken)
Balken 1: Display komplett schwarz und 500 MHz CPU Volllast
Balken 2: Display komplett weiß bei 1% Helligkeit + 1,2 GHz Volllast
Balken 3: Display komplett weiß bei 100% Helligkeit + 1,4 GHz Volllast (übertaktet)
Balken 4: Beispiel "Navi": 800 MHz Vollast, Display ~ 450 mW, BT und GPS kontinuierlich auf Scan (ist natürlich bei Navi-Nutzung nicht wirklich der Fall)
Balken 5: Beispiel "Foto": Display ~ 450 mW, Kamera + LED-Blitz
​

Was lernen wir? Der größte Schlucker ist wohl die CPU, sofern er denn unter Volllast fährt. Das ist glücklicherweise nicht allzu oft der Fall. OC auf 1,4 GHz ist ziemlich der Knüller: SIGGI schluckt plötzlich 4 W und hätte innerhalb von 1,5 h den Akku leergesaugt. BT + GPS kann man meist getrost vernachlässigen. Die Kamera saugt ebenfalls ordentlich und kann bei ausgedehnten Photoshootings schnell den Akku entleeren (Camcorder noch schlimmer).

Der gute CPU von SIGGI... mit diesem beschäftigen wir uns im Folgekapitel wohl etwas genauer...

 

[payce]

5 Diskussion des CPU-Akkuverbrauchs

Wie zuvor gilt auch hier: Die gemessenen Werte entsprechen den *reinen* Verbrauchswerten der CPU. Also alles andere (Display etc.) ist nicht inbegriffen!
Anmerkung: Der Einfachkeit halber kürze ich Core Voltage mit CV ab!

Konst. Core Voltage bzw. Frequenz

Wenn man sich das Verhalten der CPU genauer ansehen will, ist es ratsam, zunächst immer nur einen Parameter zu variieren. So geschehen in Bild 1: Links wird die Frequenz konstant gehalten (200 MHz bzw. 800 MHz) und CV variiert, rechts genau umgekehrt bei einer fixen CV von 1250 mV.
In beiden Fällen verhält sich der Leistungsverbrauch einigermaßen linear (bei 800 MHz und variierter CV ist eine leichte Nichtlinearität vorhanden). Das deckt sich mit anderen Untersuchungen:
Der Leistungsverbrauch verhält sich näherungsweise jeweils linear zur Core Voltage und Frequenz.

​

Variation Core Voltage + Frequenz

Folglich müsste bei Überlagerung einer angepassten Core Voltage mit der Frequenz (* angepasste CVs siehe weiter unten) sich die Leistung wieder nicht-linear verhalten, genauer gesagt quadratisch. So ist es auch, vgl. Bild 2 links. Auffällig ist hier aber, dass der quadratische Anteil in Vergleich zu anderen CPUs (Milestone, Streak) recht hoch ist, d.h. die CPU verbraucht bei hohen Frequenzen deutlich mehr Leistung!

Um das Ganze etwas vergleichbarer darzustellen, kann man sich nun die spez. Leistung darstellen lassen, d.h. man teilt den jeweiligen Leistungsverbrauch durch die Frequenz. Damit hat man eine Aussage darüber, wieviel Leistung *die selbe* Aufgabe bei der jeweiligen Frequenz benötigt. Siehe Bild 2 rechts, welches man übrigens auch als Energie in Joule / 1 Milliarde Taktzyklen interpretieren kann.

In allen CPUs konnte ich bisher immer einen "nice spot" finden, also eine Frequenz, bei der Rechenoperationen auf die verbrauchte Energie bezogen optimal ausgeführt werden (Streak: 600 MHz, Milestone: 550 MHz). Im SGS2 ist das genauso: Ein und die selbe Operation wird energetisch am Effizientesten bei 200 MHz durchgeführt!

Übrigens brachte *bei mir* ein Untertakten auf 100 MHz nichts mehr, da ich die CV nicht weiter herunterschrauben konnte (ebenfalls 850 mV). Da der Verbrauch sich jeweils linear zur CV und Frequenz verhält, sollte die spezifische Leistung bei 100 MHz also in etwa genauso hoch sein wie bei 200 MHz. Dem ist nicht ganz so: Die aktivierte CPU-Peripherie versaut den Wert bei 100 MHz (1 W/GHz bei 100 MHz und 0,7 W/GHz bei 200 MHz).
Ein Untertakten auf 100 MHz bringt akkutechnisch nichts, *außer* die CV ist geringer als bei 200 MHz (ist i.d.R. nicht der Fall).

Zwischenfazit: Die minimale Taktrate sollte bei SIGGI *immer* 200 MHz betragen, egal ob Screen On oder Screen Off. Hier werden Operationen energieeffizient durchgeführt!

(*): Hier meine für das Diagramm verwendeten CV's: 100 MHz 850 mV, 200 MHz 850 mV, 500 MHz 850 mV, 800 MHz 1000 mV, 1000 MHz 1100 mV, 1200 MHz 1250 mV, 1400 MHz 1350 mV, 1600 MHz 1450 mV. Mit diesen Werten fährt mein SIGGI recht stabil (mehrere Tage ohne Abstürze).

​

Weiteres

Einen Unterschied der Leistungen zwischen den Kerneln konnte ich (zum Glück) nicht feststellen - d.h. natürlich nicht, dass der eine Kernel mehr/weniger Leistung verbraucht als der andere. Je nach Einstellungen von Wakelocks, Polling etc. kann ein Kernel die gesamte Laufzeit natürlich stark beeinflussen. Nur halt den Verbrauch der einzelnen Komponenten alleine nicht (außer bei UV).

Das Abschalten eine der beiden Cores vermindert die verbrauchte Leistung auf etwa 55% bis 58%. Das passt vom Wert her recht gut. Das Abschalten einer Core kann die Leistung nicht auf 50% drücken, da, egal ob eine oder zwei Cores rennen, immer etwas CPU-Peripherie mitläuft. Das heißt aber auch, dass ein kontinuierliches Abschalten einer Core die Akkulaufzeit zwar verlängert, aber der Wert für die spez. Leistung (also Energie pro Operation) schlechter wird! Imho also lieber die Frequenz begrenzen (siehe nächster Absatz), da man dann den spez. Leistungsverbrauch verbessert *und* nicht gezwungenerweise auf 50% der Rechenleistung verzichtet.

1600 MHz:
Ich habe mal ein paar Tests bei 1600 MHz (1450 mV) gemacht: SIGGI schluckt während der CPU-Voll-Last stolze 5,9 W (!!!!!). Nicht nur deswegen rate ich von einem übertakten auf 1600 MHz ganz klar ab. 5,9 W (bzw. 1850 mA) entspricht einer Entladung von ~ C (d.h. der Akku wäre innerhalb einer Stunde leer). Damit sinkt nicht nur die Akkulebensdauer, sondern man hat auch das Problem, dass bei Voll-Last die Akkuspannung schnell mal auf einen Wert unter 3,3 Volt einbricht und der Akku fälschlicherweise als "leer" interpretiert wird - obwohl noch genügend Saft vorhanden wäre. Folge: SIGGI schaltet ab, obwohl der Akku vielleicht noch eine reale Restkapazität von über 30% hat (ohne Übertreibung).

Zum Akku sparen kann man sich überlegen, die Frequenz auf 1 GHz oder 800 MHz zu begrenzen. Damit lässt sich der spez. Leistungsverbrauch auf 70% (1 GHz) bzw. 60% (800 MHz) deutlich senken (in Vergleich zu 1,2 GHz)! Zum Vergleich: Bei übertakten auf 1400 MHz verbraucht die gleiche Operation 20% mehr Energie als bei 1200 MHz!
Das heißt nicht, dass ich grundsätzlich von 1400 MHz abrate. Man hat SIGGI ja nicht gekauft, um eine möglichst lange Akkulaufzeit zu erreichen, sondern um in den Genuss einer echt irren Performance zu kommen! Aber wenn man weiß, dass einem ein Steckdosen-freies Wochenende bevor steht, kann man die Akkulaufzeit per Untertakten auf 800 MHz in Vergleich zu 1400 MHz *locker* um mind. 50% erhöhen (max. CPU-Verbrauch sinkt von 3,8 W auf 0,95 W bzw. 2,7 W/GHz auf 1,2 W/GHz).
PS: Ich fahre normalerweise auf 1400 MHz, *wenn* ich weiß, dass SIGGI am Abend an die Steckdose kommt.

Wenn man den Dual Core mit einrechnet (= doppelte Rechenleistung) ist die CPU in SIGGI ein sensationelles Sparwunder... aber nur, wenn er bei 800 MHz oder weniger rennt! Um einen Dual-Core mit einem Single-Core direkt zu vergleichen, kann man den spez. Leistungsverbrauch in etwa halbieren. Beim Milestone und am "nice spot" wird ~ 1 W/GHz verbraucht, beim Streak ~ 0,7 W/GHz (ziemlich gut!).
SIGGI hat Dual-Core-bereinigt (Wert halbiert) sensationelle 0,3 - 0,4 W/GHz bei 200 MHz, 0,5 - 0,7 W/GHz bei 500 MHz / 800 MHz und 0,9 - 1,2 W/GHz bei 1 - 1,2 GHz.
Ausnahmen OC und UC: Hier verbucht SIGGI Dual-Core-bereinigt stolze 0,5 W/GHz (100 MHz), 1,3 W/GHz (1400 MHz) bzw. 1,8 W/GHz (1600 MHz). Nicht wirklich gute Werte...
Also nochmal: Mein Tipp zum Akku sparen (wenn nötig bzw. gewollt) ist ganz klar, die max. Frequenz runterzusetzen bzw. einen Governor zu verwenden, der möglichst spät & selten den CPU-Takt erhöht!

PS: Governor sind eine Religionsfrage. Ich fahre *immer noch* (da sehr zufrieden mit der Performance) ondemand. Für eine schnelle Reaktion verwende ich eine Sampling rate von 50 ms (!nicht kürzer! ansonsten verursacht ondemand selbst eine höhere Taktrate) und eine Threshold von 90% bis 95% (damit erst recht spät hochgetaktet / früh runtergetaktet wird).

​

Das Wirreste für den Schluss: 500 MHz CV - it's not a bug, it's a feature

Wer den Thread in der Entstehung mitverfolgt hat, weiß, dass ich anfangs bei 500 MHz recht komische Werte gemessen habe. Es war recht einfach nachzuvollziehen, dass die CV bei 800 MHz auch für 500 MHz übernommen wurde. Nach einer kleinen und feinen Odyssee konnte mir Tegrak höchstpersönlich den entscheidenden Hinweis geben. Hier direkt seine Email mit dem entscheidenden Hinweis:

... I've checked Samsung cpu driver source. something weird code is there.
200MHz -> 500MHz
expected: Volt@200 -> Volt@500
actual: Volt@200 -> Volt@800

I can't explain why they did like this, but I can say this is intended situation by Samsung devs. If you lock frequency 500 after locking at higher freq, it'll work as we expected. In conclusion, the problem that you said is not relative with my app.
Regards, Tegrak

Übersetzt heißt das Folgendes: Der "500 MHz-Bug" ist tatsächlich kein Bug, sondern von Samsung absichtlich in den Kernel so eingebaut. Dabei handelt es sich um eine Hysterese der Core Voltage, die wohl für ein wenig mehr Stabilität sorgen soll. Ich versuche es mal bildlich darzustellen, was in SIGGI passiert, wenn von einem CPU rate Zustand in den nächsten geschaltet wird:

Aufwärts:
200 MHz -> 500 MHz: CV 800 MHz übernehmen
500 MHz -> 800 MHz: CV 800 MHz übernehmen
800 MHz -> 1 GHz: CV 1 GHz übernehmen
usw.

Abwärts:
1 GHz -> 800 MHz: CV 800 MHz übernehmen
800 MHz -> 500 MHz: CV 500 MHz übernehmen
500 MHz -> 200 MHz: CV 200 MHz übernehmen

D.h. bei einer Erhöhung der Taktrate wird im Falle von 500 MHz sicherheitshalber eine zu hohe CV angelegt - ich denke mal, um die Trägheit der Spannungsversorgung auszugleichen oder Ähnliches. Bei Absenken der Taktrate werden keine CV Sprünge gemacht, sondern alles läuft wie gewohnt ab.
Fazit: It's not a bug, it's a feature.
Ich habe meine Messmethode darauf hin angepasst (d.h. ich "steige" nicht auf 500 MHz, sondern "falle" auf 500 MHz) und siehe da, alles passt, vgl. Diagramme.
Das heißt allerdings auch, dass gerade auf eine gute CV bei 800 MHz geachtet werden sollte, da diese doch des Öfteren verwendet wird (eben auch für den Sprung von 200 MHz auf 500 MHz).
Und auch beim optimieren der eigenen CV's muss man darauf achten: Wenn Ihr den Wert für 500 MHz einstellen wollt, setzt zunächst 500 MHz als minimale Taktrate, 800 MHz oder alles drüber als maximale Taktrate, lasst SIGGI irgendwas machen (damit auf > 800 MHz getaktet wird) und vermindert dann erst die maximale Taktrate auf ebenfalls 500 MHz! Ansonsten kann es sein, dass Ihr aus Versehen die CV für 500 MHz *gar nicht* verwendet (bspw. wenn Ihr von vornherein 500 MHz als max. Taktrate und 200 MHz als min. Taktrate setzt - SIGGI verwendet dann durch die Bank die CV für 800 MHz).

​

 

[payce]

6 Verbräuche im StandBy-Betrieb

Nach einigen User-Hinweisen werden momentan auch die Verbräuche im StandBy-Betrieb durchgemessen. Da ich schlecht stundenlang neben dem Messgeräten hocken und sekündlich die Messwerte aufschreiben kann, wird hierfür im Allgemeinen folgendes Vorgehen durchgezogen:

1) Akku-Kapazität vor StandBy wird notiert
2) CPU Spy (zur Bestimmung des DeepSleep Anteils) und BetterBatteryStats (zur Bestimmung der Wakelocks) werden zurückgesetzt
3) Das Phone wird mehrere Stunden ohne am Ladegerät zu hängen liegen gelassen
4) Danach werden alle wichtigen Messwerte notiert.
​

Wichtige Anmerkung: Es ist SEHR pfrimelig, verlässliche Werte hier zu ermitteln. Android machts einem manchmal nicht leicht. Die weiter unten stehenden (Haupt)aussagen sind so gut wie möglich verifiziert. In der Tabelle selbst bitte die Werte mit einer gesunden Varianz betrachten!

​

Die Tabelle kann man nun folgendermaßen lesen:

Zustand sollte klar sein.
Sync, HG-Daten (Hintergrunddaten) und Standort-Service gibt jeweils an, ob diese Option in den Einstellungen aktiviert war oder nicht. Für fast dormancy gilt das Gleiche, nur das dies eben nicht in den Einstellungen, sondern über *#9900# eingestellt wird.
Dauer der Messung und Deep Sleep Anteil -> klar.

​

Hauptaussagen:

• Flugmodus ist wie erwartet der Akkusparer. WENN man auf alles verzichten will, was ein Smartphone smart macht.
• Nur 3G verursacht *bei mir* aufgrund des recht schlechten Netzes sehr viel mehr Leistungsverbrauch im StandBy als nur 2G. Auffällig war auch, das es häufig zu Verbindungsabbrüchen kam und daher der Partial Wakelock von facebook recht lange aktiv war (bis die Daten ankamen). 2G war hier schon viel besser bei mir (sehr gutes Netz). Alternativ 2G/3G (bei mir *etwas* schlechter als nur 2G)
• Die besten Ergebnisse erzielte ich mit einem stabilen, konstanten und starken WLAN. Dabei sollte die WLAN-StandBy Richtlinie *tatsächlich* wohl eher auf "niemals" gestellt sein. Klingt total widersinnig, aber ansonsten werden minimal längere Partial Wakelocks verursacht, da für einen Datenverkehr erst einmal das WLAN reaktiviert werden muss (vor Allem der Partial Wakelock von facebook dauerte immer etwas länger - bei gleicher Anzahl).

Interpretation: Am Wichtigsten scheint zu sein, dass Datenverkehr während des StandBy's möglichst *schnell* abgearbeitet werden kann. Sprich, man braucht eine stabile und schnelle Verbindung mit niedrigem Ping (= WLAN oder bestes Netz). Langsame Verbindungen oder Verbindungsabbrüche sind Gift für den Akku während des StandBy's.

Anmerkung WLAN: Einige User berichten, dass Ihr WLAN-Verbrauch weitaus höher ausfällt! Das kann mehrere Gründe haben: Schlechtes Netz (selten), mehrere *bekannte* WLANs parallel (auch wenn nur eins verwendet wird) und vor allem auch ein aktivierter fast dormancy (dazu etwas weiter unten mehr). Letzteren auf jeden Fall disablen!

Übersicht Partial Wakelocks: *Bei mir* waren folgende Partial Wakelocks normal und fast immer bei den vorderen Plätzen dabei:
Alarm Manager, FacebookService, Activity-Manager-Launch, MAIL_SERVICE
Sporadisch kommt auch folgendes mit höheren Werten vor:
*sync* (Galeriedienst), *backup*, RILJ (Telefon), GTALK_ASYNC_CONN
Und falls die entsprechende App benutzt wird:
JuiceDefender_Service

Falls Eure Partial Wakelocks abweichen, könntet Ihr den verdächtigen Sauger gefunden haben.
​

Weitere Feststellungen:

• Fast dormancy: In Deutschland immer abschalten. Punkt. Fast dormancy *kann* wenig verursachen, muss es aber nicht (vor Allem in Verbindung mit bestimmten Apps - bspw. Skype - oder auch WLAN). Im schlechtesten Fall kann fast dormancy jedenfalls einen enormen Akkudrain verursachen. Und es bringt absolut keine Vorteile. Des Weiteren werden zusätzliche Kernel Wakelocks verursacht (svnet-dormancy). Das verringert den DeepSleep. Also *#9900# und disablen.
• SetCPU + Konsorten "ScreenOff" Profile: Bringen kaum etwas Messbares. Ich habe bei ScreenOff testhalber auf 500 MHz begrenzt. Bei den hohen DeepSleep Anteilen spielt das kaum eine signifikante Rolle.
• NoLED: Die recht beliebte App NoLED wird zur Anzeige von Benachrichtigungen auf dem Display verwendet (ähnlich einer Notification LED). Die Ergebnisse dazu sind recht ernüchternd, vgl. hier: https://www.android-hilfe.de/forum/...des-galaxy-s2.180670-page-3.html#post-2471700
• BLN: Schaut ebenfalls sehr ungut aus. BLN verhindert aktiv den DeepSleep und verursacht damit einen Battery-Drain (~ 200 mW Verbrauch statt 8 mW im Deep Sleep)
  DANKE an grobmutant! Vgl hier: https://www.android-hilfe.de/forum/...des-galaxy-s2.180670-page-4.html#post-2491958
• JuiceDefender: Ist immer ein zweischneidiges Schwert, mit dem man vorsichtig umgehen sollte: Die Datenverbindung wird unterbrochen, aber der DeepSleep wird verringert (Partial Wakelocks "JuiceDefender_Service"). D.h. wenn JD zuviel zu tun hat, wird sogar mehr Akku verbraucht als nötig.
  Wenn man es aber richtig einstellt: Hier die Ergebnisse von pogobi.
  "Richtig einstellen" heißt: JD *NUR* die Daten (+ WiFi) steuern lassen! Nicht Sync/HG-Daten etc. Das ist unnötig! Zeitplan sollte mind. 30 min, eher mehr sein (1 h). Auf keinen Fall JD als 2G/3G Switcher betreiben! Alles, was man nicht unbedingt braucht, sollte NICHT mehr JD gesteuert werden (BT, Helligkeit, CPU...) - ansonsten kann JD dem Akku mehr Schaden als Nutzen. Und man muss auch bedenken, dass nach dem Einschalten des Displays immer mal 2 - 5 sek. vergehen, bis das INet wieder funzt. ^^
  Dafür drückt man seinen StandBy-Verbrauch aber merklich (wenn es mal läuft): Ich konnte bei aktiven 2G-Empfang von 1.8% pro Stunde ohne JD auf 0,8% pro Stunde mit JD Akkuverlust schalten. Aber halt immer mit den enstprechenden Nachteilen ("kein push", kein sofortiges INet).

Typische Verdächtige für Partial Wakelocks und damit einen fehlenden DeepSleep:

*BITTE UM MITHILFE* Wenn Ihr nach obigen Vorgehen eine App entdeckt, die *eindeutig* einen DeepSleep effektiv verhindert und diese hier nicht aufgeführt ist, dann bitte postet dies. Am Besten mit Hintergrundinfos (bspw. erzeugt auch dann Partial Wakelocks, wenn Sync/HG-Daten nicht aktiviert ist; erzeugt Partial Wakelocks wenn Optionen A, B, C aktiviert sind). Am Besten inkl. einer Abschätzung wieviel % DeepSleep verloren gehen. So können wir die typischen Akku-Vernichter hier zusammenführen! *BITTE NICHT* selbstverständliche Apps aufführen (nach dem Motto: "Mein Push-Mail Dienst macht immer Partial Wakelocks") sondern vor Allem eindeutig fehlerhaft programmierte Apps!
​

• Facebook: Erzeugt auch dann Partial Wakelocks ("FacebookService"), wenn Sync und HG-Daten ausgeschaltet sind! Dafür aber nicht sehr viele: Insgesamt wird der DeepSleep Anteil um nur ~ 2% - 4% verringert.
• TouchDown: Erzeugt leider, egal in welcher Einstellung, unnötige Partial Wakelocks, die zu einer ordentlichen Verringerung des DeepSleep um 5% - 20% führen (einstellungsabhängig, d.h. Polling alle 2 h -> 5%, alle 30 min -> 15% und Push ~ 10%). Leider.
• K9-Mail: Verhält sich ähnlich, aber wohl nicht so schlimm wie TouchDown. Bei aktiven Sync (per Poll!) sinkt der DeepSleep Anteil um mehr als 5% (obere Grenze ist von der Polling-Rate abhängig, alle 2h entsprechen ~ 5%).
• NoLED und BLN: Siehe einen Absatz weiter oben.
• PowerAMP: Verursacht durchgängig minimale Partial Wakelocks und vermindert den DeepSleep um ca. 2%. Abhilfe: Automatisches Scannen abschalten.
• 3G Watchdog: Ebenfalls ungefähr eine Verringerung um ca. 2%. Alternative: Netcounter mit langsamen Update (keine PWLs).
• Skype: Verhält sich normalerweise unauffällig, kann aber gerade in Verbindung mit fast dormancy zum plötzliche Akkutod mutieren. Im schlechtesten Fall eine Verringerung des DeepSleeps auf ~ 50% (im Ernst jetzt).

Update-Historie:
20.12: Thread erstellt, erste Einträge
21.12: Alle Kapitel bis auf 2 semi-final
29.12: "Bug" Update, 100 MHz, USB-Ladung, 2G/3G Switching, allgemein aufgeräumt
30.12: "Der CPU" -> "Die CPU"
05.01: Leistung Telefon, Update Pin-Belegung Akku, neues Kapitel 6
06.01: Kap. 6 etwas weiter geschrieben mit Bitte um Mithilfe
08.01: Mini-Update Kap. 6
01.02: StandBy Verbräuche einigermaßen finalisiert, weitere Kleinigkeiten, ToDos aktualisiert
07.02: JUHUUU, endlich sind die Kapazitätsmessungen erledigt!!!

Merkzettel bzw. ToDo:
Weitere Updates erstmal auf Eis gelegt, bis meine Doktorarbeit endlich fertig ist! Sorry!
- Reine CPU Bereitschaft bei unterschiedlichen rates testen (per NoLED oder BLN)
- Verbrauch bei MP3-Wiedergabe im StandBy (= SD-Karte aktiv) - Vorschlag jonathan

 

[aqua1]

Hört sich interessant an. Aber DEN SGS2?

 

[payce]

Hört sich interessant an. Aber DEN SGS2?

Ich personalisiere meine Phones gerne.
Der Streak, der Stein, der SGS2.

"Das" hört sich sooo... ... sooooo ... neutral an. Also wenns stört, änder ichs gerne. ^^

 

[C01]

interresantes Topic, bitte auch mal Ladestrom am USB und am AKKU während Navigon Betrieb messen =)

 

[Randall Flagg]

Kann ich das in meiner Begriffserklärung verlinken?
Das interessiert bestimmt viele User.

 

[tobik1]

Hey payce, schön wieder von dir zu lesen! Warst damals im Milestone Bereich schon super hilfreich.

Mich würde noch gerne der Unterschied im Akkuverbrauch im HSDPA Netz bei vollem Empfang interessieren, im Gegensatz zu abnehmenden Empfang? Wäre super, falls du hier noch Messungen anstellen könntest. Ebenso vielleicht, wenn das Handy überhaupt kein Netz hat, aber permantent versucht, sich ins Netz einzubuchen. Die praktische Umsetzung ist wahrscheinlich leider nicht ganz einfach, ich weiß.


Grüße!

 

[pogobi]

Ah, du machst den Physiker immer noch stolz

Ich bin auch ins SGS2 Lager gewechselt. Die CPU Auswertung ist interessant wie immer! Ich bin überrascht, wie viel Undervolt bringt.

 

[screenager]

danke! sehr aufschlussreich!!!

 

[Melory]

Sind die UV Werte realistisch für eine dauerhafte Auslastung?
Mir ist bekannt das UV Werte von der HW (CPU, Fertigungstoleranzen etc.) abhängen.

 

[UKSheep]

Ich personalisiere meine Phones gerne.
Der Streak, der Stein, der SGS2.

Finde "das SGS2" passt weitaus besser und ich würde nie der SGS2 sagen... Klingt so nach "Der Gerät"... (irgendwie verdammt falsch)

Aber ist nur meine persönliche Meinung.

MfG

UKSheep

P.S. Wir kennen uns ja noch aus dem Streak Bereich und ich freue mich dich hier zu lesen

Sent from my GT-I9100

 

[a-tom]

Sehr interessant! Vielen Dank für diese detailierten Informationen. Jetzt weiß ich auch warum ich die Helligkeit auf dem niedrigsten Wert habe und ein Bild als Hintergrund, es hält so zwischen 1,5-3 Tage. Hatte mal den Christmas HD Live-Hintergrund für einen Tag, da war der Akku fast leer...
Wenn jetzt schon die Fernseher einen Energieeffizienzklassenaufkleber haben warum dann nicht auch Smartphones
...und wenn wir schon dabei sind bin ich dafür das Apps auch eine Energieinformation in der Beschreibung bekommen...

Weiter so, bin gespannt auf die nächsten Ergebnisse. Endlich mal wieder ein Thread zum durchlesen...

 

[molki]

Vielen vielen dank für diesen versuch.

 

[payce]

Uh, krass. Schon so ne Resonanz, obwohl der Thread noch weit davon entfernt ist, fertig zu sein! DANKÖ!!!


@C01:
Also A) habe ich kein Navigon und B) wird das recht schwer, weil man den echten Betrieb nur "in Bewegung" nachvollziehen könnte - ich poste heute noch das Foto des Messaufbaus, dann verstehst Du, warum das nicht so ganz einfach sein würde. (^^)
Generell gilt aber: Beim Ladevorgang wird ein konstanter Strom aus der Buchse gezogen (bei Siyah-Kernel und "Power-USB" (Anzeige "AC" im Akkuverbrauch) sind das 650 mA *Ladestrom*). D.h. der Akku wird nur dann geladen, wenn der gerade benötigte Strom geringer als der Ladestrom ist. Um beim Beispiel mit den 650 mA zu bleiben: Das entspricht etwa 2,6 W Ladeleistung. Und das wiederum heißt, dass DAS SGS2 ( ) bei voller CPU-Auslastung eben doch den Akku weiter leicht entlädt (Bspw. 2,6 W - circa 3 W = -0,4 W).

Dazu schreibe ich mal einen kleinen Part.

@Randall: Super, super gerne! Dank Dir!

@tobik1: Da hast Du Recht, wird nicht einfach werden. Ich muss mal gucken. Vollen Empfang werde ich nicht hinbekommen (vgl. Empfangsprobleme bei entnommenen Akku). Evtl. kann ich mit einem Stück Metall die Antenne blockieren und so den Empfang unterbinden. Problem dabei ist aber, dass das SGS2 immer nur recht kurz versucht, Empfang zu finden (~ 2 sek.). Eine genaue Strommessung ist da recht schwierig...
Das 2G/3G Switching könnt ich noch mit angucken.

@pogobi: Schon, oder? Freu Dich schon mal auf die CPU-Auswertung. Die guckt ganz anders als beim Stein oder Streak aus!

@Melory: Das sind natürlich Werte, die ich für mein SGS2 in Erfahrung gebracht habe. Allerdings *sehr* stabile Werte. Jede einzelne Core Voltage liegt 50 - 75 mV über dem sofortigen Freeze. Ist also recht konservatives und stabiles UV. Läuft bei mir seit zwei Wochen stabil (kein einziger Freeze). Sollte auf die meisten SGS2 übertragbar sein.

@UKSheep und aqua1: OKÄÄÄÄÄÄIII, OKäääi, okäi. (^___^) Ab jetzt das SGS2. ... ... *überredet*
Schade, wird wohl mein erstes neutrales Phone. Naja, ich nenne es ab sofort einfach SIGGI. ^^


Danke nochmal an alle für die positive Rückmeldung und Kritik! Immer her mit Letzterem!

PS: Updates erste Seite:
- Bilder des Messaufbaus gepostet.
- Ein paar kleine Korrekturen.
- SIGGI eingeführt. (^_^) <- Sollte das ("SIGGI") doch eher nerven und/oder verwirren, bitte Bescheid geben.

 

[Randall Flagg]

Ich hab's mal eingebaut, vielen Dank! Ist jetzt im dritten Post, bei den anderen Akku Sachen zu finden.
Ist wirklich sehr gut gemacht, der Thread und sollte gepinnt werden!

 

[payce]

So, gibt Updates. Vor Allem Kap. 5 ist imho spannend. Sind einige Überraschungen drin! Viel Spaß!

Anmerkung: Kap. 2 wird erst etwas später fertig. Das Ladegerät muss ich noch besorgen (liegt bei einem Arbeitskollegen).

Grüße!

 

[motoxtremo]

Super das du dir die ganze Mühe machst das alles zu analysieren und auch noch auszuwerten! Ist wirklich aufschlussreich und interessant zu lesen!

Nachdem ich mein SGS2 (ich personalisiere weder meine Technik Gadgets noch mein Auto ) schon länger gerooted habe und seit kurzem CM7.1 installiert habe, habe ich gestern angefangen mit herabsetzen der maximalen Taktfrequenz und der CPU Spannungen zu experimentieren (Ich hab erstmal deine UV Werte übernommen und auf 1GHz runtergesetzt). Demnächst kommt auch noch Siyah drauf. Zumindest die Spielerei mit der Frequenz und den Spannungen hätte ich wohl nicht angefangen wenn ich diesen Thread nicht gelesen hätte Danke dafür, ebenso wie dafür das du aufgezeigt hast das ein 2G/3G Switch nichts bringt, hatte mir gerade am Tag vorher so etwas mit Tasker zurecht gebastelt

 

[C01]

Ich kann den aufwand und die damit verbundenen einschränkungen fürn Navi versuch schon verstehen, bin selbst elektroniker ;-)

Tolle ergebnisse bis jetzt =)

Wenn ich das alles so lese, dann änder ich einfach nix an meinem verhalten. Ich hab mir heute ne schicke Plexiglas Ladeschale fürn nachttisch gebaut und lads weiter jeden abend =)