[FAQ] Kernelparameter-Einstellungen (UV, OC, UC, Governor)

Diskutiere [FAQ] Kernelparameter-Einstellungen (UV, OC, UC, Governor) im Google Android Forum Forum im Bereich Smartphone Betriebssysteme; Wir werden tagtäglich mit Fachausdrücken aus der Kernel-Szene konfrontiert, aber kaum einer weiß, was sich dahinter verbirgt und inwieweit man die...
M

Mr. Green

Gast
Wir werden tagtäglich mit Fachausdrücken aus der Kernel-Szene konfrontiert, aber kaum einer weiß, was sich dahinter verbirgt und inwieweit man die Kernel tunen kann.

Ich möchte hier Tweaken der Kernel und deren Adjutanten, den Governor, erklären.
Man kann zwar einige Parameter via Voltage Control und SetCPU einstellen, doch gibt es seit Neuem einige Einstell-Apps seitens der Kernel-Programmierer wie N.E.A.K., Siyah oder Thoravukk, welche eine komplexere und auch effektivere Möglichkeit bieten die Kernel-Parameter zu verändern.

Zuerst möchte ich die herkömmliche Weise vorstellen: Die Scripte bzw. init.d-Scripte.

Was ist ein Script?

Ein Script ist eine Datei, in welcher Einstell-Parameter von Kernel, Governor, Scheduler, CPUs und und und mit speziellen Werten hinterlegt sind (z.B. für bessere Performance oder Akkulaufleistung).

Viele Scripte werden im init.d-Ordner hinterlegt, da dieser Ordner so etwas wie ein Autostart-Ordner wie bei Windows ist, d.h. die Scripte, die dort hinterlegt sind, werden automatisch nach dem Systemstart ausgeführt.

Es gibt auch einige Kernel-spezifische Scripte, die besondere Einstellungen des Kernels und dessen Zusammenspiel mit der Doppel-Kern-CPU haben, aber diese sind für uns erst mal nicht von Bedeutung. Wir müssen ja schließlich nicht Ingenieurswesen studieren, sondern es reicht, wenn wir eine solide Grundlage zur besseren Nutzung im Alltag mit unserem Android-Gerät bekommen.

Ich möchte auch darauf hinweisen, dass nicht jedes Tweak mit jedem Kernel kooperiert, aber bei den bekanntesten Kernel wie Siyah, N.E.A.K., RedPill und Tegrak etc. sollte es funktionieren.

Vorweg, wenn man diesen Thread am Ende einigermaßen verstanden hat und jeder nun sein Android-Gerät nach seinen Wünschen tweaken will, müssen einige Regeln beachtet werden:
man erstellt eine Datei ohne irgend eine Endung und fügt in diese seine Parameter etc. ein
man muss darauf achten, dass man sein Script nicht vor den anderen Scripten ausführen lässt, daher gibt es einen sogenannten Sleep-Befehl, der in Sekunden angibt nach wie vielen x Sekunden nach dem Start des Handys das Script ausgeführt werden soll
Man sollte stets darauf achten, dass, wenn man mehrere Scripte benutzt, zwar diese die gleichen Parameter haben können und dürfen, aber man nie unterschiedliche Werte für die gleichen Parameter nutzt darf, denn damit kann das System nichts anfangen und es kann unter Umständen euer System bremsen
das Script muss nachher in den Ordner init.d kopiert werden, welcher folgenden Pfad hat /system/etc/init.d

Prozesse

Unter Android gibt es fünf verschiedene Arten von Prozessen:

Active Processes
Visible Processes
Started Service Processes

Background Processes
Empty Processes

(Sehr hohe Priorität, hohe Priorität, geringe Priorität)

Jedem Prozess wird die höchstmögliche Priorität zugewiesen. Benötigt das System mehr Leistung, werden Prozesse der Priorität nach geordnet gekillt (hier also von unten nach oben).

Welche Priorität und wieviel Rechenzeit und -leistung ein Prozess bekommt, regelt der "nice value". Der Prozess mit der höchsten Priorität bekommt letztlich die meiste Rechenleistung zugewiesen.

Jetzt werde ich mal einige konfigurierbare Parameter von Governor vorstellen, welche nach eigenem Ermessen später einstellbar sind, entweder via Scripte oder Apps.

Man darf nie vergessen, dass unterschiedliche Governor auch unterschiedliche Parameter haben, aber die, die wir behandeln werden - ONDEMAND, CONSERVATIVE, SMARTASS V2, LULZACTIVE und INTERACTIVE - sollten i.d.R. diese Hauptmerkmale haben:

Sampling Time/Rate wird in µS (Millisekunden) gemessen und wird durch die Polling-Funktion, also wie oft abgefragt und entschieden werden soll, gesteuert, d.h. die Frequenz, also die Häufigkeit der Abfrage, wird entweder runterskaliert, also verkleinert die Häufigkeit der Abfrage, oder wird hochskaliert, also vergrößert die Häufigkeit der Abfrage. Einige Governor haben unterschiedliche Abtast- bzw. Abfragezeiten für das Hochskalieren und Runterskalieren.
Thresholds gibt den Schwellenwert in Prozent an, als den Grenzwert der CPU-Last. Wenn die CPU-Last diesen Punkt, x %, erreicht, skaliert der Governor die CPU hoch oder runter. Die meisten Governor haben Niedrig- und Hoch-Schwellenwerte von Haus aus, die die CPU entweder hoch- oder runterskalieren, und fest integriert sind.

Interactive

[Parameter]

hispeed_freq - Es wird auf diese Frequenz skaliert, wenn die lower Speed, also die langsamere Geschwindigkeit, nicht ausreicht und unter Last zu platzen droht, dann wird auf die höhere Geschwindikgkeit skaliert (Standard-Wert ist die Skalierung auf max_freq)

go_hispeed_load - Es wird auf die höhere Geschwindigkeit skaliert, wenn die CPU genau oder oberhalb dieses Wertes ist. Ähnlich wie bei den anderen Governorn up_threshold.

min_sample_time - Die Mindestzeit innerhalb einer Frequenz bis runtergefahren wird.

timer_rate - Die Abtastrate bzw. Abfragegeschwindigkeit des Zeitgebers, um eine Frequenz zu erhöhen.

[Beispiel-Tweak-Script]

1. Mehr auf batterieschonend eingestellt

Interactive und batterieschonend passt so zusammen wie Luciano Pavarotti und Justin Bieber. Probieren kann man es, indem die hispeed_freq limitiert wird.

Code:
#!/system/bin/sh

sleep 25
echo "95" > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load
echo "1000000" > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
echo "10000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate
2. mehr auf Performance/Leistung eingestellt

Code:
#!/system/bin/sh

sleep 25
echo "80" > /sys/devices/system/cpu/cpufreq/interactive/go_hispeed_load
echo "1400000" > /sys/devices/system/cpu/cpufreq/interactive/hispeed_freq
echo "40000" > /sys/devices/system/cpu/cpufreq/interactive/min_sample_time
echo "20000" > /sys/devices/system/cpu/cpufreq/interactive/timer_rate
Ondemand

[Parameter]

sampling_rate - Gemessen wird in µS und gibt an, wie oft der Kernel die CPU-Auslastung überprüfen soll und entsprechend entscheidet und reagiert, d.h. was mit der Takt-Frequenz geschehen soll. Höhere Werte bedeuten, dass CPU-Abfragen seltener gestellt werden. Für niedrigere Frequenzen kann das von Vorteil sein, da dadurch nicht gleich sofort zur nächsten Taktstufe gesprungen wird und bei höheren Frequenzen wird dadurch schneller runterskaliert.

up_threshold - Gemessen in Prozent, von 1 - 100. Dies bedeutet, wenn die CPU-Last diesen Schwellen- bzw. Grenzwert erreicht hat, wird der Governor die CPU hochskalieren. Höhere Werte bedeuten weniger Reaktionsfähigkeit, aber dafür Akkuersparnis und niedrigere Werte höhere Reaktionsfähigkeit, aber dafür ein höherer Akkuverbrauch.

powersave_bias - Standardwert ist 0 (Null). Wird ein hoher Wert festgelegt, beeinflusst dies den Governor in niedrigeren Frequenz-Schritten zu skalieren. Verwendet man diese Funktion, wird die CPU weniger Zeit für höhere Frequenzen aufbringen. Eine bessere Alternative wäre, dass man auf eine niedrigere Frequenz untertaktet als die Verwendung von powesave_bias, weshalb die meisten Devs von Vornherein diese Funktion mit 0 belegen.

sampling_down_factor - Dieser Parameter bestimmt wie oft die CPU bei höheren Frequenzen sich aufhält, wenn sie real beschäftigt ist. Vorgabe ist, schnell sich auf niedrigere Frequenzen umzustellen = 1. d.h. ist der Wert für sampling_down_factor auf 1 gesetzt, ändert sich an dem bestehendem Verhalten des nicht-modifizierten Ondemand nichts, aber jeder andere Wert größer 1 bedeutet einen neuen Multiplikator für das Scheduling-Intervall, was eine Neubewertung der Last zu Grunde legt, wenn die CPU die höchste Taktfrequenz (die scaling_max_freq) wegen hoher Last erreicht. Dies verbessert die Leistung durch eine Verringerung des Aufwands der Last-Auswertung und hilft die CPU bei der höchsten Frequenz zu halten, wenn sie real ausgelastet ist, statt sie ständig hin und her takten zu lassen, was mehr Akkuleistung bedeuten würde. Diese Abstimmung hat keinen Einfluss auf das Verhalten bei niedrigeren Frequenzen/ niedrigerer CPU-Last.

down_differential - Dieser Faktor berechnet indirekt den down_threshold, also den Niedrig-Schwellewert, des Ondemand. Nach Fertigstellung von sampling_down_factor * sampling_rate bei maximaler Frequenz aufgrund von hoher Auslastung, probiert der Governor die Last erneut aus, um eine Schätzung der neuen Soll-Frequenz zu berechnen und erreicht dies, indem er die niedrigste Frequenz wählt, die den up_threshold nicht auslöst. Die Ziel-Frequenz wird folgendermaßen berechnet: max_load_freq/(up_threshold - down_differential). Sollte der erhaltene Wert nicht in der Frequenz-Tabelle enthalten sein, wird zum nächsten Wert abgerundet. max_load_freq ist die theoretische Frequenz, bei der die CPU 100% arbeiten kann. I.d.R ist es ein Wert unter scaling_max_freq.

[Beispiel-Tweak-Script]

1. Mehr auf batterieschonend eingestellt

Um den Ondemand dazu zu bringen, dass er batterieschonend sich verhält, setzt man einen hohen up_threshold und eine hohe sampling_rate. Dadurch fragt der Governor weniger häufig ab und skaliert weniger häufig hoch.

Code:
#!/system/bin/sh

sleep 25
echo "95" /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo "120000" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
echo "1" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo "5" > /sys/devices/system/cpu/cpufreq/ondemand/down_differential
2. mehr auf Performance/Leistung eingestellt

Um den Ondemand dazu zu bringen, dass er performanter/leistungsstärker sich verhält, setzt man einen niedrigen up_threshold und eine niedrige sampling_rate. Dadurch fragt der Governor häufiger ab und skaliert häufiger hoch.

Code:
#!/system/bin/sh

sleep 25
echo "70" /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo "40000" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_rate
echo "2" > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor
echo "15" > /sys/devices/system/cpu/cpufreq/ondemand/down_differential
SmartassV2

[Parameter]

awake_ideal_freq - Das ist die Frequenz, bei der die CPU schnell wach wird, d.h.es wird ganz schnell hochskaliert um aus dem DeepSleep bzw. Tiefschlaf zu kommen. Danach skaliert die CPU wieder weniger aggressiv hoch.

sleep_ideal_freq - Das ist die Frequenz, bei der die CPU schnell in den DeepSleep bzw. Tiefschlaf runterskaliert, wenn der Display ausgeschaltet wird. Danach skaliert die CPU weniger aggressiv runter.

up_rate_us - Die Mindestzeit innerhalb einer Frequenz bis runtergefahren wird.

down_rate_us - Die Mindestzeit innerhalb einer Frequenz bis hochgefahren wird.

max_cpu_load - Ist das Gleiche wie up_threshold von anderen Governorn.

min_cpu_load - Ist das Gleiche wie down_threshold von anderen Governorn.

ramp_down_step - Das sog. Frequenz-Dreieck tritt ein, wenn unterhalb der idealen Frequenz runter gesprungen wird. Null deaktiviert es und es wird das Runterspringen nach heuristischer Last berechnet. Wenn man über der idealen Frequenz ist, wird immer zur idealen Frequenz runter gesprungen.

ramp_up_step - Das ist die Frequenz, wenn über die ideale Frequenz hoch gesprungen wird. Null deaktiviert es und verursacht immer einen Sprung direkt zur max-Frequenz. Wenn man unterhalb der i
dealen Frequenz ist, wird immer zur idealen Frequenz hoch gesprungen.

sleep_wakeup_freq - Die einzustellende Frequenz beim Aufwachen aus dem DeepSleep. Wenn sleep_ideal_freq = 0, dann wird dies keine Auswirkung haben.

[Beispiel-Tweak-Script]

1. Mehr auf batterieschonend eingestellt

Code:
#!/system/bin/sh

sleep 25
echo "500000" > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq;
echo "500000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq
echo "85" > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load;
echo "70" > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step;
echo "48000" > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us
echo "49000" > /sys/devices/system/cpu/cpufreq/smartass/down_rate_us
2. mehr auf Performance/Leistung eingestellt

Code:
#!/system/bin/sh

sleep 25
echo "800000" > /sys/devices/system/cpu/cpufreq/smartass/awake_ideal_freq;
echo "200000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_ideal_freq;
echo "800000" > /sys/devices/system/cpu/cpufreq/smartass/sleep_wakeup_freq
echo "75" > /sys/devices/system/cpu/cpufreq/smartass/max_cpu_load;
echo "45" > /sys/devices/system/cpu/cpufreq/smartass/min_cpu_load;
echo "0" > /sys/devices/system/cpu/cpufreq/smartass/ramp_up_step;
echo "0" > /sys/devices/system/cpu/cpufreq/smartass/ramp_down_step;
echo "24000" > /sys/devices/system/cpu/cpufreq/smartass/up_rate_us
echo "99000" > /sys/devices/system/cpu/cpufreq/smartass/down_rate_us
Conservative

[Parameter]

down_threshold - wie bei den anderen Governorn zuvor

up_threshold - wie bei den anderen Governorn zuvor

sampling_down_factor - wie bei den anderen Governorn zuvor

sampling_rate - wie bei den anderen Governorn zuvor

freq_step - Legt fest, wie hoch der Conservative die CPU-Geschwindigkeit zu jedem Zeitpunkt der CPU-Last erhöht, wenn up_threshold erreicht ist (wird in Prozent der maximalen CPU-Geschwindigkeit angegeben)

ignore_nice_load - Es gibt zwei Einstellungsmöglichkeiten: 0 und 1. Bei 0 (Standard) werden alle Prozesse gleich behandelt bei der Berechnung der aktuellen Systemleistung (der errechnete Wert regelt dann, ob mehr Leistung benötigt wird oder nicht). Ist der Wert 1 eingestellt, werden alle Prozesse mit einem "nice value" in dieser Berechnung ignoriert und nicht gekillt. Dadurch wird der Prozessor später hochgetaktet. Prozesse mit einer höheren Priorität benötigen allerdings länger, um abgarbeitet zu werden, da die eigentlich benötigte Rechenleistung ja von den Prozessen mit einem "nice value" blockiert wird.

[Beispiel-Tweak-Script]

1. Mehr auf batterieschonend eingestellt

Stellt man freq_step auf einen niedrigeren Wert, wird der Conservative mehr Akku sparen.

Code:
#!/system/bin/sh

sleep 25
echo "95" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold
echo "120000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
echo "1" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor
echo "40" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold
echo "10" > /sys/devices/system/cpu/cpufreq/conservative/freq_step
echo "1" > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load
2. mehr auf Performance/Leistung eingestellt

Code:
#!/system/bin/sh

sleep 25
echo "60" > /sys/devices/system/cpu/cpufreq/conservative/up_threshold
echo "40000" > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
echo "5" > /sys/devices/system/cpu/cpufreq/conservative/sampling_down_factor
echo "20" > /sys/devices/system/cpu/cpufreq/conservative/down_threshold
echo "25" > /sys/devices/system/cpu/cpufreq/conservative/freq_step
echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load
Lulzactive

[Parameter]

inc_cpu_load - In der vorherigen Version war dieser Parameter hardcoded, also fest eingestellt, bis 60. Jetzt ist es vom Benutzer einstellbar. Das ist die Frequenz, bei der der Governor nach oben/unten skaliert. Ist die Last <inc_cpu_load, dann skaliert die CPU runter, ist die Last >inc_cpu_load, dann skaliert die CPU hoch.

pump_up_step - Wenn die Last >=inc_cpu_load, dann werden keine Skalierungsschritte nach oben vollzogen

pump_down_step - Wenn die Last <inc_cpu_load, dann werden keine Skalierungsschritte nach unten vollzogen

screen_off_min_step - Gibt die Stufen in der Frequenz-Tabelle an, wenn der Display ausgeschaltet ist. Beispiel: Verfügbar sind sind die Frequenzen 1600 1400 1200 1000 800 500 200 100 (L0 bis L7) und screen_off_min_step = 5, dann bedeutet es, dass bei ausgeschaltetem Display die Frequenzen 100 200 und 500 (L5 bis L7) bei Bedarf genutzt werden können.

down_sampling_time - Abfrage-Zeit um die CPU runter zu skalieren. Erlaubt sind Werte zwischen 10.000 und 50.000.

up_sampling_time - Abfrage-Zeit um die CPU hoch zu skalieren. Erlaubt sind Werte zwischen 10.000 und 100.000.

[Beispiel-Tweak-Script]

1. Mehr auf batterieschonend eingestellt

Dieser Tweak bringt den Lulzactive dazu, die CPU schrittweise hoch zu skalieren und bei niedriger Last schnell runter zu skalieren.

Code:
#!/system/bin/sh

sleep 25
echo "90" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step
echo "2" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "50000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "6" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step
2. mehr auf Performance/Leistung eingestellt

Dieser Tweak bringt den Lulzactive dazu, die CPU schnell hoch zu skalieren, oft abzufragen und bei niedriger Last schrittweise runter zu skalieren.

Code:
#!/system/bin/sh

sleep 25
echo "60" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "4" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "10000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "70000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step
3. Gleichgewicht zwischen Performance und Akkuersparnis

Dieser Tweak bringt den Lulzactive dazu, die CPU öfter abzufragen und bis zu 4 Stufen über der aktuellen Frequenz hoch zu skalieren, aber nur bei 90% Last. Die CPU wird normal runter skaliert.

Code:
#!/system/bin/sh

sleep 25
echo "90" > /sys/devices/system/cpu/cpufreq/lulzactive/inc_cpu_load
echo "4" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_up_step
echo "1" > /sys/devices/system/cpu/cpufreq/lulzactive/pump_down_step
echo "10000" > /sys/devices/system/cpu/cpufreq/lulzactive/up_sample_time
echo "40000" > /sys/devices/system/cpu/cpufreq/lulzactive/down_sample_time
echo "5" > /sys/devices/system/cpu/cpufreq/lulzactive/screen_off_min_step
Anleitung für init.d-Scripte:

Der Android-Bootup-Prozess beinhaltet 3 Teile.
Zuerst wird der Bootloader ausgeführt.
Dann bootet der Kernel und er lädt diverse Treiber, bereitet einige Hardware-Komponenten vor.
Zuallerletzt werden die Benutzer-spezifischen Programme eingebunden. Das ist die wichtige Phase, wo diverse init.d-Scripte ausgeführt werden, genauso wie diverse App und Dienste.

Init.d-Scripte müssen innerhalb des init.d-Ordners sein, welcher im Verzeichnis /system/etc/ ist. Es gibt auch ein Verzeichnis mit /etc/init.d, welches nur ein Symlink zum obigen Verzeichnis ist.

Init.d-Scripte werden in alphabetischer bzw. numerischer Reihenfolger aufsteigend ausgeführt.

Beispiel 1: Ascript1 und Bscript2 = Ascript1 wird zuerst ausgeführt
Beispiel 2: Ascript1 und Ascript2 = Ascript1 wird zuerst ausgeführt

Erstellungsvorgang
Die erste Zeile eines init.d-Scriptes beginnt entweder mit #!/sbin/busybox sh oder #!/system/bin/sh
Danach startet das Script mit entsprechenden Befehlen wie z.B. echo "200000" > /sys/devices/system/cpu/spu0cpufreq/scaling_max_freq
Für die Kompatibilität darf keiner der Windows-Editoren wie Notepad oder Wordpad benutzt werden, sondern ein GNU-Editor, am Besten ihr nimmt den Notepad++
Weder am Anfang noch am Ende darf keine Leerzeile vorhanden sein, also lieber schön überprüfen!
Nachdem alles fertig ist, speichert man das Script ohne jegliche Datei-Endung. Der Name ist frei wählbar, aber sollte mit Bedacht gewählt sein.
Danach wird das selbst erstellte Script in den init.d-Ordner via eines rootfähigen Filemanagers, am Besten den rootexplorer, verschoben und danach die Permissions angepasst. Welche man nehmen muss, sieht man am Besten daran, welche die anderen Scripte in dem init.d-Ordner haben.
Wenn man etwas im Script kommentieren möchte, wird einfach ein # gesetzt, dadurch wird alles nach der Raute nicht berücksichtigt und ausgeführt.
 
Zuletzt bearbeitet:
M

Mr. Green

Gast
Kernelparameter-Einstellungen (UV, OC, UC, Governor)

Hier stelle ich einige Scripte vor, die ihr nach eigenem Ermesse ändern könnt, deshalb sollen jene als Vorgaben dienen:

Ein akkusparendes Script:

S1siyah

Code:

#!/system/bin/sh
#hotplug parameters
echo 35 > /sys/module/pm_hotplug/parameters/loadl
echo 80 > /sys/module/pm_hotplug/parameters/loadh
echo 90 > /sys/module/pm_hotplug/parameters/loadl_scroff
echo 100 > /sys/module/pm_hotplug/parameters/loadh_scroff
echo 400 > /sys/module/pm_hotplug/parameters/rate
echo 400 > /sys/module/pm_hotplug/parameters/rate_cpuon
echo 1000 > /sys/module/pm_hotplug/parameters/rate_scroff
echo 524288 > /sys/module/pm_hotplug/parameters/freq_cpu1on
Grenzen bzw. CPU-Auslastungen, bei denen der zweite Kern ein/ausgeschaltet wird, wie lang er an bleibt und wie oft die Auslastung abgefragt wird. Höhere Werte sind akkuschonend, bis auf die CPU_freqs, da niedriger.

Code:
#deepsleep levels
echo 4 > /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_cpulevel
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_buslevel
Max Takt im Deepsleep sowie Deepsleep Buslevel. in dem Fall sollten das 500 Mhz auf dem niedrigsten FSB sein. Das echo 4 gibt den max Takt als Stufe an, also 4 Stufen ab der niedrigsten.

Code:

#smooth scaling parameters
echo 3 > /sys/devices/system/cpu/cpu0/cpufreq/smooth_target
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/smooth_offset
echo 1 > /sys/devices/system/cpu/cpu0/cpufreq/smooth_step
Nicht 100%ig sicher, sollten aber die Taktsprünge bei Belastung sein. sprich, wenn die CPU zu x % ausgelastet ist, wird in die nächsthöhere / niedrigere Taktstufe gewechselt. echo gibt an, ob Stufe für Stufe
gesprungen wird oder direkt auch mehrere Stufen übersprungen werden
können.

Auf Performance ausgerichtetes Script:

S1siyah

Code:

#!/sbin/busybox sh
#hotplug parameters
echo 20 > /sys/module/pm_hotplug/parameters/loadl
echo 50 > /sys/module/pm_hotplug/parameters/loadh
echo 30 > /sys/module/pm_hotplug/parameters/loadl_scroff
echo 70 > /sys/module/pm_hotplug/parameters/loadh_scroff
echo 200 > /sys/module/pm_hotplug/parameters/rate
echo 1200 > /sys/module/pm_hotplug/parameters/rate_cpuon
echo 800 > /sys/module/pm_hotplug/parameters/rate_scroff
echo 131072 > /sys/module/pm_hotplug/parameters/freq_cpu1on
#cpu freq
echo 200000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 1400000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
#deepsleep levels
echo 3 > /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_cpulevel
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_buslevel
#smooth scaling parameters
echo 0 > /sys/devices/system/cpu/cpu0/cpufreq/smooth_target
echo 2 > /sys/devices/system/cpu/cpu0/cpufreq/smooth_offset
echo 2 > /sys/devices/system/cpu/cpu0/cpufreq/smooth_step
#cpu governor
echo conservative > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 60 > /sys/devices/system/cpu/cpufreq/conservative/up_threshold
echo 30 > /sys/devices/system/cpu/cpufreq/conservative/down_threshold
echo 5 > /sys/devices/system/cpu/cpufreq/conservative/freq_step
echo 10000 > /sys/devices/system/cpu/cpufreq/conservative/sampling_rate
#gpu clock, threshold and voltage
echo "160 267" > /sys/class/misc/gpu_clock_control/gpu_control
echo "55% 25%" > /sys/class/misc/gpu_clock_control/gpu_control
echo "950000 1000000" > /sys/class/misc/gpu_voltage_control/gpu_control
#io scheduler
echo bfq > /sys/block/mmcblk0/queue/scheduler
#static bus frequency
echo "0 0 0 0 0 1 1 2" > /sys/devices/system/cpu/cpu0/cpufreq/busfreq_static
echo enabled > /sys/devices/system/cpu/cpu0/cpufreq/busfreq_static
#enable sched_mc
echo 1 > /sys/devices/system/cpu/sched_mc_power_savings
#enable AFTR
echo 2 > /sys/module/cpuidle/parameters/enable_mask
#brightness settings
echo 30 > /sys/class/misc/brightness_curve/min_bl
echo 1 > /sys/class/misc/brightness_curve/min_gamma
echo 24 > /sys/class/misc/brightness_curve/max_gamma
 
Thema:

[FAQ] Kernelparameter-Einstellungen (UV, OC, UC, Governor)

Sucheingaben

governor einstellungen

,

lulzactive richtig einstellen

,

governor lulzactive

,
lulzactive settings
, smooth scaling level, siyah kernel governor, governor settings, smartassv2 erklärung, cyanogen 10 change smartass parameters, cpu governor lulzactive, siyah kernel bester governor und scheduler, interactive governor settings, cpu governor erklärung, siyah kernel beste einstellungen, governor settings android, governor erklärung, init.d android, lulzactive optimale uv settings, lulzactive governor, android governor ändern, lulzactiveq, governor interactive settings, smooth scaling level android, cpu einstellung android, lulzactive einstellungen

[FAQ] Kernelparameter-Einstellungen (UV, OC, UC, Governor) - Ähnliche Themen

  • [Free] Grand Battle General FAQ

    [Free] Grand Battle General FAQ: Hello, GB commander! Since Grand Battle is always full of surprises, you may have many opportunities to gain props and cards to defeat more...
  • [Free Game] [Android] Grand Battle FAQ

    [Free Game] [Android] Grand Battle FAQ: Hi, guys and gals. Since Grand Battle has been updated to version 6.0, more and more game lovers are becoming Grand Battle fans. They share game...
  • Trotz WhatsApp-Hilfe (FAQ) immer noch doppelte Kontakte..

    Trotz WhatsApp-Hilfe (FAQ) immer noch doppelte Kontakte..: Hi. ich habe eben ein paar ruhige Minuten damit verbracht zu Creedence Clearwater Revival etwas mein Kontaktbuch (cobook) zu sortieren. Altes...
  • [FAQ] Kernel-Governors, Modules, I/O Schedulers,.........

    [FAQ] Kernel-Governors, Modules, I/O Schedulers,.........: Da viele Governors und Scheduler für großteils der Android-geräte gedacht ist und nicht nur für das S2, dachte ich mir, dass es eher hierher...
  • iOS 4.3 ist da!!! FAQ

    iOS 4.3 ist da!!! FAQ: Nun ist iOS 4.3 offiziell in iTunes verfügbar viel Spaß damit.. Jailbreak und unlock angewiesene NOCH nicht updaten. Und gleich noch ne Frage...
  • Ähnliche Themen

    • [Free] Grand Battle General FAQ

      [Free] Grand Battle General FAQ: Hello, GB commander! Since Grand Battle is always full of surprises, you may have many opportunities to gain props and cards to defeat more...
    • [Free Game] [Android] Grand Battle FAQ

      [Free Game] [Android] Grand Battle FAQ: Hi, guys and gals. Since Grand Battle has been updated to version 6.0, more and more game lovers are becoming Grand Battle fans. They share game...
    • Trotz WhatsApp-Hilfe (FAQ) immer noch doppelte Kontakte..

      Trotz WhatsApp-Hilfe (FAQ) immer noch doppelte Kontakte..: Hi. ich habe eben ein paar ruhige Minuten damit verbracht zu Creedence Clearwater Revival etwas mein Kontaktbuch (cobook) zu sortieren. Altes...
    • [FAQ] Kernel-Governors, Modules, I/O Schedulers,.........

      [FAQ] Kernel-Governors, Modules, I/O Schedulers,.........: Da viele Governors und Scheduler für großteils der Android-geräte gedacht ist und nicht nur für das S2, dachte ich mir, dass es eher hierher...
    • iOS 4.3 ist da!!! FAQ

      iOS 4.3 ist da!!! FAQ: Nun ist iOS 4.3 offiziell in iTunes verfügbar viel Spaß damit.. Jailbreak und unlock angewiesene NOCH nicht updaten. Und gleich noch ne Frage...
    Oben