[Kernel] Dorimanx v8.43v66 (JB Sammy) + v9/v10.43v66 (CM/AOKP) *04.02.14*

@Stehof

Das ist auch richtig, vor einem Kernelwechsel das Script einmal durchlaufen zu lassen, bevor man den neuen Kernel flasht . Es ist nicht verkehrt, wenn du Einstellungen in der App STweak vorgenommen hast, anschließend einen Reboot zu machen, das mache ich ganz genauso . Will mal hoffen, das die neuen Einstellungen zu den genannten Werten in Post #191 Abhilfe schaffen und sich solch ein SOD nicht mehr ergibt. Jedenfalls habe ich das jetzt mal alle 30 min. mit dem Wecker getestet und es trat kein SOD momentan mehr auf. Sollte sich das jetzt nochmal ergeben, werde ich die unteren Taktraten mit der Spannungsversorgung noch mal um + 25mV erhöhen .

Manchmal passieren unerklärliche Dinge auf dem Handy, welche man nicht erklären kann, zumindestens im ersten Moment nicht. Manche Erscheinungen lassen sich meistens meistens nicht reproduzieren und werden dann durch pure Zufälle erst entdeckt, weil man hier oder dort irgendwelche Einstellungen vorgenommen hat, welche man dann aber wieder verdrängt . Schaun wir mal, ob dein rapider Akkuverbrauch einmalig entstanden ist, oder nochmal auftritt, ich hoffe es jedenfalls nicht .

So, habe heute den nächsten SOD verzeichnen müssen, nach dem mein Wecker heute angegangen ist. Nun gut, komischerweise habe ich das zuvor nicht verzeichnet, aber wer weiß wieso die Einstellungen sich jetzt auf einmal nicht mehr nutzen lassen. Ich habe jetzt mal die Spannungsversorgungen für die unteren Taktraten von 100 kHz - 500 kHz um +25mV angehoben, so dass ich jetzt folgende Einstellungen eingestellt habe:

CPU-Tuning

• 500 MHz: 925 mV > 950 mV

• 400 MHz: 900 mV > 925 mV

• 300 MHz: 900 mV > 925 mV

• 200 MHz: 875 mV > 900 mV

• 100 MHz: 875 mV > 900 mV


Mal schauen wie sich jetzt diese Einstellungen verhalten, um das Handy nach dem Aufwecken aus dem DeepSleep-Modus durch den Wecker nicht wieder zum SOD führen. Werde heute Nachmittag den Wecker wieder stellen und berichten, ob sich wieder ein SOD ergeben hat, wenn der Wecker klingelt, oder diesmal die Anhebung der Spannungsversorgung zur Abhilfe gereicht hat . Vielleicht werde ich dann auch nochmal den DorimanX Kernel v8.31 installieren, um zu vergleichen, ob sich bei dieser Version v8.31 die SOD´s ebenfalls mit den unteren Taktraten ergeben, oder dieser stabiler damit umgeht und läuft .

Update

Nach Änderung der unteren Spannungsversorgungen der Taktungen von 100 kHz - 500 kHz heute morgen (siehe vorherigen Beitrag), habe ich nach dem Weckvorgang heute Nachmittag keinen SOD mehr gehabt . Ich will aber noch nicht in Jubelstürme verfallen und den weiteren Weckvorgang morgen früh abwarten, ob dieser ebenfalls reibungslos verläuft. Sollte dem so sein, wären die unteren Taktungen mit den neuen Spannungsversorgungen dann vielleicht die richtigen, für die CPU der Gruppe 3 .

Ich habe neulich den CORTEXBRAIN Background Service deaktiviert. Hatte immer das Problem, dass das aufwachen sehr lange gedauert hat und auch gelegentlich zu SODs geführt hat. Bisher fühlt sich alles deutlich besser an und einen SOD hatte ich auch nicht mehr.

Nachtrag

Wie gestern schon angekündigt, habe ich heute morgen wieder einen Weckvorgang durchgeführt, der wie gestern Nachmittag ebenfalls reibungslos verlaufen ist, also keinen SOD zur Folge hatte . Somit denke ich, das die gewählten Einstellungen in Post #202 zum gewünschten Erfolg geführt haben und das Handy stabil aus dem DeepSleep-Modus Aufwachen lässt .


@Boxter

Dieses Verhalten habe ich trotz eingeschaltetem CORTEXBRAIN Background Service bis jetzt nicht wahrnehmen können und kann durchaus dazu sagen, dass das Aufwachen des Handys jederzeit ohne Zeitverzögerung stattfindet . Was ich gestern aber wieder ausgeschaltet habe, war unter GPU der "VPLL MODE", den ich vor 3 Tagen testweise mal zugeschaltet hatte, um die Grafiken besser darstellen zu lassen, was bei mir aber nur zu mehr Rucklern und Laggen geführt hat.

Ja, ich hatte das Problem früher auch nicht, erst seit den letzten paar Kernel-Builds. Vielleicht hängt es mit den Settings zusammen, wobei ich die eigentlich nicht geändert habe. Na ja, über Nacht im Flugzeugmodus werden auch ohne CORTEXBRAIN Background Service nur ca. 2 % Akku verbraucht. Einen großen Nutzen konnte ich mit aktiviertem Service daher eh nicht wirklich feststellen...

@Boxter

Ich kann dir leider jetzt auch keinen Unterschied präsentieren, welche dafür oder dagegen spricht, das der CORTEXBRAIN Background Service ein- oder ausgeschaltet ist. Jedenfalls läuft der CORTEXBRAIN Background Service bei mir im eingeschalteten Zustand ohne Probleme und Auffälligkeiten .

Neue Dorimanx Kernel v8.33 und v9.33 herausgekommen, sind aber nach wie vor ein Major Update "BETA-TEST".

XDA-Developers Thread: http://forum.xda-developers.com/show...hp?p=25262098#


Ausschließlich nur für JB CM/AOKP 10.1 ROMs

Kernel_Siyah-Dorimanx-V9.33-JB-CM-AOKP-SGII-PWR-CORE:
CWM: http://dorimanx.shine.sk/kernels-jb-...I-PWR-CORE.zip


Ausschließlich nur für JB Mali StockROM und AOSP ROMs

Kernel_Siyah-Dorimanx-V8.33-JB-SGII-PWR-CORE:
CWM: http://dorimanx.shine.sk/kernels-jb-...I-PWR-CORE.zip


Kommentar zur neuen 33-Version von @Phil:

We worked many days to build/test this update, so here it is!


Changelogs (Kernels have same changes):

*I have ported massive update to MMC code from 3.10.RC5 Google Android
It's responsible for SDCARDS and IDLE sleep, battery improved in deep sleep.
drain is very low, and wakeup is fast.
*Ported many ARM code for android from 3.10.RC5
*Alucard created new CPU GOV, DARKNESS! it's based on nightmare but more simple and fast, basic configs but very complex structure.
*Alucard updated nightmare gov and improved stability, so far was stable in tests.
*I have Reverted to Linaro 2013.05 GCC 4.7.4 as it's made for JB android, and GCC 4.8.1 is not optimized as should, so more stability now.
*Patched with 3.0.83 Main stream patch.
*Ported good update to ZZMOOVE CPU GOV.
*Ported all new updates from CM-KERNEL.
*Ported many code updates to FS/SYSTEM/TIME/TICK/KERNEL from 3.10.y main stream and 3.10.RC5 Google Android tree.
*Alucard fixed Cortex Logic and added new GOV options in STweaks.
*Pulled updates from SAMMY SG3 Source tree.
*Optimized WIFI config.
*Voku ported good updates to RAM/SYNC/BOARD
*Cleaned Junk logs in dmesg every 2sec. less noise more battery saved
*Allowed to use MIN voltage 800mv for GPU and CPU, but for MANY users it's will lead to SOD right away or in minutes.
but for some LUCKY users, it's can be stable. but UV is not supported so use, get stuck and dont report
*Tuned LowMemKill code to be more aggressive in case there is no RAM left. + tuned kernel RAM tuning.
*Merged code to allow to use our device as external CDROM, using special app that mount ISO IMAGE as USB drive and we can boot other PC/SERVERS with it,
but need to disable the USB AUTO MOUNT in STweaks to be able to use that APP, this is for people that need it,
and know what to do with it, in other words for IT PRO tech/engineers.


For me system is STABLE, i am with latest ROOTBOX nightly.

danke SaGaS... ich werd den 8.33 erst flashen, wenn DU ihn für gut befunden und freigegeben hast

Und bitte halte Deine Einstellungen auf #168 immer aktuell und lass alle Änderungen einfliessen - das ist (mit Sicherheit nicht nur) meine Vorlage!!!


Kurze Rückmeldung: V 8.32 läuft inzwischen fehlerfrei und akkuschonend... derzeit zwar "nur" 4 - 7 Stunden längere Akkulaufzeit; aber nach einigen Ladezyklen wird sich das möglicherweise noch steigern.
Muss gestehen, dass ich erst seit dorimanx diese android-Energiesparmodus aktiviert habe und deshalb gar nicht sagen kann, ob die Laufzeitverlängerung auf den dorimanx zurückzuführen ist oder doch (überwiegend) auf den Energiesparmodus.

Diese seltsame Akkuentladung über Nacht von 60% auf 0% ohne irgendwelche Anzeichen ist seitdem nicht mehr aufgetreten. War hoffentlich eine einmalige Geschichte!

@Stehof

Werde ich sehr gerne tun und habe auch schon an den Spannungsversorgungen wieder etwas nach unten korrigiert, um zu schauen, wie die sich jetzt mit der neuem DorimanX Kernel v8.33 vertragen, den ich gerade geflasht habe .

Ich denke hier kommen beide Änderungen auf deinem System zum Tragen. Der Energiesparmodus, da dieser nur noch ein höchst Taktrate von 1000 kHz zulässt (mehr wird meiner Meinung auch gar nicht benötigt) und zum Anderen auch der DorimanX Kernel, der zugegebenermaßen, sich viel freundlicher und besser verhält, als der PhilZ Kernel . Dies kann ich ohne Einschränkungen aussagen, da ich zuvor ja immer auf dem PhilZ Kernel unterwegs war, aber nie die Akkuverbrauchswerte erzielt habe, wie ich sie jetzt mit dem DorimanX Kernel wahrnehme .

Welcher Kernel sich ebenfalls besser geschlagen hat, als der PhilZ Kernel, war der Apollo Kernel (seit gestern ein Update auf die Version v4.8 herausgekommen und jetzt auch mit englischem CWM , siehe Eingangsthread ). Die 5 unterschiedlichen Version vom Apollo Kernel sind ja auch mit unterschiedlichen vordefinierten UV-Werten versehen, die es möglich machen, ebenfalls mit heruntergesetzten Spannungsversorgungen die Taktungen zu beeinflussen und durch eine Konfigurator App (ähnlich STweaks) zusätzlich Einstellungen vorzunehmen. Bei mir lief der Apollo Kernel v4.7 V1 ohne Probleme (als ich ihn testete), wobei der V2 wiederrum nicht installiert werden konnte, da er mit so extremen UV daher kommt, das mir mein Handy gleich gefreezt ist .

Es ist schön zu Lesen, das sich deine rapiden Akkuentladungen erst einmal behoben haben, welcher Grund sie auch immer ausgelöst haben. Es ist tatsächlich so, das sich gewisse Dinge wie ein Buch mit 7 Siegeln darstellen, ohne erklärbare Gründe nennen zu können. Es sind oftmals Kleinigkeiten, die bei bestimmten Flashvorgängen einfach keine Berücksichtigung finden und das fängt meistens schon mit fehlenden Wipes an . Natürlich können auch Flashdateien für Probleme nach dem Flashen verantwortlich sein, da diese schon z.B. fehlerhaft heruntergeladen wurden, aber trifft nicht auf die meisten zu . Zeit nehmen, Geduld und ein glückliches Händchen haben, sind die Tugenden für erfolgreiche Flashvorgänge und stellt wirklich keine Magie da, sind Flasherregeln .

SaGaS testest du den neuen gov mal ?

Bei mir sieht es so aus als wenn er einfach ultra schnell auf 1ghz taktet ... Und den Rest der Zeit auf 200mghz bleibt.

Sonst kann ich nur sagen das die Version wie alle andern einfach unglaublich geil läuft !

Habe mir jetzt einen 2000mah Akku gekauft weil ich mein s2 noch einige Zeit weiter benutzen werde ! Hoffe die Leute entwickeln weiter am s2 !

Eines gleich vorweg, der DorimanX Kernel v8.33 läuft sehr gut und sehr stabil, also wenn du jetzt auf den Starschuss gewartet hast @Stehof, dann jetzt aber los .

Habe mich seit gestern mit den Spannungsversorgungen für die Taktraten im Bereich von 100 mHz bis 500 mHz weiter auseinandergesetzt, da ja bei mir, wie wahrscheinlich auch bei anderen, bei zu niedriger Spannungsversorgung der Taktraten ein SOD ausgelöst wurde, wenn man den Wecker genutzt hat und dieser dann angegangen ist. Nach etlichen Versuchen ist es mir endlich gelungen, den Fehler zu lokalisieren, welche Spannungsversorgung bei welcher Taktung diesen SOD auslöst . Es ist die 500 mHz Taktung, die auf keinen Fall unter 950 mV eingestellt werden darf (magische Grenze, wie die 1000 mHz mit 1075 mV), bei einer installierten CPU der Gruppe 3.

Leider hatte ich das Pferd von der falschen Seite aufgezäumt, wodurch meine experimentellen Versuchen auch ein wenig in die Länge gezogen wurden, da ich mit den unteren Taktraten von 100 mHz bis 200 mHz begonnen hatte, anstatt mich von den 500 mHz auf 100 mHz runter zuarbeiten . Nicht desto trotzt, ist es mir jetzt gelungen, stabile Spannungsversorgungen für die Taktraten von 100 mHz bis 500 mHz für die CPU der Gruppe 3 festzulegen, wo das Handy stabil läuft, welche aber wahrscheinlich noch von 100 mHz bis 400 mHz in -25 mV Schritten reduziert werden könnten.

Daher komme ich jetzt auf folgende CPU-Tuning Einstellungen für die Taktraten von 100 mHz bis 500 mHz:

CPU-Tuning

• 500 MHz: 950 mV (FESTWERT - nicht weniger einstellen)

• 400 MHz: 925 mV (*variabel - ?)

• 300 MHz: 900 mV (*variabel - ?)

• 200 MHz: 875 mV (*variabel - ?)

• 100 MHz: 850 mV (*variabel - ?)

* = Könnte noch um - 25 mV / -50 mV heruntergesetzt werden - einfach ausprobieren und durchtesten, wem es wichtig ist (ich persönlich bleibe jetzt erst einmal auf den stabilen Werten, wie angegeben ).


@kehne
Meinst du den neuen ZZMOOVE CPU Governor? Ich gehe mal davon aus, das du diesen dann schon nutzt . Wie empfindest du den Akkuverbrauch und schätzt die Performance ein? Läuft alles stabil, smooth und laggt nicht?

jawoll.... i'm flashing

Genau den meine ich. Ich habe alles auf den normalen werten gelassen. Nur den gov geändert. Performance hat sich nicht merkbar geändert. Zum Akku kann ich keine Aussage treffen. Jedoch sehe ich bei CPU Spy das meine CPU 60% von der Zeit die das display an ist auch auf der höchsten Stufe bleibt.

Display aus habe ich den sleepy. Denke daher wird sich der Akku auch nicht merkbar ändern. Display war heute fast nur aus.

Werde morgen mal zwei S2 nebeneinander legen und dann schauen, was dort geändert wurde...

Sagmal geht deine Cpu auf 100mghz runter ?! Selbst wenn ich 100 einstelle geht die nie so tief.

War etwas ruhig in letzter Zeit, habe aber immer mitgelesen und schreibe mal ein paar Sachen zu Dingen, die ich noch im Kopf habe:

Ich lasse alle Einstellungen bezüglich CPU (Governor), RAM und I/O-Schedular so wie sie mitgeliefert werden. Das Dorimanx-Team hat diesbezüglich viel Zeit in die Optimierung gesteckt, so viel Zeit wie ich dafür gar nicht aufwenden möchte und kann. Der Hyper-Gov ist ein super smoothes Ding und auch ziemlich Akku-Freundlich. Auch die ganzen Einstellungen bzgl. der Governor Settings werden immer wieder optimiert, so dass die Werte die mitgeliefert werden echt gut sind.

Der Row Schedular ist speziell für den Dateizugriff (Read/Write) für mobile Endgeräte optimiert. Der CFQ ist ein Standard Linux Schedular, auch von Samsung als Standard genutzt, der aber nicht unbedingt optimal ist für ein mobiles Endgerät. Bei Smartphones ist es vorallem wichtig, dass Dateien schnell gelesen werden (Read), Write ist in der Priorität hinten anzuordnern. Der Row hat ungefähr die gleichen Write-Bechmark-Werte wie der CFQ, jedoch wesentlich schnellere Read-Benchmarks: http://www.spinics.net/lists/linux-a.../msg04911.html
Der ROW-Schedular wurde extra nach den Bedürfnissen eines Handys entwickelt.
Von daher sehe ich keinen Grund Governor/Schedular zu ändern. Vielleicht wird der Darkness oder Nightmare mal der neue Stock-Governor, aber das lasse ich besser die drei vom Dorimanx-Team entscheiden.

UV muss halt jeder selber wissen. Ich kann auf jeden Fall die 500 Mhz @ 950mV vollkommen bestätigen (obwohl ich Group 4 bin), das ist wohl irgendwie seit ICS so. Unter GB konnte man drunter gehen.

100 Mhz als zusätzlichen CPU-Step würde ich nicht einstellen. Habe jetzt schon mehrmals gelesen, dass das mehr Batterie kosten soll, als dass es spart.

VPLL ist "nur" dazu da, dass man die GPU übertakten kann (330-520 MHz). Ist der Harken nicht gesetzt, kann man die Steps zwar trotzdem einstellen, werden aber nicht genutzt, sondern max. 267 MHz.

Dass der Cortex Service wirklich für Freezes verantwortlich sein soll, kann ich mir nicht vorstellen. Ist dieser aus, werden alle Einstellungen/Tweaks die darunter in der App aufgelistet sind nicht genutzt. Der TCP-Ram-Tweak ist übrigens Standard ausgestellt, weil der fehlerhaft war und hier und da mal zu SODs führen konnte. Keine Ahnung warum sie ihn dann nicht erstmal komplett rausgenommen haben. Vielleicht weil es bei einigen läuft und diejenigen User davon profitieren.

Generell zu Freezes/SODs: Häufig ist gar nicht der Kernel schuld, sondern Buggy-Roms oder auch fehlerhaft programmierte Apps. Das kommt häufiger vor als man denkt

Zum 9.33er: Läuft super unter der SlimBean-Rom. Generell läuft die die SlimBean wesentlich flotter als jegliche Sammy-(Custom)-Rom. Ich bin echt froh den Weg ins AOSP-Lager eingeschlagen zu haben. Auch vom nicht vorhandenen Project-Butter in den AOSP-Roms merke ich gar nichts. Samsung baut halt zwar super Handys, aber Software-technsich haben sie es echt nicht drauf. Allein schon die Touchwiz-Oberfläche ist so schlecht programmiert, dass sie selbst auf dem neuen S4 nicht komplett ruckelfrei daher kommt. Das ist echt schon schwach. Naja, der Touchwiz-Launcher war eh das erste was ich an meinem Handy ersetzt habe.
Nochmal zum Kernel: Am geilsten finde ich allerdings die Möglichkeit den Kernel nun (seit x.33) als USB-Drive zu nutzen. Z.B. eine Win7 Installation sollte wesentlich flotter per USB von statten gehen, als von CD/DVD. Und dazu einfach sein Handy nehmen zu können, ist schon irgendwie ganz witzig. Auch einfach eine kleine Linux Distribution draufzupacken als Notfall-System ist kein schlechtes Anwendungsszenario

Edit @ Kehne: CPU-Spy ist noch super neu und Buggy, das ist bei mir auch mit der hohen CPU-Auslastung und schlicht ein Bug der App.

@kehne

Die 100 mHz Taktung wurde bei angesprochen, wenn auch nicht lange (31 sek.), schau dir dazu mal die letzten beiden Screenshots in folgendem Post #172 von mir an (war allerdings noch der v8.32):

PPC-Post: http://www.pocketpc.ch/samsung-galax...ml#post1757596

Ich hätte mal folgenden Vorschlag zu unterbreiten @kehne, vielleicht hat ja auch @Stehof Lust mit zu machen . Wenn du bereit wärst, mal zeitgleich zu mir den Akkuverbrauch für den DorimanX v8.33 zu testen, dann übernehme doch mal die Einstellungen aus meinem Post #168 (außer das du CPU-Tuning (Awake) statt des Nightmare Governor den ZZMoove Governor einstellst und das Hotplugging auf "Disabled" einstellst):

http://www.pocketpc.ch/samsung-galax...ml#post1755670


Wenn @Stehof eventuell ebenfalls mal testen mag, dann statt des eingestellten Nightmare Governor, den ebenfalls neuen Darkness Governor nimmt, wo du dann aber das Hotplugging unter CPU-Tuning (Awake) auf "Enabled" stehen lässt , da der Darkness Governor auf dem Nightmare Governor basiert. Alle anderen Einstellungen belassen wir so, wie sie in Post #168 von mit angegeben sind, damit wir identische Einstellungen haben.

Somit könnten wir gemeinsam 3 verschiedene Governor (Nightmare, ZZMoove und Darkness) zeitgleich auf Herz und Nieren testen und dabei auch zeitgleich den Akkuverbrauch in einer bestimmten Nichtnutzungszeit ermitteln, welche sich aus dem DeepSleep-Modus der jeweiligen Governors ergeben. Hierbei spielt für mich tatsächlich die Nichtnutzungszeit eine ganz entscheidene Rolle, wo man erkennen kann, ob das Handy tatsächlich auch einen adäquaten Akkuverbrauch erzeugt, wenn es nicht genutzt wird.

Sollte dann doch ein Wakelog entstehen, welche z.B. bei mir durch das Abfragen nach dem Wetterstatus alle 3 Stunden erfolgt, wie hierzu dann von den Governors die entsprechenden Taktraten genutzt werden und wie lange dann die Prozesse laufen, bis das Handy wieder in den DeepSleep versetzt wird und was dabei dann für ein Akkuverbrauch generiert wird.

In der Summe der Stunden, welche ich meistens mit 10 oder 12 Stunden wähle (in der Zeit wird das Handy von mir nicht angefasst), lässt sich dann ein DeepSleep ermitteln, welcher tendenziell aussagt, ob man einen gute DeepSleep-Phase hatte, oder das Handy aufgrund von unerwünschten Wakelogs ständig aufgeweckt wird, weil irgendwelche Prozesse im Hintergrund laufen, um Datenabgleiche durchzuführen.

Um den DeepSleep ermitteln zu können, nutze ich hierfür die App "CPU Spy", welche kostenlos im Google Play Store heruntergeladen werden kann. Wenn sich alles ruhig verhält auf dem Handy in der Nichtnutzungszeit, kommt man immer auf einen DeepSleep von 98% - 99%, was zeitlich ungefähr 3 - 5 min. ausmacht, die man als Differenz zu der Nichtnutzungszeit von 10 oder 12 Stunden generiert. Sollten aber ständig rege Hintergrundaktivitäten auf dem Handy in der Nichtnutzungszeit ausgeführt werden, werden die Ergebnisse deutlich unter 98% liegen, welchen man dann auf den Grund gehen kann, z.B. mit der App BetterBatteryStats .

Der ganze Test soll letztendlich sicherstellen, das man immer auf einen DeepSleep von 98% - 99% kommt, wodurch sich dann auch realle Akkuverbrauchswerte feststellen lassen, wenn man tatsächlich sein Handy richtig nutzt und nicht zusätzlich durch Apps, die in der zwischenzeit ebenfalls Akkuverbräuche generieren, weil sie sich ständig im Hintergrund mit irgendwelchen Servern verbinden, um Daten auszutauschen.

Also wenn ihr interessiert seid, dann gebt mal Bescheid und dann starten wir gemeinsam mal solch einen Test. Ich würde dann auch eine Nichtnutzungszeit von 10 Stunden vorschlagen, die man locker auch über Nacht durchführen kann, da man hier ja meistens auch schläft und das Handy nicht nutzt . Wir können auch zu unterschiedlichen Zeiten damit beginnen, da ich denke, wenn man sich den neuen DorimanX Kernel erst geflasht hat, ich gestern, das dann mindestens 2 - 3 Ladezyklen erst durchgeführt werden sollten, um auch den Akku richtig auf 100% zu kalibrieren, bevor dann solch ein Test gestartet wird . Was meint ihr dazu!

An sich eine Gute Idee, leider verursachen Unterschiedliche Roms oder unterschiedliche Apps auch einen einen anderen Verbrauch, chrischaan und ich sind z.b. beide auf der SlimBean.

Habe Facebook und Whats-App Installiert und Internet an. Komme auf einen DeepSleep von 96-98% wenn mein Handy über Nacht nichts machst.

Dazu glaube ich das man einen Gov nicht vom DeepSleep abhänig machen sollte. Ich persönlich nutze mein Handy mehrere Stunden am Tag. Auch das Verhalten beim Öffnen von Apps usw. finde ich wichtig.
Dazu kommt ja noch die Tatsache, das Nachts der Bildschirm aus ist. Ich habe den ZZ bis jetzt nur als Screen On Gov genommen. Daher spielt er beim Deep Sleep ja eh keine Rolle.

Ich habe z.b. schon kurz den Hyper und den neuen ZZ miteinander verglichen. Vom Benchmark Ergebnis war dort schon ein Unterschied:


Hier sind einfach mal Bilder


Was sagt ihr dazu. Genau der gleiche Test im genau gleichem Zeitabstand:


Hyper:

https://picasaweb.google.com/lh/phot...eat=directlink

https://picasaweb.google.com/lh/phot...eat=directlink


ZZ:

https://picasaweb.google.com/lh/phot...eat=directlink

https://picasaweb.google.com/lh/phot...eat=directlink

@kehne

Haste Recht , macht irgendwie dann keinen Sinn, wenn du auf SlimBean unterweg bist und ich auf der NeatROM . Wenn du dann auch noch Facebook und Whatsapp nutzt, dann sind ja schon einige Wakelogs vorprogrammiert, die deinen Akkuverbrauch mehr beeinflussen, als auf meinem Handy, da ich solche Apps nicht nutze . Einen Vergleich können wir somit dann nicht heranziehen, um dann bestimmte Governors auszutesten. Gebe dir auch in diesem Punkt Recht, das der Governor nur bedingt Einfluss auf den DeepSleep hat, obwohl die Taktungen dann vom Governor übernommen werden, wenn das Handy durch einen Wakelog aufgeweckt wird .

Habe heute morgen noch zwei Screenshots gemacht, um dir mal aufzuzeigen, das die untere 100 mHz Taktung bei mir schon rege genutzt wird, wenn mein Handy aus dem DeepSleep geholt wird, oder ich bestimmte Apps ausführe, die keine höhere Taktung benötigen, wie z.B. eine SMS schreiben:




Lass dich jetzt aber nicht von der allgemeinen DeepSleep Zeitangabe verwirren, denn mein Handy war nicht in diesen ermittelten Werten die ganze Zeit im DeepSleep , hatte nämlich zwischendurch auch ein paar Dinge auf dem Handy ausgeführt . Will dir mit den Screenshots nur aufzeigen, das bei mir auf dem Handy auch die eingestellte 100 mHz Taktung durchaus zum Einsatz kommt, weil du ja gestern danach fragtest .

Sage mal, was hat das eigentlich mit den Benchmark-Tests auf sich, habe dieses Kapitel eigentlich noch nie so richtig behandelt, von daher kann ich deine eingestellten Screenshots zu den beiden Governors nicht so richtig zuordnen, bzw. werten.

Einfach gesagt, je höher die Punkte sind desto "schneller" arbeitet die CPU, habe wirklich nur einen CPU-Test ausgeführt, weil der Rest ja nichts mit dem Gov zu tun hat.

Wie man sieht arbeitet der ZZ "besser", zumindest die Performance angeht. Dafür nutz der ZZ die 100mHz Taktung gar nicht. Das finde ich in der Tat schon erstaunlich, weil ich der Meinung war, das der Hyper eigentlich direkt ohne große Wartezeiten hochtaktet, demnach sollte die Leistung ja eigentlich höher sein.

Mir fällt auch sonst nichts mehr ein, wie man das nun bezüglich Akkuverbrauch testen könnte. Ich habe ein besseres Gefühl wenn die 100mHz Taktung benutz wird. Daher habe ich nun erstmal den Hyper wieder an.


Und mal was ganz anderes: Wir reden hier über so kleine Werte ... Die Frage ist auch ob man bei dem normalem Betrieb überhaupt etwas davon bemerkt.

@kehne

Und mal was ganz anderes: Wir reden hier über so kleine Werte ... Die Frage ist auch ob man bei dem normalem Betrieb überhaupt etwas davon bemerkt.

Ich glaube nicht , von daher habe ich ja jetzt auch Spannungsversorgungen für die ganzen Taktungen gewählt (siehe Post #168 welche ich längere Zeit getestet habe), womit das Handy absolut stabil läuft, weil hierüber schon ein wenig an Ersparnis heraus zu holen ist, als zu den Standardwerten, die bei der Installation des DorimanX Kernel eingestellt werden. Im Gegensatz zu @chrischaan, dessen Meinung ich aber sehr schätze, glaube ich schon, das bestimmte Anpassungen zu den Standard-Einstellungen, insofern man sie nachvollziehen kann, Einfluss nehmen können, sonst wären die Optionen in der STweak App nicht gegeben.

Da ich kein OC-Freak bin (geht zu Lasten der CPU), sondern eher die smoothere Variante bevorzuge, ist UV schon eine Option, welche mit bedacht eingestellt, zu Verbesserungen im Verbrauch führen können, vorausgesetzt, wenn auch andere grundlegende Dinge durchgeführt wurden, wie z.B. die Entfernung von sogenannten Bloatware-Apps. Mit Sicherheit verfolgt hier jeder ein anderes Muster, wonach er einen Kernel bemisst, was dieser umsetzen muss und wie er letztendlich auch auf dem Handy wirkt.

Eine ganze Zeit lang habe ich mich dem PhilZ Kernel verschrieben gehabt, der ja eigentlich als StockKernel daher kommt, ich aber eine ganze Zeit lang glaubte, das dieser ebenfalls modifiziert so war, das er einen gewissen Einfluss auf den Akkuverbrauch nimmt . Dank @chrischaan, öffnete mir die Augen , handelt es sich tatsächlich aber nur um einen erweiterten StockKernel, der mit Root und fantastischem Recovery Interface ausgestattet wurde, mehr nicht. Als mir das bewusst wurde, hatte ich als erstes dann den Apollo v4.7 mal als Vergleich zum PhilZ Kernel getestet und siehe da, der Apollo v4.8 V1 erzielte zum Philz viel bessere Akkuverbrauchswerte.

Von daher kam ich dann auch wieder auf den DorimanX Kernel zurück, wo ich wusste (hatte ihn ja schon mal eine Zeit genutzt), das hier mit der App STweak einige Dinge beeinflussbar waren, um diesen DorimanX nach meinen Wünschen auf dem Handy anzupassen. Ich kann nur sagen, was du @kehne und auch @chrischaan schon ausgesagt haben, dieser DorimanX Kernel v8.33 ist echt ein Top Kernel geworden, der auch den PhilZ in den Schatten stellt, außer das geniale Recovery Interface, welches eines, wenn nicht sogar das Beste Interface ist, was ich je gesehen und benutzt habe.

Was die untere 100 mHz Taktung betrifft, so ist diese für mich schon wichtig, das sie mit eingebunden ist, da hierüber nur kleine Aufgaben abgearbeitet werden, welche keine höheren Taktraten benötigen, aus meiner Sicht schon für einen geringeren Akkuverbrauch sorgen. Warum soll ein Dienst nicht die 100 mHz Taktung beanspruchen, wenn sie als Option zur Verfügung steht, als die nächst höhere 200 mHz zu wählen, wenn gar nicht erforderlich. Ob die 100 mHz Taktung nun gegenüber der 200 mHz mehr Akkuverbrauch generieren soll, halte ich aus rationaler Sichtweise für verfehlt.

Ich sehe hier eher den Mehrverbrauch andersherum, wenn anstatt einer 100 mHz Taktung die 200 mHz Taktung genommen werden muss, weil die 100 mHz Taktung nicht zur Verfügung steht, welche dann eine höhere Spannungsversorgung und zeitgleich einen höheren Akkuverbrauch zur Folge hat. Jetzt soll mir bitte nur keiner Weis machen wollen, weil die 200 mHz Taktung aktiv ist, das der Dienst oder der Prozeß damit schneller abgearbeitet wird und dadurch ein geringerer Akkuverbrauch generiert wird .

Da es sich bei den Governors und I/O Schedulern um intelleigente Zuweiser handelt, nur eben mit unterschiedlichen Veranlagungen, wird natürlich jeder Dienst oder Prozeß, der durch ein Wakelog erzeugt wird, mit der Taktung versehen, welche nötig ist, um diesen Dienst oder Prozeß schnell abzuarbeiten. Es ist auch ein Unterschied, ob bei einem Dienst oder Prozeß eine Abfrage erzeugt wird, oder nur etwas an Daten empfangen wird . Von daher kann hier für einen Datenempfang schon eine 100 mHz Taktung völlig ausreichend sein, wogegen eine Abfrage schon eher mit 200 mHz Taktung, oder auch höher, ablaufen wird.


@chrischaan

VPLL ist "nur" dazu da, dass man die GPU übertakten kann (330-520 MHz). Ist der Harken nicht gesetzt, kann man die Steps zwar trotzdem einstellen, werden aber nicht genutzt, sondern max. 267 MHz.

Bist du dir in diesem Punkt sicher, das die eingestellten Werte nicht genutzt werden?

Ich habe diese Option mit dem VPLL auch immer als mögliche Übertaktung gesehen, welche eine bessere Performance bringen soll, aber auch schneller für SODs sorgen. Letztendlich soll darüber ja ermöglicht werden, Taktraten von 330 - 520 MHz nutzen zu können. Ich hatte diese Option zwischendurch auch mal getestet, nach dem ich aber bemerkt habe, das mit VPLL viele Ruckler und Laggen eintraten, habe ich dies wieder ausgeschaltet.

Wird diese Option VPLL aber nicht genutzt, kommen die unteren eingetragen Einstellungen zum Tragen (108 MHz - 267 MHz oder auch andere Verteilung), die man ja auch unterschiedlich mit Spannungen belegen kann. Wären die nicht einstellbar, wären die möglichen Zuordnungen doch dann auch deplaziert und müssten dann auch nicht aufgeführt werden, meinst du nicht auch?

Woran ich mich aber noch erinnern kann, gab es vor ein paar Monaten ja noch die Möglichkeit, den Step 1 mit 56 MHz zu bestimmen, welcher hier jetzt gar nicht mehr auftaucht? Hast du dazu irgendwelche Infos, oder ist das einfach aus Erfahrungswerten so herausgenommen worden?