[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 :D.

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 :D.

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 :D. 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:

Anhang 130007Anhang 130008


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

Zitat:

---

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

Zitat:

---

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?

Genau das ist jetzt die Frage ... Warum bauen die von Dori einen Governor, der auf dem nightmare aufbaut, wenn der "Hyper" aber die 100MHz deutlich länger nutz. Deiner Therorie nach, sollte dann ja dieser "besser" sein.


Ich bin zurzeit unentschlossen. Habe den ZZ jetzt schon etwas länger aktiv ( mal von den Benchmarks abgesehen ), jedoch spricht der, die 100MHz Taktung nur lächerliche 0,5% der Gesamtzeit an. Selbst wenn mein Handy nur mit Bildschirm an auf dem Tisch liegt und nichts macht, geht die CPU nicht auf 100MHz runter, sondern verweilt in der 200Mhz Taktung. Bei dem Hyper hingegen schon.

@kehne

Soweit ich jetzt richtig liege, wird ja bei der Installation des DorimanX Kernels der Hyper Governor als Standard Governor genommen, nicht der Nightmare ;-). Ich weiß jetzt nicht, wie der Hyper Governor so auf dem System arbeitet, da ich ihn noch nicht genutzt habe, sondern, seit Einführung des Nightmare Governors, den Nightmare Governor nutze. Ich habe heute nochmal einen Nichtnutzngszeittest durchgeführt, wo ich sehen wollte, wie sich im DeepSleep, durch erzeugte Wakelogs, die entsprechenden Taktungen wiederspiegeln. Diesmal habe ich tatsächlich das Handy weitesgehend ruhen lassen, außer für heute morgen eine Weckphase genutzt und alle 3 Stunden eine Wetteraktualisierung durchführen lassen. Entsprechendes Ergebnis kannst du nun in den Screenshots ersehen:

Anhang 130100Anhang 130101Anhang 130102Anhang 130103Anhang 130104Anhang 130105


Wie du ersehen kannst, sind überwiegend die 100MHz und die 500MHz für die Wakelogs herangezogen worden, welche von den Wakelogzeiten fast identisch sind. Da ich wie gesagt einmal den Wecker in Anspruch genommen habe (Abends Weckzeit eingeben und morgens wecken), könntest du hier die Zeit der 500MHz Taktung als Wakelog heranziehen, wogegen die Wetter Aktualisierungen eher der 100MHz Taktung zu zuordnen sind, welche durch diese Wakelogs erzeugt worden sind ;-).

Warum nun der ZZMoove Governor keine 100MHz Taktung zulässt, kann ich dir nicht erklären, vielleicht ist dieser aber so konzipiert worden, keine Ahnung. Wenn der Hyper es hergibt und wie du jetzt ja auch ersehen kannst, der Nightmare ebenfalls, warum testest du den Nightmare nicht einmal, um zu prüfen, ob mit diesem Governor auf deinem Handy die 100MHz Taktung mit eingebunden wird! Allem in allen, wie wir ja schon mal festgestellt haben, bewegen wir uns hier in einem sehr marginalen Bereich, um das letzte an Akkuverbrauch zu vermeiden.

Letztendlich kommt es doch darauf an, einen Governor zu finden, der deinen Ansprüchen und Nutzungsverhalten entspricht. Ich für meinen Teil habe mit meinem Nutzungsverhalten, eher weniger als Ottonormalverbraucher ;-), mit dem Nightmare eine gute Wahl getroffen und dieser harmoniert exellent mit den Sleepy Scheduler. Dasselbe gilt nun auch für dich, einen entsprechenden Governor und Scheduler für deine Bedürfnisse zu finden und mal ehrlich, wir reden ja hier nicht von einem unterschiedlichen Verbrauch in den zweistelligen Bereichen ;-).

Wenn deine Wahl mit Governor und Scheduler einen Verbrauch in der Zeit "X" 10% zur Folge hat und ich dagegen einen Verbrauch von nur 8% generiere, was macht das denn schon für einen Unterschied ;-), um uns hier jetzt die Birne heiß laufen zu lassen, warum passiert das hier bei mir und nicht bei dir, wenn du verstehst was ich meine :). Alles in allem und das ist mal Fakt, läuft der DorimanX Kernel v8.33 erste Sahne und generiert mir einen Akkuverbrauch, den ich mit dem PhilZ StockKernel so nie erreicht habe und das ist für mich das wesentliche, was ich jetzt aus den letzten 3 Wochen als Fazit für mich herausziehen kann ;-).

Der DorimanX Kernel läuft wirklich sehr stabil, ist sehr smooth, hat einen wirklich guten Akkuverbrauch, erzeugt bei mir keine SODs mehr, keine Freezes bei geöffneten Anwendungen oder glänzt mittendrin mit Reboots, das ist wirklich prima ;-). Das einzigste was mir noch nicht ganz so gut gefällt, ist, dass das Scrollen manchmal laggt, nur kann ich das jetzt nicht wirklich richtig zuordnen, ob dies durch meine Einstellungen in der Spannungsversorgung erzeugt wird, oder ein Kernel Problem ist. Aber als Fazit bleibt, das es momentan, denke ich jedenfalls, keinen besseren Kernel gibt, außer eventuell der Apollo Kernel, den ich jetzt aber nicht weiter ausprobiert habe ;-).

So, lade mein Handy gerade mal, und lasse es über Nacht laufen, poste dann mal das Bild. Der ZZ ist jetzt endgültig weg. Mit dem Hyper hatte ich über eine Halbe Stunde mehr Display zeit. Was ich schon enorm finde. Teste diese Nacht mit dem Hyper und dann später nocheinmal den Nightmare....

@kehne

Na da bin ich ja mal gespannt auf deine Ergebnisse, zumal du ja auch eine andere ROM nutzt als ich ;-), das macht es doppelt interessant :).

So Habe einen Deep Sleep von 99,1% und 0,4% auf 500Mhz. D.h. der Hyper dürfte beim Schlafen etwas mehr verbrauchen, da du dort "etwas" weniger hast. Bilder kommen hoch, sobald mein Internet wieder gescheit läuft

Anhang 130177Anhang 130178Anhang 130179

hier die Bilder ... Deine Werte sind meiner Meinung nach noch etwas beeindruckender ... Jedoch sollte man mit 99,1% deep sleep zufrieden sein. ( Bei aktiviertem Wecker ) denke ohne wecker wäre ich noch etwas höher gewesen ...

@kehne

Das sieht doch schon richtig gut aus und deine DeepSleep Zeit in 5h kann sich mehr als sehen lassen. Es wäre jetzt mal interessant zu Wissen, wenn du eine Nichtnutzungsphase von 12 Stunden als Vergleich einstellen könntest, so wie ich es durchgeführt habe ;-), um einen besseren Vergleich zu generieren, denn das würde mich echt mal interessieren, wie dann deine installierte SlimBean ROM gegen meine installierte NeatROM mit dem DorimanX Kernel v8.33 abschneiden würde ;-).

Was für ein Modem nutzt du eigentlich? Ist das ein CM Modem oder ein Samsung Modem?

Habe das XXLPX drauf, habe ehrlich gesagt aber auch gar keine Ahnung in welche Richtung ich da etwas ändern soll ...

Wie hast du getestet welches Modem am besten ist. Gibts da ne app ?!

@kehne

Ich habe durch ausprobieren der ganzen verfügbaren Modems getestet, welchen Verbrauch und Empfang ich auf dem Handy habe und als Hilfe über BetterBatteryStats die Häufigkeit und Zeit bestimmter Wakelogs herangezogen, die letztendlich den Ausschlag für das Modem XXLS8 gegeben haben. Gerade diese Wakelogs:

- I2_hsic
- PowerManagerService
- multipdp
- "radio-interface"
- "secril_fd-interface"

sind typische Modem Wakelogs, die, wenn sie nicht stimmig mit der Handy Hardware (Module) sind, enorme Akkuverbräuche durch ihre ständigen Wakelogs generieren können, die sich zeitlich sogar bis zu Stunden ausweiten können ;-). Letztendlich habe ich heraus gefunden, das hierbei das XXLS8 Modem am besten abgeschnitten hat, was den Netzempfang (Provider), Surfen, WLan-Empfang und GPS-Empfang betrifft, als auch die daraus resultierenden Wakelogs in der Nichtnutzungszeit ;-), die deutlich heruntergegangen sind, seit ich das XXLS8 Modem nutze. Wenn du magst, kannst du dieses Modem ja selber mal ausprobieren, um einen Vergleich zu deinem jetzigen installierten Modem zu erhalten ;-).

Download Modem/RIL XXLS8: http://d-h.st/qqH

Zitat:

---

Zitat von SaGaS

@kehne

Ich habe durch ausprobieren der ganzen verfügbaren Modems getestet, welchen Verbrauch und Empfang ich auf dem Handy habe und als Hilfe über BetterBatteryStats die Häufigkeit und Zeit bestimmter Wakelogs herangezogen, die letztendlich den Ausschlag für das Modem XXLS8 gegeben haben. Gerade diese Wakelogs:

- I2_hsic
- PowerManagerService
- multipdp
- "radio-interface"
- "secril_fd-interface"

sind typische Modem Wakelogs, die, wenn sie nicht stimmig mit der Handy Hardware (Module) sind, enorme Akkuverbräuche durch ihre ständigen Wakelogs generieren können, die sich zeitlich sogar bis zu Stunden ausweiten können ;-). Letztendlich habe ich heraus gefunden, das hierbei das XXLS8 Modem am besten abgeschnitten hat, was den Netzempfang (Provider), Surfen, WLan-Empfang und GPS-Empfang betrifft, als auch die daraus resultierenden Wakelogs in der Nichtnutzungszeit ;-), die deutlich heruntergegangen sind, seit ich das XXLS8 Modem nutze. Wenn du magst, kannst du dieses Modem ja selber mal ausprobieren, um einen Vergleich zu deinem jetzigen installierten Modem zu erhalten ;-).

Download Modem/RIL XXLS8: http://d-h.st/qqH

---

Flasht du das Modem einfach drüber ? Hatte im XDA auch von einem Cleaner Script gelesen ... Ist aber überflüssig da eh alles gelöscht wird richtig ?

@kehne

Ich flashe das Modem einfach über CWM und mache dann anschließend noch einen "Wipe Cache Partition" und "Wipe Dalvik Cache", das war es dann auch schon ;-).

gut, dann habe ich ja intuitiv alles richtig gemacht, habe noch ein fix gemacht, aber naja schaden tut das auch nicht ;-)

@kehne

Den "Fix Permissions" wende ich in der Regel nur nach einer Neuinstallation einer "Non-Wipe" CustomRom an, oder wenn Apps nach dem installieren irgendwie nicht so laufen, wie sie sollten. Für Kernel und Modem Installationen reichen in der Regel der "Wipe Cache Partition" und "Wipe Dalvik Cache" nach der Installation aus, wobei ich mir angewöhnt habe, bei einer neuen Kernel Installation zuvor noch das GS2KernelWipe Script von @hawkerpaul durchlaufen zu lassen ;-).

Bin echt mal gespannt, wie du das Modem XXLS8 bewertest und ob du für dich ebenfalls eine Verbesserung feststellen kannst, im Vergleich zu deinem zuvor installierten Modem ;-).

@ SaGaS:

Ja da bin ich mir sicher. Steht auch so in der Beschreibung dazu. Wurde aber auch schon mal im Forum erwähnt. Will man seine Graka übertakten mit den Werten über 267MHz, muss man VPLL aktivieren. Wobei diese VPLL Funktion wiederrum nicht auf jedem Handy gleich gut funktioniert, weshalb es vielleicht bei dir zu Problemen gekommen ist.

Der 56MHz Step wurde rausgenommen, weil er schlichtweg nicht genutzt wurde. Also es lies sich zwar einstellen, wurde dem Grafikchip auch mitgeteilt, aber dieser hat die 56MHz einfach nicht genutzt. Wurde mal so von Dori in irgendeinem Post erwähnt und dann entfernt :)

---------- Hinzugefügt um 23:02 ---------- Vorheriger Beitrag war um 22:57 ----------

Kernels 8.34 and 9.34 ONLINE!


Download:

Kernel_Siyah-Dorimanx-V9.34-[22-34]-[03-07]-JB-CM-AOKP-SGII-PWR-CORE.zip

Kernel_Siyah-Dorimanx-V8.34-[22-31]-[03-07]-JB-SGII-PWR-CORE.zip

Kommentare:

This is MAJOR update from 3.10.RC5 Google Android kernel.
470 files changed, 38287 insertions(+), 15686 deletions(-)

and some updates from Sammy STOCK/Modded SG4 Kernel! (thanks to AndrieLux)

Big thanks to Alucard for helping testing and updating new code.

This kernel has huge update for all critical functions!
and power that now saved is just awesome! with performance profile i see -9ma/h on deep sleep! and sleep time is much higher. (less wake-ups)

kernel is very stable.
I recommend to set nightmare as main awake gov! about sleep gov, you can leave ondemand or other that you like.

Change Log:

• Updated WIFI driver from SG4 kernel. v1.61.56
• Updated massive code for DM partitions (move apps to sdcard)
• Updated massive code for Power Manager from 3.10.rc5 google android
• Updated massive code for BLOCK and FS that responsible for all I/O throughput!
• Updated and enabled latest and most advanced I/O GOV - BFQ v6r2!
• Alucard made big code change/improve for nightmare and darkness govs.
• Updated ARM compressions code.
• Updated LINARO 2013.06 GCC 4.7.4 kernel builder.
• Updated with 3.0.84 main stream patch.
• Fixed old bugs with video drivers for STOCK and CM/AOKP ROMS!
• for CM/AOKP only! i have fixed the mass storage and MTP, now we have CM-kernel code for that.
  for 8.34 kernel, that part can't be changed, or stock ROM will loose mass storage support.
• Updated latest CM-KERNEL boot INIT and other new init changes.
• Ported some stock code updates from SG4 kernel.
• Alucard fixed performance gov! now if used, 2 cores will be ON non stop.
• Fixed Color tuning on boot and for first ROM boot default.
• Alucard cleaned Pegasusq CPU GOV, now it's much better, and working with our Intelihotplug code.
• Updated all I/O GOVS and set BFQ as default I/O gov for awake/sleep.
• Updated kernel global code from 3.10.rc5 for ptrace function.
• Updated power regulator code.
• disabled slide2wake in all profiles.
• Alucard made changes in GOVS tunings and all profiles tuning.
• Added data/cache partition light fix on boot, in case partition was not unmounted cleanly.

Tja dann muss ich wohl doch wieder flashen ... Immerhin läuft 9.33 ja schon drei tage ... :D

Hört sich einfach zu gut an

Hahaha, ja so geht es mir bei fast jedem Update =D Ich bin schon echt froh, dass die Zeit an dem jeden Tag nen Update kam vorbei ist und er sich jetzt etwas mehr Zeit lässt. Die letzten Versionen waren dafür auch recht Bugfrei! Ich nutze jetzt erstmal auch den Nightmare Gov, so wie er es in den Kommentaren zum Changelog empfohlen hat. Scheint wohl endlich offiziell Stable zu sein. Zwischenszeitlich war der Nightmare leider nicht wirklich stabil (so vor 6-7 Versionen). Außerdam schau ich mal wie sich der neue BFG Schedular schlägt der jetzt Standard ist. Hab dazu leider noch kein Benchmark gefunden.

Du nutzt den 9.33? Darf ich fragen auf welcher Rom du unterwegs bist?

Zitat:

---

Zitat von chrischaan

Hahaha, ja so geht es mir bei fast jedem Update =D Ich bin schon echt froh, dass die Zeit an dem jeden Tag nen Update kam vorbei ist und er sich jetzt etwas mehr Zeit lässt. Die letzten Versionen waren dafür auch recht Bugfrei! Ich nutze jetzt erstmal auch den Nightmare Gov, so wie er es in den Kommentaren zum Changelog empfohlen hat. Scheint wohl endlich offiziell Stable zu sein. Zwischenszeitlich war der Nightmare leider nicht wirklich stabil (so vor 6-7 Versionen). Außerdam schau ich mal wie sich der neue BFG Schedular schlägt der jetzt Standard ist. Hab dazu leider noch kein Benchmark gefunden.

Du nutzt den 9.33? Darf ich fragen auf welcher Rom du unterwegs bist?

---

Genau die 9.33 ist ein unglaublicher Traum. Siehe die Bilder von mir uns SaGaS ... Habe jetzt die 9.34 geflasht, mal schauen wie die so ist.

Ich nutze die Slimbean Rom.



Erster Eindruck: Sieht auf den ersten Blick stabil aus und 100Mhz wird mit Nightmare deutlich länger genutzt ... Bin gespannt was nächste Nacht da so bei rumkommt.

Zitat:

---

Zitat von kehne

Genau die 9.33 ist ein unglaublicher Traum. Siehe die Bilder von mir uns SaGaS ... Habe jetzt die 9.34 geflasht, mal schauen wie die so ist.

Ich nutze die Slimbean Rom.

---

Sauber, auf der SlimBean bin ich auch. Ein absoluter Traum die Rom. Einfach super schnell und smooth, und dazu kann man einfach noch alles einstellen was das Herz begehrt. Das einzige was mich gestört hat war, dass man bei den WIFI/Empfangssignal-Icons oben in der Statusleiste die Farbe nicht ändern kann (wollte es gerne weiß haben -> schön schlicht). Aber das hab ich dann einfach selber in die Hand genommen und in der SystemUI.apk angepasst :) In Verbindung mit dem Dori geht das Ding einfach ab wie Schmitz' Katze. Und dazu noch super stable. Toll finde ich auch, dass es immer Weeklys gibt zu der Firmware, die schon Beta getestet sind und i. d. R. komplett stabil laufen. So hat man jede Woche schön was zum flashen und muss nicht immer 1-2 Monate auf nen Stable Release warten =D Für Flashsüchtige ist das auf jeden Fall die perfekte Droge.... ;)

---------- Hinzugefügt um 01:40 ---------- Vorheriger Beitrag war um 00:02 ----------

@ Sagas:

Nachtrag zu VPLL: was mir gerade aufgefallen ist, dass der VPLL Mode nur für die Steps 330, 440, 520 MHz gebraucht wird, es aber noch eine weitere Frequenz gibt und zwar 400 MHz. Also kann man seine GPU auch übertakten ohne VPLL zu aktivieren, dann hat man aber nur die Möglichkeit auf 400 MHz zu gehen. Die anderen drei Steps werden nur durch VPLL ermöglicht. So verstehe ich das zumindest aus der Beschreibung. Aufgefallen ist mir das, als ich das Performance Profil ausgewählt habe (das nutzt Dori immer selber). Dabei wird u. a. die CPU auf 1,5 GHz übertaktet UND auch die GPU auf 400 MHz, ohne dass VPLL aktiv ist. Ich denke nicht, dass Dori die GPU auf 400 MHz einstellen und dann den VPLL beim Performance Profil nicht aktivieren würde, wenn dies dazu eigentlich notwendig wäre. (Achtung beim Lesen, nicht GPU und CPU durcheinander bringen. G und C sehen sich echt verdammt ähnlich, musste sau aufpassen beim schreiben keinen Fehler zu machen :P )

:)

@chrischaan

Danke dir für deine Antwort ;-). Meine Frage zielte aber nicht drauf ab, ob übertaktet werden kann, sondern was mit den vorab eingestellten Werten von 108 MHz - 267 MHz passiert, welche ja auch unterschiedlich mit Spannungen beaufschlagt werden können. Da hatte ich erst aus deiner Antwort in Post #215 herausgelesen, das die vorab eingestellten 108 MHz - 267 MHz Taktungen nicht mit veränderten Spannungswerten beeinflusst werden können.

Jetzt nach nochmaligen Gegenlesen dazu, verstehe ich nun deine Antwort zu deiner Ausführung mit "VPLL" und die möglichen Taktungen von 330 MHz - 520 MHz ;-), bzw. bis max. 400 MHz. Ich hatte dies zuerst so interpretiert, das bei nicht anhaken von "VPLL", dann die Taktungen von 108 MHz - 520 MHz vom System verwaltet werden, was aber auch bedeutet, das die Spannungsversorgungen sich dann auch dafür nicht ändern lassen und vom System gehändelt werden ;-), welche aber durchaus manuel eingestellt werden können.

Somit hat sich meine Frage dazu auch erledigt und wieder einmal die Erkenntnis gewonnen, wer Lesen kann, ist klar im Vorteil :D. Was man nicht alles so verstehen kann, wenn man nicht richtig liest ;-).

Bei der 9.34 geht der Cortexbrain background service nicht mehr ... Ist das nur bei mir so ? Oder hat jemand anderes auch schon das problem?


Edit: Einstellungen einmal neu eingestellt, jetzt gehts ;-)