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

Da ich maximale taktung von 800 habe und nur einen kern, ist es also schlecht...hm...aber woran könnte das liegen?

Solange das Display an ist, wird dein Handy immer viel verbrauchen. Egal ob irgendein aufgemotzter Kernel oder nicht. Das Meiste was du rausholen kannst mit Kernel/Autostart aufräumen/Apps freezen ist im Deep Sleep.
Wenn du bei 1 1/2 h "Display an" mal in die einfache Akkuverbrauchsanzeige vom System wechselst, wird der Display mit Sicherheit minimum für 75% des Batterieverbrauchs verantwortlich gemacht. Die Optimierungen durch Kernel/CPU etc. bringen dir dann vielleicht in diesem Zeitraum 1-2%. Als Lösung dienen kann nur ein besserer Akku oder ein effizienteres Display

Zu deiner Taktungsfrage: wenn du nur einen Kern laufen hast und dazu auf 800Mhz beschnitten braucht dein Handy wesentlich länger für alle Berechnungen. Das führt automatisch zu längeren "Display an"-Zeiten. Außerdem kann es durchaus sein, dass die CPU sogar mehr Energie verbraucht in der Summe als vorher. Klar verbraucht die CPU erstmal weniger durch die Beschneidung, aber nach hinten raus kann das wieder verpuffen durch die längere Berechnungszeit. Das ist aber nur eine Vermutung, kann ich nicht validieren.

Zitat von Dtex

Da ich maximale taktung von 800 habe und nur einen kern, ist es also schlecht...hm...aber woran könnte das liegen?

Ich würde dies mal so formulieren wollen, je nach Anwendung die du auf deinem Handy ausführst, benötigt / erfordert die Anwendung eine bestimmte CPU (Prozessor)- und GPU (Grafik)-Taktung, damit sie vernümftig und flüssig laufen kann. Ist die Anwendung nicht sehr CPU- und GPU-lastig, wird dafür dann wahrscheinlich eher ein geringerer Akkuverbrauch auftreten, da z.B. für die CPU-Taktung nur 800mHz benötigt werden, was auch eine geringere Spannungsversorgung dieser Taktung zur Folge hat, folglich auch eher weniger Akkudurst .

Lässt du jetzt aber eine Anwendung wie z.B. eine Navigationssoftware laufen, dann kannst du davon ausgehen, das du mehr Akkuverbrauch haben wirst. Das liegt zum einen daran, das die meisten Navigationssoftwaren sehr rechenintensiv sind, was zur Folge hat, das du dich bei der CPU-Taktung dann mindestens bei 1000mHz einfinden wirst. Hierbei geht es dann aber auch noch weiter, je nach dem wie deine beiden CPU-Kerne (Load_H0 und Load_H1) dazu dann eingebunden werden, wird dein Akkuverbrauch auf ein (1) % pro 3 - 5 Minuten kommen.

Wenn dein erster CPU-Kern (Load_H0) z.B. so eingestellt ist, das ab einer 60%-tigen Auslastung der zweite CPU-Kern (LOad_H1) dazugeschaltet werden soll, dann wird dein Akkuverbrauch dazu natürlich ansteigen, da der zweite CPU-Kern (Load_H1) ja auch mit Spannung versorgt sein will und die zieht dieser ebenfalls vom Akku. Das bedeutet, solange eine Anwendung nur einen CPU-Kern beansprucht, wird der Akkudurst nicht so groß sein, als wenn beide CPU-Kerne aktiv sind.

Jetzt kommt aber noch ein weiterer Aspekt in die Berechnung des Akkuverbrauches mit dazu, deine GPU (Grafik-Prozessor). Je nach intensität und Aufwendung der grafischen Darstellung, wird dann deine GPU-Taktung ebenfalls rational zur Intensivität der Beanspruchung und Darstellung der Bilder, den Akkuverbrauch ansteigen lassen. Die GPU-Taktung wird dann je nach Anwendung und Darstellung stetig ansteigen (von Step1 bis auf Step 5), was wiederrum ebenfalls eine höhere Spannungsversorgung zur Folge hat und dadurch steigt dann natürlich auch wieder der Akkuverbrauch rapide an.

Wenn du nun z.B. eine App wie STweaks nutzt, wo du über bestimmte Parameter Einfluss auf die Taktungen der CPU und der GPU nimmst, ist es auch entscheidend welchen Governor und Scheduler du dafür verwendest, um die Zuordnungen zu priorisieren. Das ist aber auch kein leichtes unterfangen, um ein gesundes Pärchen aus Governor und Scheduler für dein Nutzungsverhalten einzustellen / zusammenzustellen, damit dein Akkuverbrauch dementsprechend nicht zu rapide ausfällt. Aber in allen Anwendungen die du über dein Handy ausführst, wirst du je nach Intensität deiner Anwendungen, immer einen proportionalen Akkuverbrauch dazu verzeichnen.

Wenn du z.B. viel mit Games (Spielen) machst (sehr rechenintensiv), wirst du meistens immer einen hohen Akkuverbrauch dabei haben, da sowohl die CPU (meistens beide CPU-Kerne), als auch die GPU gefordert sein werden. Wenn du z.B. nur Musik hörst, dann wirst du zwar auch einen etwas höheren Akkuverbrauch haben, der wird aber nicht so hoch ausfallen, als wenn du dies im Vergleich zu den Games bringst, da hier meist nur ein (1) CPU-Kern beansprucht wird und die GPU weniger. Wenn du jetzt z.B. nur SMSs schreibst, dann wird hierzu im Vergleich zum Game spielen oder Musik hören, dein Akkuverbrauch eher moderat ausfallen, da für diese Anwendung keine hohe CPU- noch GPU-Last auftritt und somit weniger Spannung verbraucht wird, was deinen Akkuverbrauch dazu auch moderat ansteigen lässt.

Ich hoffe ich konnte dir ein wenig die Hintergründe für den Akkuverbrauch aufzeigen / schildern und wie sich dieser je nach Anwendung zusammensetzt oder verhalten wird. Aber alles was du letztendlich ausführst, hat immer zur Folge, das dein Display (Akkukiller Nr.1) von Hause aus schon mal am Akku zerrt, egal was du für eine Anwendung am laufen hast. Je länger das Display genutzt wird (sonst siehste ja nichts ), desto mehr steigt dein Akkuverbrauch, es kommt jetzt nur darauf an welch rechenintensive Anwendung du dazu laufen lässt und wie dazu die CPU- und GPU genutzt / gebraucht wird.

Also eigentlich brauche ich handy nur zum sms schreiben, videos und bilder sehen, bilder machen, internet surfen momentan...Was ist dafür denn am geeignetsten?
mfg

Zitat von Dtex

Also eigentlich brauche ich handy nur zum sms schreiben, videos und bilder sehen, bilder machen, internet surfen momentan...Was ist dafür denn am geeignetsten?
mfg

Ich habe zur Zeit unter Governor den "ondemand" eingestellt und unter Scheduler "noop". Das ist eigentlich immer eine gute Paarung und ich denke für deine Belange erst einmal eine gute Grundeinstellung. Aber du solltest dich diesbezüglich mal ein wenig einlesen, @chrischaan hat dafür eigens ein paar Links mit Themen im Eingansthread (Sticky) eingestellt, die auf diese Thematik einbisschen eingehen und auch vieles für das Grundverständnis erklären.

Hier mal etwas zum Nachlesen zum Thema Governor & Scheduler:
http://www.android-hilfe.de/kernel-f...chedulers.html

Version 7.46 is daaa

So, nach ein paar Tagen Testzeit, möchte ich euch aus meiner eingestellten Liste (Beitrag #32) nun weitere Apps vorschlagen, die ihr von / aus der Liste entfernen könnt, um unnötige Apps (Bloatware) zu verbannen. Ich rate jedoch dazu die mit einem *Sternchen davor und roter Fettschrift aufgeführte App vor dem entfernen vorsichtshalber über einen File-Manager (z.B. Root Explorer) zu sichern, da ich nicht weiß, wie sich die Entfernung auf eurem System auswirkt. Ich kann aber zu 100% bestätigen, das mein System nach dem entfernen der gleich aufgeführten System-Apps und Apps einwandfrei funktioniert und keine abnormalen Verhaltensweisen wie z.B. Freezes, Reboots, Bootloops oder Akku-Drain aufgezeigt hat.

Alle Apps lassen sich im Unterordner "app" wiederfinden, welchen ihr über einen File-Manager wie folgt anwählen und sichern könnt:

"System" > "app"


Weitere entfernte System-Apps und Apps aus der NeatROM Lite v4.2:

• *Google Backup Transport 4.1.2-509230
• Automation Test 1.0
• Bluetooth-Freigabe 4.1.2-I9100XWLS8
• com.sec.android.app.lcdtest 1.0
• Face Unlock 4.1.2-509230
• Factory Test 1.0
• Fernzugriff v1_1210_2_1
• Fernzugriff v1_1211_1_1
• Self Test Mode 1.0
• SyncmIDS v3_1210_2_1 (Samsung Account = wer diesen benötigt, dann diese System-App nicht entfernen)
• TestService 1.0
• Zertifikatsinstallationsprogramm 4.1.2-I910XWLS8



@chrischaan

Habe jetzt mal deinen Tipp mit dem "Sleepy" unter Sleep Governor eingestellt, mal schauen wie sich dieser darstellt und in wie weit sich dadurch noch der DeepSleep verändern lässt. Danke dir erst einmal für diesen Tipp.

Des Weiteren habe ich über die Tune-App STweaks weitere Einstellungen vorgenommen, welche sich bis jetzt auch nicht negativ auf meinem System ausgewirkt haben. Folgende Einstellungen nutze ich jetzt zur Zeit mit STweaks:

• CPU
Folgende Einstellungen habe ich gewählt:

• MAX NORMAL FREQUENCY: 1000000 kHz
• SMOOTH SCALING LEVEL: 150 MHz
• SCALING_MIN_SUSPEND_FREQ: 150 kHz


• CPU-Voltage
Folgende Einstellungen habe ich gewählt:

• 1200 MHz: 1250 mV
• 1152 MHz: 1225 mV
• 1100 MHz: 1200 mV
• 1052 MHz: 1175 mV
• 1000 MHz: 1150 mV
• 952 MHz: 1125 mV
• 900 MHz: 1100 mV
• 852 MHz: 1075 mV
• 800 MHz: 1050 mV
• 750 MHz: 1025 mV
• 700 MHz: 1000 mV
• 650 MHz: 975 mV
• 600 MHz: 950 mV
• 550 MHz: 950 mV
• 500 MHz: 925 mV
• 450 MHz: 925 mV
• 400 MHz: 900 mV
• 350 MHz: 900 mV
• 300 MHz: 900 mV
• 250 MHz: 875 mV
• 200 MHz: 875 mV
• 150 MHz: 875 mV
• 100 MHz: 850 mV


• CPU-Tuning (Awake/Sleep)
Folgende Einstellungen habe ich gewählt:

• (CPU-Tuning Awake) Default CPU Governor > nightmare
• (CPU-Tuning Sleep) DeepSleep! CPU Governor > sleepy


• I/O (Scheduler)
Folgende Einstellungen habe ich gewählt:

• KILOBYTES TO READ-AHEAD > 2048 kb
• DEFAULT AWAKE I/O SCHEDULER > DEADLINE
• STANDBY/DEEPSLEEP I/O SCHEDULER > NOOP


• GPU
Folgende Einstellungen habe ich gewählt:

• 62Mhz: 850mV
• 108Mhz: 850mV
• 160Mhz: 900mV
• 200Mhz: 950mV
• 267Mhz: 1000mV


• SCREEN
Folgende Einstellung habe ich gewählt:

• MAX_GAMMA: 20


• SOUND
Folgende Einstellungen habe ich gewählt:

• JB LOW SOUND FIX ON BOOT: Haken gesetzt (Enabled)
• HEADPHONE AMPLIFIER: Boost 3 dB
• MIC GAIN LEVEL: 4 dB
• SPEAKER LEVEL: 8 dB


• TWEAKS
Folgende Einstellungen habe ich gewählt:

• CORTEXBRAIN-BACKGROUND-PROCESS: Enable
• ANDROID LOGGER CONTROL: Disabled


So, ich hoffe mit diesem Beitrag wieder ein Stück näher gekommen zu sein, um den Akkuverbrauch ein wenig weiter einschränken zu können. Wenn von euch noch irgendwelche Ideen in Bezug auf Bloatware einfallen, oder mit den Einstellungen mit der App STweaks, dann würde ich mich über ein Feedback freuen.

---

Kernel 7.46 ICS-JB-MALI-CM10.1-JB-LEAK! (JB XWLS8 Support!) BETA

I have updated the SCHED CORE to 3.8.RC5 last update!
Alucard updated the CPUFREQ code from 3.8.RC5
So, if some OLD ROM will be broken, i cant help! UPDATE already!
Tested on SAMMY ROM and RootBox 3.2 AOKP works great!
CM10.1 ROM is broken with my kernel, WIFI bugs and others,
So i hope it's will be better now, if not.. well i hope it will one day.
When CM do some more fixing. they always do, and that is great!

Change Log:

• ROOT (SuperSU) updated to 1.04 and will replace any other by auto.
• Kernel Sched Core merged with 3.8.RC5 kernel main line. (70 Commits!)
• Kernel CpuFreq code merged with 3.8.RC5 exonys part. by Alucard
• Fixed HOME KEY restore (for JB SAMMY ONLY!) if switching to other kernel via RECOVERY.
• Tuned All Profiles.
• Alucard tuned and updated Nightmare GOV to be something Awesome!
• it's very powerful and low draining=(on idle!) if used it's give you the smoothness that you like, it's tuned based on profiles.
• Fixed ICS BOOT stuck! now BOOT.
• Added Auto Fix to EFS partition holding the important Device files. if it's get broken, you loose signal + others things, now it's will not happen. FIX will be auto when you load RECOVERY and only if needed. no user input required.
• Added CLEAN RAM CACHE button to STweaks Memory TAB. it's can clean very fast all cached RAM, it's will be filled slowly again.
• Restored normal color for Recovery.
• Reduced Logger allocated RAM and restored PMEM = 4MB allocation for ICS and JB SAMMY, it can improve stability, we lost 2MB of TOTAL RAM.
• Removed broken sched_mc_power_savings it's was 0(disabled) and was holding huge code! now it's out! and battery drain is very low.
• Updated Sensors Code from JB SAMMY Kernel.
• Ported MMC code updates to support 16GB+ cards from unsupported vendors, now should work. thanks to AndreiLux! also should help with sdcard error detection.

---

@SaGaS: Ich bin seit gestern mal ein wenig auf Pegasusq/Sio unterwegs (awake). Schlägt sich nicht schlecht. Beim "Hyper" Governor hatte ich das Gefühl, dass das Gerät manchmal in einen Sekundenschlaf beim Bearbeiten von Eingaben fällt, ehe es seinen "Job" wieder antritt. Mit dem Pegasus scheint das jetzt besser zu sein - mal abwarten. Über den Nightmare habe ich jetzt auch viel gelesen in den letzten Tagen, vor allem seit dem Update 7.46 Beta (s. o.). Den werde ich wohl als nächstes testen. Soll von der Performance ähnlich wie der Ondemand sein, nur etwas akkusparender. Ach man, eigentlich hatte ich das ganze Governor/Schedular rumprobiere in die Ecke gestellt, aber jetzt hänge ich schon wieder in diesem Doom Loop fest =D

@chrischaan

Mit gehangen mit gefangen . Ich finde im Moment die Mischung aus Nightmare und Sleepy gar nicht so schlecht, was zumindestens erst einmal die Standby Zeiten und den daraus resultierenden DeepSleep betrifft. Der Akkuverbrauch ist damit auch sehr moderat, so wie ich es mir vorstelle, wenn ein Handy eben nicht benutzt wird. Was den Akkuverbrauch unter Belastung betrifft, so werde ich dies auch noch genau unter die Lupe nehmen, aber erst einmal möchte ich sicherstellen, das meine Grundvoraussetzung erfüllt ist .

Hast du den DorimanX v7.46 Beta schon installiert, oder wartest du eher auf die Stable-Version? Mich hat das ein wenig abgeschreckt, als ich "Mega-Beta-Test" für den DorimanX 7.46 gelesen habe, da habe ich dann immer so ein unwohliges Gefühl dabei. Naja, mal abwarten was so die User Meinungen zu dem DorimanX 7.46 Beta sind und welche eventuell auftretenden Probleme damit verbunden sein könnten.

Werde heute mal versuchen die CPU-Taktungen noch ein wenig anzupassen, hatte beim letzten Tuning ein wenig übertrieben und hatte promt ein Freeze nach dem anderen . Sollten sich dann die neuen eingestellten Werte als stabil erweisen, stelle ich hierzu wieder ein Update ein. Was mir aber aufgefallen ist, laut CPU Spy ist die Höchstgrenze von 1000 MHz nicht überschritten worden, was bedeuten würde, das der Energiesparmodus funktioniert und das Handy nur bis 1000 MHz getaktet wird.

Zitat von SaGaS

@chrischaan

Mit gehangen mit gefangen . Ich finde im Moment die Mischung aus Nightmare und Sleepy gar nicht so schlecht, was zumindestens erst einmal die Standby Zeiten und den daraus resultierenden DeepSleep betrifft. Der Akkuverbrauch ist damit auch sehr moderat, so wie ich es mir vorstelle, wenn ein Handy eben nicht benutzt wird. Was den Akkuverbrauch unter Belastung betrifft, so werde ich dies auch noch genau unter die Lupe nehmen, aber erst einmal möchte ich sicherstellen, das meine Grundvoraussetzung erfüllt ist .

Hast du den DorimanX v7.46 Beta schon installiert, oder wartest du eher auf die Stable-Version? Mich hat das ein wenig abgeschreckt, als ich "Mega-Beta-Test" für den DorimanX 7.46 gelesen habe, da habe ich dann immer so ein unwohliges Gefühl dabei. Naja, mal abwarten was so die User Meinungen zu dem DorimanX 7.46 Beta sind und welche eventuell auftretenden Probleme damit verbunden sein könnten.

Werde heute mal versuchen die CPU-Taktungen noch ein wenig anzupassen, hatte beim letzten Tuning ein wenig übertrieben und hatte promt ein Freeze nach dem anderen . Sollten sich dann die neuen eingestellten Werte als stabil erweisen, stelle ich hierzu wieder ein Update ein. Was mir aber aufgefallen ist, laut CPU Spy ist die Höchstgrenze von 1000 MHz nicht überschritten worden, was bedeuten würde, das der Energiesparmodus funktioniert und das Handy nur bis 1000 MHz getaktet wird.

bin noch auf 7.44. Aber werde mir jetzt gleich den 7.46 drauf machen. Ich denke das "Mega Beta Test" bezieht sich darauf, dass der Thread-Titel im XDA-Forum zu 7.46 geändert wurde, obwohl es sich um eine Beta handelt. Normalerweise geschieht dies nur bei Stable-Releases. Meine Vermutung ist, dass sich das "Mega" auf die User-Anzahl bezieht, die er versucht mit der Beta zu erreichen =D Prinzipiell ist sowieso erstmal nichts gegen die Betas einzuwenden. Während der 7.3x Betas war es für ICS-Nutzer etwas ärgerlich, aber auf der 7.29 Beta war ich z. B. super lange unterwegs.

Viele Bugs zur 7.46 wurden bisher nicht berichtet, zumindest nicht öffentlich im Forum. Allerdings ein für dich entscheidender, denn der Nightmare Gov hat jetzt wohl den Bug, dass nur ein Kern genutzt wird. Dazu gibt es den Workaround, dass man den Governor einmal tauschen soll und dann wieder zurück zum Nightmare, allerdings muss das nach jedem Neustart erledigt werden. Also würde ich an deiner Stelle lieber auf die 7.47 warten

@chrischaan

Vielen Dank für deine Antwort und Hinweis lieber auf den DorimanX v7.47 zu warten, das werde ich dann auch tun. Momentan gibt es eigentlich für mich auch keinen Grund den Dorimanx v7.44 zu wechseln, den er leistet gute Arbeit und läuft bei mir sehr stabil. Mal schauen wie der DorimanX v7.46 Beta von den Usern angenommen wird und was sie zu dem Test berichten werden. Werde den Thread mal genauer beobachten .

Kernel 7.47 Power BETA (was auch immer eine Power Beta ist )

Change Log:

• Updated WiFi driver from 1.12.19 to 1.12.23 from Google Exonys Kernel. should sleep and work as should!
  NOTE: CM10.1 Hotspot ROM drivers not supported! so it's will not turn ON.(the HOTSPOT! wifi OK)
  for all the rest OK.
• Updated with 3.0.62 patch from main stream.
• Updated kernel build scripts from 3.8.RC6 kernel.
• Pulled all new MEM updates from 3.8.RC6 kernel.
• Alucard fixed and tuned Nightmare gov, now sec cpu turn on/off and should!
  and gov set as default for profiles: default, performance, and extra performance.
• All profiles tuned!
• We have cleaned CPU code and improved voltages now we are +25mv from default exonys cpu voltages,
  we have tried to use DEFAULT, but found it to be unstable in some conditions! "SOD" now stable.
• I have added new control for dirty ratio in Memory tab and STweaks.
• Fixed touch keys ON if user want OFF. now will be OFF.
• Fixed "AFTR only" set by auto for JB SAMMY ROMS to remove sound bug on screen off.
• Improved wake up boost function for nightmare gov, now kick ON with full power for set delay, then go to normal mode.
• Alucard fixed the 1.6Mhz freq spike on boot that broken many phones boot in last kernel, now we have less voltage wasted and no 1.6Mhz spikes!
  many CPU chips cant handle that speed even for 0.1 sec! (cpu code tuned to more battery saver, pulled from 3.8.RC6)
• Voku ported Network updates that should speed up network processing + security + lower battery usage.
• Voku ported code for improved file Mem cache to speed up the system.
• Voku ported lowmemkiller code to work with better values taken from actual RAM.
• Voku ported updates to ROW I/O sched, it's should work better and save some power on idle.
• I have ported update to NEW MALI drivers from JB-KERNEL source. effect only CM10/10.1 and all AOKP ROMS. (nothing to pull for old driver!)
• Added DB optimization Cron task and fixed others. (will run at 3:00AM if checked)
• Alucard made many corrections in STweaks descriptions, tuning + cleaning!
• I have fixed SuperSU PRO app removed on ROOT reinstall or update!
  this is paid app that allow more options in SuperSU ->"free ver", see Google play. (not must to have, but nice)
• I have tuned static memory tuning in cortex.
• Cortex FW tweaks set PING blocked or allowed! nothing more.
  if you need ping open uncheck the cortex fw and reboot.
  
  

  ---

@SaGaS: Scheint so, als sei der Nightmare Gov gefixed. Vielleicht gibst du dieser Beta mal eine Chance Habe zwar gelesen, dass ein User von einem SOD berichtet hat und dies auf den Nightmare Gov zurückführen will. Allerding meinte er auch, dass er unter Nightmare schon immer SODs hatte. Hört sich für mich daher eher nach einem grundlegenderem Problem an (zu viel UV oder was auch immer), als das allein am Nightmare festzumachen. Du scheinst bisher ja keine Probleme mit dem Nightmare gehabt zu haben oder?

edit: so wie ich das aus dem Changelog lese, hat der Nightmare den Hyper als Standard Gov abgelöst in 7.47. Hab das aber noch nicht überprüft.

@chrischaan

Wieder einmal vielen Dank für deinen Hinweis und Tipp, den ich in der Tat auch umsetzen werde .

Zuvor möchte ich noch auf dieses Problem eingehen, mit dem Gerücht um diesen SOD (Sleep of Death) und das dies auf den Kernel DorimanX alleine zurück zu führen wäre. Seit geraumer Zeit verfolge ich ja nun bestimmte mögliche Einstellungen, die man in Verbindung mit dem DorimanX Kernel und der App STweaks ausprobieren kann. Momentan erscheint es so, das der Nightmare Governor im Moment mit dem DorimanX Kernel sehr gut harmoniert und es sich tatsächlich sehr gute Akkuverbrauchswerte generieren lassen, siehe Screenshots:




Ich habe mit dem Nightmare Governor nicht dieses Problem, dass das Handy nicht mehr aus dem DeepSleep-Modus (SOD) aufwacht, was auch immer das Problem bei diesen Usern ist, es kommt nicht vom DorimanX Kernel. Eine vermutete Fehlerursache könnte die zu niedrige Busfrequenz zwischen der CPU und dem RAM sein, die wohl bei 100 kHz von @dorimanx eigestellt worden ist und wohl bei einigen, aber eben nicht bei allen Galaxy S2 Handys auftritt, die mit dem Exynos Prozessor ausgestattet sind.

Wenn man sich dazu z.B. mal die installierten Custom-ROMs ansieht, die von diesem SOD sprechen und dies erleben, oder erlebt haben, wirst du hier überwiegend auf die Alliance-ROM oder die MIUI-ROM stossen, aber so gut wie auf keine NeatROM . Ich denke hier liegt auch eher der Fehler begraben, das der DorimanX Kernel mit der Alliance- oder MIUI-ROM nicht richtig harmoniert, hingegen aber mit der NeatROM prächtig. Ich kann auch nicht sagen woran das genau liegt, aber es scheint mir, dass das SOD Problem im Zusammenhang mit der jeweiligen Custom-ROM zu suchen ist und nicht beim DorimanX Kernel.

So, ich möchte nun wieder ein Update von eingestellten Parametern über die App STweaks einstellen, die ich zur Zeit nutze und womit ich diesen hervorragenden DeepSleep erreicht habe, bei 10 Std. Nichtnutzungszeit des Handys.

Folgende Einstellungen nutze ich jetzt zur Zeit mit STweaks:

• CPU
Folgende Einstellungen habe ich gewählt:

CPU GLOBAL SETTINGS
• MAX NORMAL FREQUENCY: 1000000 kHz
• SMOOTH SCALING LEVEL: 150 MHz

CFS SETTINGS
• GENTLE FAIR SLEEPERS: Haken gesetzt (Enabled)
• ARCH POWER: Haken gesetzt (Enabled)

CPU IDLE AND POWER SETTINGS
• SCHED_MC: 2
• SCALING_MIN_SUSPEND_FREQ: 150 kHz


• CPU-Voltage
Folgende Einstellungen habe ich gewählt:

• 1200 MHz: 1225 mV
• 1152 MHz: 1225 mV
• 1100 MHz: 1200 mV
• 1052 MHz: 1200 mV
• 1000 MHz: 1150 mV
• 952 MHz: 1125 mV
• 900 MHz: 1100 mV
• 852 MHz: 1075 mV
• 800 MHz: 1050 mV
• 750 MHz: 1025 mV
• 700 MHz: 1000 mV
• 650 MHz: 975 mV
• 600 MHz: 950 mV
• 550 MHz: 950 mV
• 500 MHz: 925 mV
• 450 MHz: 925 mV
• 400 MHz: 900 mV
• 350 MHz: 900 mV
• 300 MHz: 900 mV
• 250 MHz: 875 mV
• 200 MHz: 875 mV
• 150 MHz: 875 mV
• 100 MHz: 850 mV


• CPU-Tuning (Awake/Sleep)
Folgende Einstellungen habe ich gewählt:

• (CPU-Tuning Awake) Default CPU Governor > nightmare
• (CPU-Tuning Sleep) DeepSleep! CPU Governor > sleepy


• I/O (Scheduler)
Folgende Einstellungen habe ich gewählt:

• KILOBYTES TO READ-AHEAD > 2048 kb
• DEFAULT AWAKE I/O SCHEDULER > DEADLINE
• STANDBY/DEEPSLEEP I/O SCHEDULER > NOOP


• GPU
Folgende Einstellungen habe ich gewählt:

• 54 Mhz: 800 mV
• 108 Mhz: 800 mV
• 160 Mhz: 850 mV
• 200 Mhz: 900 mV
• 267 Mhz: 950 mV


• SCREEN
Folgende Einstellung habe ich gewählt:

• MAX_GAMMA: 20


• SOUND
Folgende Einstellungen habe ich gewählt:

• JB LOW SOUND FIX ON BOOT: Haken gesetzt (Enabled)
• HEADPHONE AMPLIFIER: Boost 3 dB
• MIC GAIN LEVEL: 4 dB
• SPEAKER LEVEL: 8 dB


• TWEAKS
Folgende Einstellungen habe ich gewählt:

• CORTEXBRAIN-BACKGROUND-PROCESS: Enable
• ANDROID LOGGER CONTROL: Auto


So, ich hoffe mit meinen Einstellungen dem einen oder anderem User hier in diesem Thread ein Vorgabe von Parametern als Hilfestellung gegeben zu haben und wäre wirklich erfreut, wenn der eine oder andere mal hier so seine Erlebnisse mit dem DorimanX Kernel einstellen würde .

@chrischaan

habe mir jetzt mal den Dori v7.47 installiert und ist soweit erst einmal unauffällig . Was mir aber aufgefallen ist, dass das System irgendwie jetzt schneller hochbootet, was vielleicht auch die Beschreibung "Kernel 7.47 Power BETA" erklären könnte, wer weiß .

Zitat von SaGaS

• SMOOTH SCALING LEVEL: 150 MHz

CFS SETTINGS
• GENTLE FAIR SLEEPERS: Haken gesetzt (Enabled)

• CPU-Voltage
Folgende Einstellungen habe ich gewählt:

• 200 MHz: 875 mV
• 150 MHz: 875 mV
• 100 MHz: 850 mV

• GPU
Folgende Einstellungen habe ich gewählt:

• 54 Mhz: 800 mV
• 108 Mhz: 800 mV
• 160 Mhz: 850 mV
• 200 Mhz: 900 mV
• 267 Mhz: 950 mV

1. Zu Smooth Scaling LvL: ist seit 7.47 Standard deaktiviert. Nur als Info, falls es dir noch nicht aufgefallen ist. Hab es gestern auch nur mehr zufällig gesehen. Schau mal in Stweaks rein, dazu steht auch was in der Beschreibung.
2. Zu Gentle Fair Sleepers: Warum Enabled? Der Beschreibungstext in Stweaks suggeriert ja eher, dass man es deaktiviert lassen soll =D Kläre mich bitte auf
3. Zu Cpu: Fährst du gut mit den zusätzlichen Frequenzen 100 & 150Mhz? Hatte das mal noch zu Zeiten vom Abyss Kernel von Angelom. Aber so richtig überzeugt hat mich das nie. gerade diese Freqs werden ja genutzt, wenn das Handy mal aus dem Deepsleep aufwacht und kleine Aufgaben zu erledigen hat. Dabei war meine Theorie immer, je schneller fertig mit der Aufgabe desto besser und dann wieder husch husch innen Deep Sleep. Die 100 bzw. 150 Mhz Freqs sind dazu aber bestimmt nicht förderlich. Werden die beiden Freqs denn im normalen Screen On Betrieb auch einigermaßen genutzt? Auf deinen Screenshots sind sie nämlich komplett ungenutzt (CPU Spy). Hast du vielleicht vergessen den Schieberegler weiter nach unten zu drehen oder zu dem Zeitpunkt noch nicht genutzt?
4. GPU: Ich hatte am Anfang auch diese UV-Werte genutzt. Nur hatte ich gerade bei grafisch intensivieren Anwendungen hin und wieder mal einen Freeze. Ich spreche natürlich von Spielen. Ich nutze mein Handy sehr, sehr selten zum Zocken. Die Freezes sind auch immer nur dabei aufgetreten. Hab es dennoch wieder hochgesetzt. 267Mhz @ 1000mV gelassen und dann bei der jeweils niedrigeren Freq -50mV. Aber das hab ich ja schon einmal gepostet. Ich meine nämlich auch mal gelesen zu haben, dass Dorimanx geraten hat die 267 Freq und alles darüber, insofern genutzt, nicht mit einer niedrigeren Spannung zu versorgen. Aber wenn es bei dir läuft, ist es natürlich top!
5. Zum Nightmare: habe jetzt auch seit gestern 7.47 drauf. Alles in allem läuft sie rund. Habe auch den Nightmare als Standard gelassen in Verbindung mit dem Zen Schedular (auch standard), aber so richtig warm bin ich damit noch nicht geworden. Anwendungen etc. öffnen alles zügig, da gibt es nichts zu meckern. Aber hin und wieder hatte ich einen größeren Lag beim scrollen, was meiner Meinung nach beim Pegasus nicht auftritt. Deshalb bin ich jetzt erstmal wieder zurück zu Pegasus/Sio. Aber ich werde den Nightmare jetzt nochmal am Wochenende aktivieren und schauen, ob das nicht übersensible Paranoias von mir waren. Gerade bei neuen Settings neigt man ja dazu, wieder etwas kritischer zu bewerten.

Und ne Info am Rande: Jkay hat sich gestern die neue XWLSD geflasht, das heißt ich werde wohl doch auf Jkay warten bevor ich entgültig auf JB wechsel =D Allzu lange kann es ja nicht mehr dauern. Über AllianceRom bzw. AllianceMod habe einfach zu oft negatives gelesen. Wenn dann käme sowieso nur die Neat in Frage.

@chrischaan

Zu Punkt 1:
Da hast du wohl recht, das es "disabled" in den Default Einstellungen vom Dori v7.47 ist , du kannst dies aber auch nutzen (also Enabled), wenn du darauf tippst und eine Eingabe tätigst, falls du es noch nicht ausprobiert haben solltest .

Zu Punkt 2:
Auch damit hast du nicht unrecht, mein Gedanke war eher, wenn du im DeepSleep bist und es kommt ein Wakelog, das dann dieser entsprechend schnell durchgeführt wird und somit nicht lange aktiv bleibt, um somit schnell wieder in den DeepSleep zu wechseln. Zumindestens habe ich das unter der Aktivität des "Gentle Fair Sleepers" verstanden, was dabei umgesetzt werden soll?

Zu Punkt 3:
Wie du in meinen Screenshots im Beitrag #53 treffend gesehen hast, wurden die Taktraten 100 MHz und 150 MHz komischerweise gar nicht genutzt wurden, obwohl diese von mir eingestellt sind . Das selbe ist auch im Nutzungsbetrieb nicht anders, also ich weiß auch nicht wozu dann die Einstellungen für 100 MHz und 150 MHz gut sein sollen? Was meinst du mit Schieberegler?

Zu Punkt 4:
Da bin ich immer noch am Testen, wann der Freeze einsetzt? Bis jetzt konnte ich nichts Nachteiliges feststellen, das z.B. das Display anfängt zu ruckeln oder zu freezen, wenn ich meine Navi-Software laufen lasse, im Gegenteil, im Moment läuft es ziemlich flüssig. Da ja bekannterweise das Display der Akku-Killer schlecht hin ist, versuche ich natürlich durch niedrige Spannungsversorgungen ein wenig auf den Akkuverbrauch gegenzusteuern. Das @dorimanx explizit darauf hinweist, keine zu niedrigen Spannungen für den Grafikprozessor über den Kernel aufzulegen ist aus seiner Sicht verständlich, damit dieser stabil läuft. Dennoch kann man ja mal testen wie weit man tatsächlich gehen kann, ohne dabei Probleme zu bekommen .

Zu Punkt 5:
Dein geschilderten Lag habe ich so noch nicht wahrgenommen, ausser dass das Scrollen nicht so flott läuft, aber es hingt auch nicht, oder ruckelt dabei. Für mich stellt sich das aber im Moment so da, als wenn da einer auf der Bremse steht .


Meinst du das JKay ein neues Framework Deluxe (Domination Theme) für die XWLSD entwerfen will? Wäre ja echt nicht schlecht, hatte dies auch genutzt bis zur XWLPG ICS 4.0.3, man konnte eine Menge an Einstellungen an der ROM vornehmen, unter anderem auch Icons im App Drawer tauschen . Da bin ich ja echt mal gespannt wann es soweit ist.


EDIT:

Habe mal nachgesehen wegen JKay und da schreibt er, das er wohl erst mit der XWLS8 beginnen will :
http://forum.xda-developers.com/show....php?t=1667846

@SaGaS:

zu 1: War mir schon klar, dass man Smooth Scaling wieder aktivieren kann. Sollte nur nen Hinweis sein, da du das ja genutzt hast

zu 2: ich werde mal ein wenig google bzgl. den fair sleepers

zu 3: Habe einen Screenshots angehängt. Unter "Min Frequency" den Regler meine ich. Mit dem bestimmt man die untere Schranke der genutzten CPU Freqs.


zu 4: Absolut sollte man das testen Ich versuch's auch nochmal mit -50mV =D

zu 5: naja, so richtig vergleichen können wir das auch nicht. Du bist auf JB und ich größtenteils auf ICS...

zu Jkay: Jkay hat schon zu Zeiten des Releases vom S3 gesagt, dass er sich jetzt erstmal um das S3 kümmern will und insofern JB für das S2 kommt, er dann damit weiterarbeiten möchte. 4.04 hat er immer bewusst ausgelassen. Zum einen wegen dem Brick Bug, zum anderen weil es im Grunde kaum Veränderungen zur 4.03 gab. Dazu dann noch das S3. Nachdem jetzt die erste JB für das S2 erschienen ist, hat er gesagt, dass er die letzte Version vom S3 Stable macht und dann sich wieder um das S2 kümmert. NeatRom mit seinen Mods oder auch der AllianceMod haben ihn zwar kurzzeitig verunsichert, ob seine Arbeit überhaupt noch gebraucht wird, ABER die User bei XDA haben ihn ganz schnell davon überzeugt, dass er gebraucht wird =D So viel zu der Story um Jkay^^

@chrischaan

Zu Punkt 1:
Weißt du vielleicht wieso @dorimanx das "Smooth Scaling Level" auf Disabled gestellt hat, den unter der v7.44 war der noch auf 200MHz eingestellt?

Zu Punkt 2:
Werde ich mir morgen auch nochmal genauer ansehen, was der "Gentle Fair Sleepers" bewirken soll.
Jedenfalls habe ich bis jetzt angenommen, das dieser eine schnellere Zuordnung zur CPU schafft, damit z.B. eine Tätigkeit einer App, die aus dem Tiefschlaf kommt , auch gleich genügend Unterstützung erhält, um die Aufgabe die jetzt durch die App umgesetzt werden, schnell erledigt werden kann. Dadurch sollen Aufgaben auch schneller eine Zuteilung bekommen und erledigt werden, um dann wieder in den DeepSleep zu wechseln, damit kein weiterer Akkuverbrauch entsteht.

Zu Punkt 3:
Danke dir für den Tipp, bei mir stand der Schieberegler bei MIN FREQUENCY noch auf 200 kHz, daher waren auch wahrscheinlich keine Aktivitäten unter 100 kHz und 150 kHz zu verzeichnen. Werde dies jetzt mal die nächsten Tage genauer beobachten und ob sich eventuell dadurch auch ein SOD einstellt, was ich aber nicht hoffe .

Zu Punkt 4:
Wie ich schon dazu geschrieben hatte, sind bei mir noch keine nachteiligen Erscheinungen aufgetreten, obwohl die Spannungen schon recht tief eingestellt sind. Mal schauen wie sich das jetzt die nächsten Tage verhält, sollte sich wiedererwartend etwas tun, werde ich dazu dann auch etwas schreiben, OK.

Zu Punkt 5:
Siehste, das habe ich ganz vergessen, das du ja noch auf der ICS unterwegs bist . Also wenn du dich irgendwann für die Jelly Bean NeatROM entscheiden solltest, dann wirst du den Unterschied zu ICS wirklich wahrnehmen. Da gibt es diese hackler oder ruckler beim Scrollen nicht, wie du es jetzt noch auf der ICS erlebst.


Zu JKay:
Also meiner Meinung nach findet sich in der NeatROM vieles wieder, was man z.B. bei dem Domination Theme von @Vertumus kennengelernt hat, was mir persönlich auch gut gefallen hat und z.B. auch in der GoaROM enthalten war. Was die Mods von JKay betrifft, so würde ich es auch begrüßen, wenn man mehr Möglichkeiten hätte eine andere Akkuanzeige, Signalanzeige oder auch Statusbar einstellen zu können. Ich kann schon nachvollziehen, das @JKay die ICS 4.0.4 ausgelassen hat, aber wiederrum auch viele User damit verärgerte, weil sie ja für seine App bezahlt haben, um entsprechende Änderungen an der installierten ROM vornehmen zu können.

Ich hoffe nur das @JKay sich auch wirklich um das S2 wieder ein wenig mehr bemüht, da auch ich seine Arbeit sehr zu schätzen gelernt habe, weil sich vieles halt nach eigenem Ermessen verändern ließ. Somit war es dann auch möglich, sich sein ohnehin schon gutes ausgesuchtes Custom-ROM noch nach eigenen Wünschen anzupassen, zu verschönern . Drücken wir mal die Daumen das @JKay wieder richtig Fahrt aufnimmt und als bald wieder ein Update für die Jelly Bean Firmwares kreiert.

@chrischaan

So habe nun mal ein paar Screenshots von dem Handy mit dem neuen Dorimanx Kernel v7.47 gemacht, welchen Akkuverbrauch ich in 12 Std. Nichtnutzungszeit mit den Einstellungen aus meinem Beitrag #53 und der Reduzierung der MIN FREQUENCY von 200 kHz auf 100 kHz hatte:




Anschließend habe ich über BetterBatteryStats noch mal Screenshots von den angesprochenden CPU Taktungen gemacht, welche in dieser Nichtnutzungszeit von 12 Std. durch Wakelogs aufgetreten sind:




Wie man erkennen kann, ist jetzt auch die untere Taktung von 100 kHz bedient worden (nach der Reduzierung der MIN FREQUENCY auf 100 kHz) und es wurde dadurch auch kein SOD ausgelöst, was meine Vermutung bestätigt, das dieser SOD wahrscheinlich nur mit bestimmten installierten ROMs zusammenhängt und anscheinend mit der NeatROM nicht auftritt. Es ist also aus meiner Sicht kein DorimanX Kernel typisches Problem, sondern eher ein Custom-ROM typisches Problem, welches anscheinend in der Ausarbeitung der Custom-ROMs zu suchen ist.

Hatte jetzt auch gelesen, das sich zu der AllianceROM und Miui-ROM auch noch die Chameleon-ROM mit in die Riege der Custom-ROMs eingereiht hat, welche mit den SODs zu tun haben. Was ich auch interessant fand, das die User die diesen SOD beklagt haben, überwiegend mit Tweak-Apps arbeiten und vorrangig mit ExTweaks und NSTools, welches bei mir ebenfalls ein Lichtchen aufgehen ließ . Also im Moment kann ich nur eines sagen, die NeatROM Lite v4.2 läuft in Verbindung mit dem DorimanX Kernel v7.47 und der STweak App wirklich richtig gut und vor allem, rund.

@SaGaS:

zu Punkt 1:
also in der Beschreibung in der STweaks-App steht jetzt, dass man den Governor entscheiden lassen soll (etwas frei übersetzt ). Ich denke, dass die viel an dem Nightmare GOV gewerkelt haben und sie den so erweitert haben, dass er logische Taktschritte nimmt. Vielleicht waren die anderen GOVs die Smooth Scaling nutzen können nicht so "intelligent" und darum gab es diese Einstellungsmöglichkeit. Aber das ist alles nur Interpretation meinerseits. Wüsste allerdings momentan auch keine andere logische Erklärung =D

zu JKay:
der Vorteil an Jkay ist erstmal, dass es wirklich sehr, sehr sauber programmiert ist und immer perfekt ins System integriert war. Es war so schön unauffällig. Habe ich Freunden mein Handy gegeben, wären sie niemals auf die Idee gekommen, dass das nachträglich reingemodded war. Habe bis jetzt ja nur kurze Einblicke in die NeatRom-Mods machen können, aber mein Eindruck war, dass es schon gut ist, aber eben doch alles von irgendwo zusammengesucht und dann fertig gekocht wurde. Wenn man mal sieht, wie lange dann doch JKay immer braucht um seine Anpassungen vorzunehmen und wie schnell es dann im Vergleich bei anderen "Devs" geht... und ich denke nicht, dass das daran liegt, dass JKay irgendwie langsam arbeitet

zu 100Mhz-Taktung:
Hast du denn sonst irgendwie Nachteile festellen können? Z. B., dass das Aufwachen des Handys etwas länger dauert? Also irgendwelche Performance-Einbußen?

Wunsch:
Kannst du mir dein Hintergrund-Bild zukommen lassen? Das ist so schön schlicht =D (und dazu noch schwarz=akku sparend^^)