[INFO] Fast Dormancy

[Rob2222]

Luppo:
Du schaltest dann ein Stromsparfeature ab, um Strom zu sparen. Wegen diesem festsitzenden Mythos habe ich eigentlich das Thema recherchiert und den Artikel geschrieben.

Ich denke, daß man den Unterschied ohne vergleichbare Bedingungen nicht merken kann. Wie will man ohne vergleichbare Bedingungen einen Unterschied erkennen?
Vergleichbare Bedingungen wären (mindestens): Fester und unveränderter Abstand/Position vom Handy zum Funkturm, gleiche Datenmenge die übertragen wird und auch gleiches Auftreten der Datenübertragung (Menge/Abstand, z.b. 1kB pro Minute).

Ein halbwegs vernünftiger Test wäre es alle Apps die irgendwie Daten übertragen einzufrieren, damit die nicht dazwischenfunken, dann ein Script einzurichten, was einmal pro Minute einen Server im Internet anpingt. Das dann 8 Stunden laufen/liegen lassen, um die Ungenauigkeit der Akku-Anzeige halbwegs auszugleichen.

Das Ganze einmal mit Fast Dormancy und einmal ohne Fast Dormancy. Dabei darf/sollte die Zelle dann aber auch kein netzseitiges Fast Dormancy unterstützten/durchführen.

Und es muß eben echt sichergestellt werden, damit keine anderen Apps Daten übertragen.

Falls wer dazu mal die Muße hat, die Ergebnisse würden mich durchaus sehr interessieren.

Gruß
Rob

 

[EsteChico]

Rob,

Ich sitze jeden Tag 8 bis 10 Stunden am Schreibtisch und nutze dabei das Gerät im Prinzip jeden Tag gleich, (nämlich sehr wenig, es geht um Erreichbarkeit), und seit ich fd abgeschaltet habe, läuft es mit einer Ladung ca. 30 - 40% länger. Also im Prinzip 3 bis 4 Tage vs. < als 2 Tage vorher. Das ist immer noch viel weniger als mein altes Razr, das mir kaputt gegangen ist, aber was solls.

Du hast bestimmt recht, wenn es um normale Nutzung geht, aber im reinen Standby ist fd ein Akkusauger. Es gibt dazu auch einen User hier im Forum, der das mal gemessen hat. Hier ist der link

https://www.android-hilfe.de/forum/...nfo-akkuverbraucher-des-galaxy-s2.180670.html

(runterscrollen zu Standby)

Wie gesagt, mir geht es um die Verlängerung des Standby Betriebs.

 

[Rob2222]

@EsteChico:
Auch wenn ich den Test von Payce sehr sehr(!) schätze, bei seiner Aussage zum Thema Fast Dormancy liegt er in meinen Augen leider sehr daneben.

Mach doch mal Folgendes:
Schalte FD ein und starte das Handy neu.
Dann gehe früh mit einem voll geladenen Handy zur Arbeit und schreibe am Feierabend die verbleibende Energie in Prozent auf einen Zettel.
Dann schaltest Du am Abend FD wieder aus und startest das Handy wieder neu. Am nächsten Tag dann dasselbe ohne FD.
Das mache bitte abwechselnd mindestens(!) 10 mal zusammen.
Ich glaube nicht, daß Du da einen Unterschied von 30-40% sehen wirst.

Es sei denn, Du bist wirklich in einer Funkzelle, die zu "FD-alt" nicht kompatibel ist. Aber sowas kann ich mir jetzt, 2013 schon fast nicht mehr vorstellen.

Prinzipiell ist die Akkuladung vom Montag überhaupt nicht mit der vom Dienstag vergleichbar. Da genügt es, wenn man an einem Tag mal etwas mehr Daten übertragen hat, oder das Handy in einer schlechteren Position zum Funkturm lag, oder der Bildschirm einfach mal 20 Minuten länger an war oder das Handy an dem einen Tag ein Backup oder eine größere Syncronisation gemacht hat. Die Liste läßt sich beliebig weiterführen. Kleine Events, die an einem Tag auftreten und am anderen nicht, können den Stromverbrauch markant verändern.
Gerade beim Thema Fast Dormancy sind scheinbar viele überzeugt, daß Fast Dormancy immer ein Stromfresser ist und man es abschalten muss um Strom zu sparen. Und das wird dann mit Beispielen belegt, die eigentlich gar nicht vergleichbar sind. Super.

Falls es Dich interessiert, kannst Du den Test ja vielleicht mal durchführen, indem Du es jeden Tag umschaltest. Das muß dann aber so oft gemacht werden, daß man eine halbwegs aussagekräftige Statistik ermitteln kann. 5 Tage pro Modi. Besser wären natürlich 10 Tage pro Modi.

Gruß
Rob

 

[EsteChico]

Ich mach das vielleicht ich echt mal, bin nämlich eher so gestrickt, dass ich wissen will und nicht glauben.

Aber die nächsten 14 Tage auf keinen Fall. Morgen fängt ein neues Projekt an, da hab ich weder Zeit noch Nerven .

Aber interessante Kommunikation, danke!

 

[Rob2222]

EsteChico:
Falls Du den Test machst, würde mich ein Feedback sehr interessieren.
Vielleicht liege ich ja auch total daneben und muß mich dann entschuldigen.

Ein Punkt ist halt, daß Kernel Wakelocks überlappend auftreten können(!). Das heißt, Du kannst 60 Minuten Kernel Wakelock A, 60 Minuten Kernel Wakelock B und 60 Minuten Kernel Wakelock C haben und trotzdem war das Handy nur 60 Minuten zusammen wach.

Das heißt, angenommen Du hast täglich 60 Minuten Wakelocks durch Fast Dormancy, und Du schaltest Fast Dormancy dann ab, dann heißt das nicht zwingend(!), daß Dein Handy danach 60 Minuten mehr Deep Sleep gewinnt.

Desweiteren frißt ein S2/S3, wenn die CPU bei ausgeschaltetem(!) Display bei 200MHz rumdümpelt gar nicht sooo viel Strom.
Mein S3 liegt gerade zum Test mit ausgeschaltetem WLAN, ausgeschaltetem mobilem Internet und ausgeschaltetem Bildschirm neben mir, aber mit künstlich erzeugtem Wakelock, also "wacher" CPU seit 30 Minuten rum und hat noch keinen Prozent Akku verloren. (EDIT: Habe das S3 jetzt in diesem Zustand 2 Stunden wach gehalten und 3% Akku verbraucht.)
Das heißt 30 Minuten Wakelock-Zeit an sich, sind gar nicht soo teuer, wie man vielleicht denken mag.
Ein hoher Standby-Verbrauch kommt oft eigentlich eher durch die (regelmäßige) Funkerei (Datenverkehr).

Aus dem Grund bin ich der Meinung, daß 30 oder 60 Minuten Fast Dormancy Wakelocks am Tag keinen merklichen Stromverbrauch erzeugen sollten.
Was Strom verbraucht ist die Funkerei, also der Datentransfer im Hintergrund, und um genau da etwas Strom zu sparen, dafür ist Fast Dormancy.

Ich muß allerdings sagen, ich habe mich zwar recht gut ins Thema Fast Dormancy und auch Akkuverbrauch beim S3 eingearbeitet und von dem Standpunkt macht soo ein großer Unterschied, wie Du ihn beschreibst keinen Sinn. Ich will aber nicht ausschließen, daß ich nicht auch irgendwo irgendwas übersehen haben kann. Und wenn ja, lasse ich mich auch gerne davon überzeugen, daß ich falsch liege. Nur sollten die Vergleiche dann zumindest bitte auch halbwegs(!) vergleichbar sein.

Ein reines Bauchgefühl, also ohne Messungen und ohne über die Vergleichbarkeit nachzudenken, kann man beim Thema Smartphone-Akku in meinen Augen total vergessen.

Viele Grüße
Rob

 

[Luppo]

Um das Thema mal zu konkretisieren, ohne dass wir in Konkurrenz treten zum Akku-Thread, ich spreche von den Wakelocks "multipdp" und "secril_fd-interface", evtl. noch "l2_hsic".
Reden wir da von den gleichen?

 

[Rob2222]

Huhu,

je genau diese drei Kernel Wakelocks steigen mit der Menge an übertragenen Daten über 3G/H/H+ mehr oder weniger gleichmäßig an.
Also mehr Daten, mehr Wakelock-Zeit bei diesen drei Wakelocks.

Nach meinen Beobachtungen überschneiden sich diese drei Wakelocks (mindestens) teilweise. Zumindest nach Versuchen mit diskreten Wakelocks im Siyah-Kernel. Der diskrete Wakelock Modus versucht, die Überschneidungen herauszurechen und erzeugt in der BBS Übersicht wirklich nur den Kernel-Wakelock, der für den Wach-Zustand gerade verantwortlich ist. Wenn Wakelock A das Handy aufgeweckt hat, wach hält und dann etwas später Wakelock B dazuschaltet, während Wakelocks A das Handy eh noch wach hält, dann wird Wakelock B im diskreten Modus gar nicht mehr mit berechnet.
Im normalen Modus werden in dem Fall dann beide Wakelocks A und B in der Kernel Wakelock Übersicht gelistet. Obwohl Wakelock B ja gar nicht an irgendeiner Wach-Zeit Schuld war, aber er existierte halt und wird im normalen Modus mit angezeigt.

Wenn der Modus mit den diskreten Wakelocks richtig funktioniert hat, dann traten die Fast Dormancy Wakelocks eh immer nur dann auf, wenn das Handy eh schon wach war. Das heißt sie haben eh keine zusätzliche Wach-Zeit erzeugt.
Allerdings kamen mir die Wakelocks im diskreten Modus aus dem Bauch generall etwas zu gering vor. Deswegen vermutete ich da evtl. noch einen Bug bei der Implementierung des diskreten Wakelock-Modus. Das konnte ich (mir) aber nie wirklich beweisen.

Viele Grüße
Rob

 

[Bernd82]

Wobei der multipdp-wakelock unabhängig von FD ist.

 

[Rob2222]

Wobei der multipdp-wakelock unabhängig von FD ist.

Ja, multipdp steigt aber auch mit der Menge der übertragenen Daten. Genau wie l2_hsic.

Gruß
Rob

 

[Bernd82]

Das ist richtig. Wird auch nur 1 Datenpaket übers Netz übertragen gibt's nen wakelock von 6 Sekunden, ob FD an oder aus ist dabei völlig egal.

 

[Rob2222]

@Bernd82:
Stimmt! Ich erinnere mich, das schon mal gelesen zu haben.
Weißt Du zufällig was/mehr über den Punkt, ob die secril_fd-interface Wakelocks das Handy nun real wach halten oder ob sie nebenläufig sind und sie damit keine weitere Wach-Zeit erzeugen? Ich habe da leider auch "nur" meine oben schon geschilderten Beobachtungen.
Ich habe mich damals mal durch den Kernel-Quellcode gewühlt, weil ich wissen wollte, wie/wann diese Wakelocks geschaltet werden, aber dieser Wakelock ist im Kernel-Quellcode gar nicht enthalten. Er muß über nicht quelloffene Binaries oder über das Radio selbst erzeugt werden.

Gruß
Rob

 

[Luppo]

ok, ich werde FD nochmal anschalten und das genau beobachten.
FD kann zuverlässig mit dem ro.ril.fast.dormancy.rule = 0 oder = 1 in der build.prop mit anschließendem Neustart geschaltet werden?

 

[Nölde_re_98]

Gibt auch 'FastDormancy Toggle' im Playstore.

Gesendet von meinem GT-I9300

 

[Rob2222]

Huhu,

dieser Test müßte belegen, daß sich die secril_fd-interface und die multipdp wakelocks überschneiden.

Ich habe über einen Zeitraum von 10 Minuten alle 10 Sekunden einen Ping mit 1 Byte Nutzlast gesendet.

Der Test ging über einen Zeitraum von 10 Minuten, davon war das Handy 95% der Zeit wach.

Dabei wurden u.A. folgende Wakelocks erzeugt:
9m48s multipdp
7m35s secril_fd-interface
40s l2_hsic

Damit müssen sich zwangsweise zumindest in diesem Test die Wakelocks überschneiden, denn 17,5 Minuten Wakelocks passen schlecht in 10 Minuten Wake-Zeit.

Die "secril_fd-interface" Wakelocks kommen übrigens in (fast?) allen meinen BBS-Dumps auf eine Wakelock-Zeit von grob 75% der "multipdp" Wakelock-Zeit.

Gruß
Rob

 

[Bernd82]

Weißt Du zufällig was/mehr über den Punkt, ob die secril_fd-interface Wakelocks das Handy nun real wach halten oder ob sie nebenläufig sind und sie damit keine weitere Wach-Zeit erzeugen?

Nein, weiß ich auch nicht, hab das mit den 6 Sekunden auch nur gelesen, glaub auf xda. Wenn ich mir den wakelock "multipdp" ausrechne (sekunden/wakelocks) dann komme ich im schnitt auf 4,5 Sekunden.
BTW: mit FD komme ich länger mit dem Akku hin, natürlich nur Subjektiv da ich nicht getestet habe da ich fast jeden Tag das Handy anders benutze (navigation, runtastic, Radio/Mp3, DLNA usw.) und somit zu viele Faktoren das ganze beeinflussen.


Gesendet von meinem GT-I9100 mit Tapatalk 2

 

[Rob2222]

@EsteChico/Luppo:
Ich habe nochmal über den Punkt nachgegrübelt, ob/wann man mit abgeschaltetem Fast Dormancy vom Handy aus (FD-alt) irgendwie Energie sparen kann/könnte.

In meinen gestrigen Beiträgen, in denen ich gemeint habe, daß das Abschalten von FD den Energieverbrauch ansteigen lassen muss, bin ich davon ausgegangen, daß die Zelle in der man sich befindet kein netzseitiges Fast Dormancy (FD-neu) durchführt. In so einer Zelle verbleibt das Handy dann nach jeder Datenübertragung z.B. 40 Sekunden in den energieintensiven Zuständen DCH und FACH.
So eine Zelle war beispielsweise meine Vodafone-Zelle bis vor einem viertel Jahr (Anfang 2013).
Diese Vodafone Zelle war zwar zu Fast Dormancy kompatibel (das heißt sie hat kein Problem damit, wenn das Handy Fast Dormancy durchgeführt hat), hat es aber von der Seite der Zelle nicht von selbst durchgeführt. Das heißt, wenn man Fast Dormancy im Handy abgeschaltet hat, hatte man wirklich keinerlei Fast Dormancy.


Eventuell macht es akkutechnisch aber doch einen (merkbaren) Unterschied, wenn man sich in einer Zelle befindet, die eh und je netzseitiges Fast Dormancy durchführt. Dann hat das Abschalten des vom Handy initiierten Fast Dormancy (FD-alt) natürlich in dieser Zelle keinen Negativeffekt, da das Fast Dormancy ja von der Zelle selbst durchgeführt wird. Eventuell ist es diese Konfiguration, die bei Euch mit deaktiviertem handyseitigem Fast Dormancy (FD-alt) Akku spart.


Sobald Ihr Euch dann aber in eine andere Zelle bewegt, die kein netzseitiges Fast Dormancy durchführt, hat das Abschalten des vom Handys initiierten Fast Dormancy (FD-alt) dann aber wieder den Nachteil, daß ihr dann aber wieder mehr Energie verbraucht.

Das heißt, mit eingeschaltetem FD-alt (das vom Handy initiierte) ist sichergestellt, daß in allen Zellen Fast Dormancy durchgeführt wird. Entweder vom Netz aus, oder vom Handy aus.

Bei abgeschaltetem FD-alt (das vom Handy initiierte) hängt es dann davon ab, ob die Zelle in der Ihr Euch befindet, netzseitiges Fast Dormancy durchführt.
Wenn ja, habt ihr keinen Nachteil und eventuell spart das sogar Akku.
Wenn nein, dann habt ihr aber einen Nachteil und das ganze frisst mehr Akku.

Und, wie gesagt, meine Vodafone Heimatzelle führt jetzt erst seit ungefähr Anfang 2013 netzseitiges Fast Dormancy durch.


Für einen Test bezüglich Fast Dormancy muß man also eigentlich vier Fälle betrachten/testen/auswerten:
A) FD-alt (vom Handy initiiert) eingeschaltet, in einer Zelle ohne netzseitiges Fast Dormancy
B) FD-alt (vom Handy initiiert) ausgeschaltet, in einer Zelle ohne netzseitiges Fast Dormancy
C) FD-alt (vom Handy initiiert) eingeschaltet, in einer Zelle mit netzseitigem Fast Dormancy
D) FD-alt (vom Handy initiiert) ausgeschaltet, in einer Zelle mit netzseitigem Fast Dormancy

Und das ganze bei möglichst gleichem Traffic. Menge/Größe/Anzahl/Abstand der Pakete.

Mir ist mal wieder aufgefallen, wie sehr man bei diesem ganzen Kram wirklich drauf achten muß, daß man nichts pauschalisiert. Ich hatte die alte Konfiguration (ohne netzseitiges Fast Dormancy) meiner Vodafone-Zelle im Hinterkopf, da kann man mit Abschalten vom FD-alt kein Strom sparen. Also Fall A und B. Und leider kann ich für einen direkten Vergleich von A und B jetzt auch keine Detailtests mehr machen, weil meine Zelle jetzt mittlerweile netzseitiges Fast Dormancy durchführt.

Viele Grüße
Rob

 

[frank_m]

Eventuell macht es akkutechnisch aber doch einen (merkbaren) Unterschied, wenn man sich in einer Zelle befindet, die eh und je netzseitiges Fast Dormancy durchführt. Dann hat das Abschalten des vom Handy initiierten Fast Dormancy (FD-alt) natürlich in dieser Zelle keinen Negativeffekt, da das Fast Dormancy ja von der Zelle selbst durchgeführt wird.

Was ist denn der Unterschied zwischen netzseitigem Fast Dormancy und handyseitigem FD? Ich verstehe noch nicht ganz, warum das Deaktivieren des handyseitigen FDs Energie sparen soll, wenn es von der Zelle dann eh wieder durchgeführt wird. Sind die Algorithmen der Infrastruktur effizienter? Das wäre eine Erklärung.


Und wo ich schon dabei bin: Spielt FD eine Rolle, wenn das Handy keine Paketdatenverbindung über Mobilfunk hat? Also im 3G eingebucht, aber per WLAN online. Hintergrund der Frage: Ich kann mit einem S3 LTE einen signifikanten Unterschied im Akku Verbrauch ausmachen, wenn ich FD deaktiviere. An einem normalen Arbeitstag geht es mit FD von 100% Akku auf 72 - 65%, ohne FD sind es am Ende des Arbeitstages noch 80 - 76% (je nach Nutzung). Aber: Ich bin quasi ununterbrochen per WLAN online. Nur in der Mittagspause und auf den Anfahrtswegen gibt es eine Mobilfunk-Datenverbindung.

 

[EsteChico]

@ Rob:

Was frank_m da beschreibt trifft mehr oder weniger genaus so auch auf mich zu. Den ganzen Tag WLAN, aber mit fd sinkt der Akku einfach schneller.

Aber den reproduzierbaren Test werde ich demnächst noch machen.

 

[Rob2222]

@Frank:

Ich weiß nicht so ganze wie ich das erklären soll, ohne den Artikel im ersten Post wieder neu zu schreiben.

Die Kontrolle wie lange das Handy in welchem Zustand bleibt, obliegt eigentlich dem Mobilfunknetz.

Mit FD-alt, also dem vom Handy aus initiierten Zurückschalten haben sich die Handyhersteller eben eines "Tricks" bedient, schneller aus dem DCH und FACH Zustand herauszukommen. Sie haben sozusagen nach jedem Datentransfer die "Verbindung" gedroppt. Das nenne ich FD-alt, oder auch das vom Handy initiierte Fast Dormancy. Das ist auch das Einzige, was man an und abschalten kann.

Das FD-neu, also das vom Netz aus iniitiierte Zurückschalten, können wir nicht steuern. Entweder die Funkzelle schaltet das Handy nach einer Datenübertragung "schnell" zurück, oder eben nicht/langsam.

Wenn man sich jetzt in einer FD-neu Zelle befindet, die das Handy eh und je schnell zurückschaltet, kann man im Handy FD-alt abschalten, ohne einen Nachteil zu haben.

Befindet man sich in einer Zelle, die noch kein FD-neu durchführt, sondern das Handy nach jeder Datenübertragung eine halbe Minute in den energieintensiven Zustanden hängen lasst, da hat das Abschalten vom FD-alt im Handy dann eben den Nachteil, daß das Handy mehr Strom verbraucht, weil es eben nach jeder Datenübertragung viel länger in den energieintensiven Zuständen rumdümpelt.

Eigentlich sollte das Abschalten von FD-alt im Handy den Stromverbrauch des Handys entweder nicht verändern oder ihn ansteigen lassen. (Nämlich dann, wenn man in einer Zelle ist, die kein FD-neu ihrerseits durchführt).

Zumindest sollte es so sein.


Wenn jetzt aber mehr und mehr Leute schreiben, daß sie aus dem Bauch heraus mit abgeschaltetem Fast Dormancy Strom sparen, frage ich mich, wie das sein kann, denn es ist eigentlich unlogisch, bzw. genau das logische Gegenteil, denn Fast Dormancy existiert ja einzig und alleine darum, um Strom zu sparen.

Ich überlege halt, woher das kommen könnte. Um mit dem Abschalten von Fast Dormancy Strom sparen zu können, muß man sich zumindest in einer Zelle befinden, die ihrerseit FD-neu durchführt, also das Handy schnell zurückschaltet. Das kann man ja mit *#0011# überprüfen, nach wieviel Sekunden man nach einer Datenübertragung im Zustand PCH oder IDLE ist.
Desweiteren müßte das FD-alt vom Handy dann mehr Energie verbrauchen, als es durch schnelles Zurückschalten einspart. In einer Zelle die ihrerseits kein Fast Dormancy durchführt, kann ich mir das eigentlich nicht vorstellen. In einer Zelle, die so oder so FD-neu durchführt, wäre es vielleicht sogar möglich.
Ich habe nur noch keine Idee, wie man das vernünftig, halbwegs belegbar testen kann.

Gruß
Rob

 

[EsteChico]

Na eigentlich kann man das schon testen.

Sobald ich wieder ein bisschen Luft habe, werde ich einfach anfangen, das Gerät frisch geladen und neu gestartet über Nacht im Büro liegen zu lassen. Immer eine Nacht mit fd "an" eine mit "aus".

Naturgemäß müsste es praktisch komplett im DeepSleep sein und nur immer ganz kurz auf die wake calls hin aufwachen. Morgens mache ich dann BBS und CPU Spy screenshots und notiere mir den Ladestand

Nach einer Woche oder zwei wissen wir, ob unser Bauchgefühl uns trog, oder ob in deiner Erklärung irgendwo noch ein Fehler ist.

Ist auch ganz günstig, dass mein Akku nagelneu ist, so dass die Akku - Hardware keine Rolle spielt.