[INFO] Fast Dormancy

[Rob2222]

@EsteChico:
Ja nur wie willst Du bei einem Test halbwegs vernünftig die anderen Parameter festhalten?
Jeder Tag Smartphonenutzung ist irgendwie anders als der davor. Ein paar Minuten mehr telefoniert, ein paar Minuten mehr im internet gesurft, ein paar mehr Nachrichten geschrieben, ein bißchen mehr gespielt und schon hat man einen ganz anderen Energieverbrauch als am Tag davor.
Eigentlich müßte man versuchen, die gleiche Anzahl von Fast-Dormancy-Events pro Tag hinzubekommen. Und ein Fast-Dormancy-Event ist JEDES Ende einer Datenübertragung, wenn danach für 10-60 Sekunden keine weitere Datenübertragung stattfindet. Und selbst wenn man das halbwegs reproduzierbar hinbekommt, dann nutzt man an dem Tag das Handy vielleicht 15-30 Minuten mehr und dann hat man wegen der Mehrnutzung schon einen höheren Akkuverbrauch und nicht wegen Fast Dormancy.


Wenn Du den Test machen willst, würde ich versuchen jeden Tag das Nutzungsprofil ähnlich zu halten. Früh bei Ankunft im Büro eine BBS-Custom-Reference erstellen und dann beim Verlassen (oder noch besser genau 7h oder 8h später) ein BBS-Dump erstellen.
Entweder mit BBS 1.11 oder mit dem letzten BBS RC von 1.12.

Wenn man dann z.B. alle Messungen OHNE FD untereinander vergleicht, bekommt man schon mal ein Überblick, wie "ähnlich" die Nutzung über die Tage überhaupt ist. Hier vermute ich eben schon größere Schwankungen. Aber wenn man mehrere Messungen hat, kann man erkennen, wie groß die Schwankungen sind und eben auch einen Mittelwert bilden.

Das gleiche dann bei mit den Messungen mit FD.

Super hilfreich für die Verleichbareit wäre es, wenn die Messungen alle über den selben Zeitintervall gehen, z.B. 7 oder 8h. Hier wäre evtl. der letzte RC von BBS hilfreich, da er einen aktiven Modus hat und damit könnte man sich alle 30 Minuten eine Referenz anlegen lassen. Abends nimmt man dann die Referenz von z.B. 08:23 und dann die von 16:32, klickt auf aktualisieren und erstellt dann einen Dump, der genau über 8h geht, ohne daß man manuell auf die Zeit achten muss.

Ich würde den Test ja auch gerne selbst durchführen, aber mein Nutzungsprofil und auch das Datenaufkommen vom S3 ist definitiv so unregelmäßig, daß es da bei mir nichts gibt, was man halbwegs vernünftig vergleichen kann.

Viele Grüße
Rob

 

[frank_m]

Sind wir uns denn sicher, dass dieses FD Deaktivieren im Handy genau macht? Vielleicht tut es noch irgendwas in der Konfiguration des Modems, was nach außen nicht unmittelbar sichtbar ist. Das haben wir nicht auf dem Schirm, und darüber lassen sich vielleicht die Unterschiede im Energieverbrauch erklären.

 

[Rob2222]

Huhu,
ja, klar, da kann intern durchaus was hinter verschlossenen Türen passieren.
Was mich nur wirklich verwirrt ist, daß Fast Dormancy einzig und allein ein Energiesparfeature ist.
Eigentlich _sollte_ man nicht gezwungen sein, ein Energiesparfeature abzuschalten um Energie zu sparen.
Ich vermute aber, das bringt wenn überhaupt nur dann was, wenn man sich in einer Zelle mit netzsseitigem Fast Dormancy befindet, da das Abschalten des telefonseitigem Fast Dormancy dann keine negativen Auswirkungen hat.
Bleibt der Nachteil, daß man dann mehr Strom verbraucht, wenn man sich dann in einer Zelle ohne netzseitiges Fast Dormancy befindet.

Gruß
Rob

 

[Luppo]

Ich habe die vergangenen Tage versucht, einen konkreten Unterschied zu aktiviertem und abgeschaltetem FD herauszufinden. Die Nutzung war, soweit man das beeinflussen kann, vergleichbar, gleiche Orte, gleiche Aktivitäten. WLAN war nur selten an, auch nur bei Nutzung. Handy jeweils abends gebootet, bis früh geladen und dann abgesteckt.
Hier die Werte:

mit FD ohne FD
Restkapazität 48% 50%
Verbrauch 3,6%/h 3,2%/h
Laufzeit 14:26 15:23
Deepsleep 11:14 12:06
Awake 3:12 3:17
Screen-On 1:57 1:57
multipdp 0:39 0:51
PowerManagementService 0:31 0:30
secril_fd-interface 0:21 0:30
l2_hsic 0:18 0:17
Akku [2000mAh] 3731mV 3758mV

 

[Rob2222]

@Luppo:
Wenn Fast Dormancy im Handy aus ist, kriege ich bei mir keine "secril_fd-interface" Wakelocks mehr.
Wenn Du die "secril_fd-interface" Wakelocks noch bekommen hast, glaube ich, daß Fast Dormancy bei Dir noch an war.
Dazu würde ich unbedingt versuchen mehr als nur jeweils 1 Messung zu machen.
Ich würde sagen Du hast damit jetzt wohl zwei Messungen mit Fast Dormancy.
Wie hast Du es denn versucht auszuschalten? Hast Du mal unter *#0011# geschaut, wie lange das Handy in Deiner Funkzelle von DCH (über FACH) zu PCH/IDLE braucht?

Gruß
Rob

 

[Luppo]

Ich habe in der build.prop den Eintrag ro.ril.fast.dormancy.rule = [0][1] geschaltet.
Derzeit steht es auf [0], sollte also abgeschaltet sein.
Bei Datenverkehr geht der RRC State von IDLE auf DCH. Nach 30-40 Sekunden geht es auf FACH, nach nochmal 30-40 Sekunden wieder auf IDLE.

 

[Rob2222]

@Luppo:
Hmm, das passt irgendwie alles nicht so wirklich zu meinen Erfahrungen.
Ich weiß nicht, ob das Modem den build.prop Eintrag wirklich beachtet. Ich glaube es richtet sich nach der Fast Dormancy Tabelle, die ich im ersten Eintrag angesprochen habe. Ich glaube, wie gesagt, daß fast Dormancy noch an war, den sonst hätte es keine secril_fd-wakelocks geben sollen. Bei meinem S3 schalte ich das Fast Dormancy durch editieren der Tabelle mit dem SQlite Editor an und aus.

Welches Netz nutzt Du denn?
Die Zeiten ergeben nicht so wirklich Sinn. Evtl. musst Du das noch genauer/öfter beobachten.
Das Schwierige bei der Beobachtung ist immer zu erkennen, wann der Datentransfer beendet ist und wie lange es nach der Beendigung(!) des Datentransfers noch in DCH bleibt. Ich glaube es ist am besten auf das Ausgehen der Pfeile zu achten und dann die Stoppuhr zu starten. Ich vermute die DCH zu FACH Zeit wird kürzer sein. Du musst auch mehrere Datenübertragungsenden beobachten und dann die kürzeste Zeit aus allen Beobachtungen nehmen.
Dazu ist es schwierig im *#0011# zu sein und eine Datenübertragung auszulösen. Ich habe von einem zweiten Handy Whatsapp Nachrichten geschickt bzw. mit einem zweiten Chaton Account vom PC aus Nachrichten gesendet, um Datenübertragungen für die Beobachtung auszulösen.
Zeiten die ich erwarten würde wären unter 15 Sekunden (nach Ende der Datenübertragung, nicht nach dem Wechsel zu DCH!) von DCH zu FACH und dann in unter 30 Sekunden von FACH zu PCH/IDLE, wenn nicht noch ein Datenpaket im Hintergrund reinkommt. Da das ab und zu passiert, ohne daß man es steuern kann, muß man die Beobachtung öfter machen.
Bei aktiviertem Fast Dormancy würde ich den kompletten Wechsel von DCH (über FACH?) nach PCH/IDLE in unter 15 Sekunden nach Ende der Datenübertragung erwarten.

Gruß
Rob

 

[Luppo]

Ich habe nun in der build.prop FD eingeschaltet, unter *#9900# ist es auch aktiv.
Die Zeit von DCH auf FACH beträgt nun ca. 10 sek. und von FACH auf IDLE 5 Sek.
Es läuft erst 20 Minuten, aber secril_fd-interface Wakelocks habe ich keine. Seltsam.
Die Messung ist in der Tat nicht einfach, da man genau die Pfeile beobachten muss. Ich schalte mit dem Task-Manager auf den Browser und erzeuge Datenverkehr.
Dann geht es relativ einfach.

 

[Rob2222]

Huhu,
ja, die Größenordnung passt schon eher.

Wenn Du möchtest, kannst Du auch mal das Tool FastDormancy Toggle probieren, das ändert die Werte in der Tabelle immer zwischen 0 und 5 Sekunden, wobei 0 bedeutet, daß das vom Handy initiierte Fast Dormancy (FD-alt) abgeschaltet ist. Nach dem Umschalten das Handy auch neustarten.

Wenn FD-alt angeschaltet ist, sollte das Handy in ca 5 Sekunden von DCH nach PCH/IDLE kommen. Wenn es FD-alt abgeschaltet ist, hängt es eben von der Funkzelle ab, wie die konfiguriert ist.

Die secril_fd-wakelocks kriege ich immer dann, wenn ich FD-alt im Handy angeschaltet habe.

Gruß
Rob

 

[Luppo]

Gibt es die Tabelle auch auf dem S2?
An- und abschalten geht doch auch mit *#9900# oder?

 

[Rob2222]

Beim S3 gibt's unter *#9900# nix mehr um FD(-alt) an- und abzustellen.
Beim S3 geht es nur noch über die Tabelle.
Und beim S2 gibts die Tabelle meines Wissens wohl auch. Auch steht in den Bewertungen der FastDormancy Toggle App, daß die App auch auf dem S2 funktioniert.
Falls Du Lust hast, weiter zu forschen, müßtest Du schauen, wann Du beim S2 die secril_fd-wakelocks kriegst und wann nicht. Ich würde FD-alt in der build.prop und unter *#9900# wieder einschalten, neustarten und das Handy etwas liegen lassen. Evtl. mit Tasker einen regelmäßigen Ping auslösen. Die Kernel Wakelock-Zeit zählt nämlich nur, wenn der Bildschirm ausgeschaltet ist. Wenn Du den Bildschirm permanent an hast, kriegst Du natürlich auch keine Kernel-Wakelocks.

Gruß
Rob

 

[Bernd82]

Auch steht in den Bewertungen der FastDormancy Toggle App, daß die App auch auf dem S2 funktioniert.

Kann ich auch so bestätigen.

Gesendet von meinem GT-I9100 mit Tapatalk 2

 

[Bogeyof]

Hallo Rob2222,

ich hatte schon einmal hier Hilfe gefunden, ich habe zwar ein LG 4X, aber das Thema FD ist ja wohl für alle ähnlich.
Ich habe inzwischen auf JB upgedated und in einem "hidden menu" einen "engineering mode" gefunden, welcher außergewöhnlich detailliert Auskunft über alles gibt, was beim Datentransfer vorgeht. Dort kann ich jetzt auch (wie Ihr) z.B. die Übergänge DCH -> FACH -> PCH sehen und testen.
Ich habe deshalb auch mal wieder meine telephony.db so angepasst, dass mein P880 statt nach ca. 35 Sekunden von FACH -> PCH in etwa 2-5 Sekunden in diesen Zustand wechselt (Vodafone, Eintrag in der telephony.db ist 300 Sekunden gewesen, Zelle macht es dann wohl nach ca. 35 Sekunden).
Das Interessante an der ganzen Sache ist ein Eintrag "tx_power_level" in diesem Menü, dieser Wert steht bei PCH auf -128 und springt bei DCH auf Werte zwischen -10 bis +10, je nachdem wie gerade der Empfang ist. Bei ca. 85-90 dBm "reichen" anscheinend -10 oder -7, bei 101-107 dBm steigt der Wert auf +4 bis +10.
Der Wert scheint also genau die Übertragungsleistung anzuzeigen, jetzt kommt aber die Überraschung:
Der Wert geht auch bereits im Zustand FACH auf -128. Also scheint auch dieser Zustand bereits sehr wenig Energie zu verbrauchen. Ich frage mich daher, ob es überhaupt etwas bringt, wenn ich den Übergang FACH -> PCH beschleunige, da bei beiden schon "tx_power_level" = -128 ist, also schon wenig "Power" verbraucht wird?

Gruß CvT

 

[Rob2222]

@Bogeyof:
Der Fehler in der Betrachtung liegt darin, anzunehmen, daß nur die Sendeleistung, die in die Antenne geht, markant Strom verbraucht. Dem ist nicht so.

Den relativen Energiebedarf der RRC Zustände, den man in der Literatur findet, habe ich im ersten Post angegeben.

Im FACH Zustand ist das Handy z.B. verpflichtet, den Forward Access CHannel (FACH) zu überwachen, damit es mitkriegt, wenn eine Nachricht für das Handy dabei ist. Siehe z.B. hier.
Aufgrund der relativ komplexen Signal(de)kodierung muß alleine für das Überwachen des FA-CHannels schon viel berechnet/dekodiert werden, um aus den Signalen die an der Antenne reinkommen Daten zu machen, die ausgewertet/verarbeitet werden können. Das heißt das Handy muß die FACH Daten kontinuierlich dekodieren um mitzubekommen, ob vielleicht ein Paket für das Handy dabei ist.

Die kontinuierliche, komplexe Signalverarbeitung frisst in dem Zustand die meiste Energie, nicht die Sendeleistung der Sendeeinheit. Meines Wissens ist das Handy im FACH die meiste Zeit eh nur am "zuhören", da wird nicht (viel) gesendet.

Gruß
Rob

 

[Izzy]

Bei den XDA-Developers findet sich zum Thema "Fast Dormancy" ebenfalls ein interessanter Thread. Wer nur "schnell drüberfliegen" will: FD-alt = "Fast Dormancy" (oder einfach FD), FD-neu = "Network Controled Fast Dormancy" (oder NCFD).

Ein interessantes Zitat, das hier an der einen oder anderen Stelle vielleicht ein wenig Licht werfen oder zumindest ergänzen könnte:

If the network tries to be smart and not just switch to IDLE or PCH after receiving the FD signal, it will cause issues as GSM Association specify that a phone should wait until it notices the FD signal has been taken into account.
That's why some phones have battery issues, as RIL will place a wakelock until the network complied with the FD request.​

(Hervorhebung von mir, nicht im Original). Für nicht-Englischsprecher:

Versucht das Netzwerk smart zu sein, und nach Empfang des FD-Signals nicht einfach (sofort) auf IDLE bzw. PCH umzuschalten, kann dies Probleme verursachen -- da die GSM Association spezifiziert, dass das Telefon zunächst abwarten soll, bis das Netzwerk die Anfrage als ausgeführt bestätigt.
Deshalb haben einige Telefone auch Akku-Probleme, da RIL einen Wakelock hält bis das Netzwerk dem FD-Request Folge geleistet hat.
​

Mit anderen Worten: Die verstärkten Akku-Probleme kommen dann zustande, wenn sich die Telefonhersteller an die Spezifikationen gehalten haben (also erst nach Bestätigung die Umschaltung auf PCH/IDLE tatsächlich durchführen), während die Netzbetreiber "smarter" sein wollten... Hm, im Umkehrschluss bedeutet dies: Zeigen die Telefonhersteller den Stinkefinger, freut sich der Anwender...

 

[Rob2222]

Huhu,
man sollte vielleicht betonen, daß die "Battery Issues" die die da meinen, ein signifikant erhöhter Standbyverbrauch sind. Also ein Stromverbrauch von mehreren Prozent / Stunde.

Die paar typischen Kernel-Wakelocks die wir bei Nutzung von Fast Dormancy hier in Deutschland erhalten sind damit nicht gemeint.

Würde mich zumindest sehr überraschen, wenn wir hier in Deutschland noch inkompatible Funkzellenkonfigurationen haben.

Gruß
Rob

 

[Izzy]

Ooops -- logo, natürlich! Ein paar angezeigte Wakelocks machen noch keinen "Issue". Aber Du hast natürlich Recht, Rob: Macht Sinn, das Kind explizit beim Namen zu nennen -- bevor man falsch interpretiert wird

 

[Rob2222]

Huhu,

ich glaube das heutige Problem von Fast Dormancy ist eher, daß viele Leute die (normal auftretenden) Wakelocks sehen und Fast Dormancy blind wegen den (normalen) Wakelocks abschalten.

Von inkompatibel konfigurierten Funkzellen, wie im Artikel beschrieben, habe ich hier bei uns in Europa noch nichts gelesen.

Das gabs glaube mal vor mehreren Jahren in den Staaten...

Gruß
Rob

 

[Izzy]

Da könntest Du sehr wohl Recht haben. Wobei das nicht erklären würde, warum diese Leute oftmals davon berichten, danach bessere Akku-Laufzeiten zu haben. Zufall, weil sie gleichzeitig noch etwas anderes verändert haben? Klar gibt es (logischerweise) auch gegenteilige Berichte (schlechtere Laufzeit -> FD schnell wieder aktiviert -> alles wieder "in Ordnung"), dennoch finden sich vielerorts erstere Meldungen. Ich habe jetzt allerdings nicht so genau auf Datum und Herkunft geachtet -- diese "Meldungen" fielen mir halt lediglich bei meiner Recherche zum Thema auf.

 

[Rob2222]

Huhu,
ich denke das liegt daran, daß viele Leute ihre Akkuleistung "aus dem Bauch" beurteilen, was in meinen Augen nicht möglich ist, da die Smartphone Nutzung einfach zu ungleichmäßig ist, um sie "aus dem Bauch" beurteilen zu können.
Und wenn man dann einen geringeren Akkuverbrauch sehen will, dann sieht man ihn in dem Fall halt...

Gruß
Rob