1. Nimm jetzt an unserem 2. ADVENT-Gewinnspiel teil - Alle Informationen findest Du hier!

[Tweaks]Kernel-Parameter-Einstellungen (Governor, OC, UV)

Dieses Thema im Forum "Kernel für Samsung Galaxy S2" wurde erstellt von mecss, 12.03.2012.

  1. mecss, 12.03.2012 #1
    mecss

    mecss Threadstarter Ehrenmitglied

    Beiträge:
    16,308
    Erhaltene Danke:
    11,089
    Registriert seit:
    14.03.2010
    Phone:
    Samsung Galaxy Note 3
    Hallo liebe SGS2-Gemeinde!

    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 tweaken, also aufmotzen - frisieren - modden, kann.

    Ich möchte hiermit einen kleinen Beitrag zum Tweaken der Kernel und deren Adjutanten, den Governor, leisten. Man kann zwar einige Parameter via Voltage Control und SetCPU und Co. einstellen, doch gibt es seit Neuem einige Einstell-Apps seitens der Kernel-Hersteller wie N.E.A.K. und Siyah, welche eine komplexere und auch effektivere Möglichkeit bieten die Kernel-Parameter zu verändern.

    Die folgenden Erkenntnisse basieren auf Basis des Threads von droidphile aus dem XDA, welchem ich hiermit aus ganzem Herzen danken möchte.

    [REF][TWEAKS] Kernel Governors, Modules, I/O Schedulers, CPU Tweaks [Reorganize Feb3] - xda-developers

    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 SGS2 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 SGS2 nach seinen Wünschen tweaken will, müssen einige Regeln beachtet werden:

    1. man erstellt eine Datei ohne irgend eine Endung und fügt in diese seine Parameter etc. ein
    2. 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
    3. 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
    4. 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. (Dank geht an Thoddü)

    Jetzt werde ich erst mal einige konfigurierbare Parameter von Governor vorstellen, welche nach eigenem Gutdünken 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:

    1. 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.
    2. 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.



    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:
    [COLOR=Black]#!/system/bin/sh[/COLOR]
    
    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:
    [COLOR=Black]#!/system/bin/sh[/COLOR]
    
    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




    Lulzactive
    (2. Version und aktuellste Version)


    [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:
    [COLOR=Black]#!/system/bin/sh[/COLOR]
    
    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:
    [COLOR=Black]#!/system/bin/sh[/COLOR]
    
    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:
    [COLOR=Black]#!/system/bin/sh[/COLOR]
    
    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




    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 idealen 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:
    [COLOR=Black]#!/system/bin/sh[/COLOR]
    
    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:
    [COLOR=Black]#!/system/bin/sh[/COLOR]
    
    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:
    [COLOR=Black]#!/system/bin/sh[/COLOR]
    
    sleep 25
    [COLOR=Black]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[/COLOR]
    echo "1" > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load




    2. mehr auf Performance/Leistung eingestellt

    Code:
    [COLOR=Black]#!/system/bin/sh[/COLOR]
    
    sleep 25
    [COLOR=Black]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[/COLOR]
    echo "0" > /sys/devices/system/cpu/cpu0/cpufreq/ondemand/ignore_nice_load




    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:
    [COLOR=Black]#!/system/bin/sh[/COLOR]
    
    sleep 25
    [COLOR=Black]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[/COLOR]




    2. mehr auf Performance/Leistung eingestellt

    Code:
       [COLOR=Black]#!/system/bin/sh[/COLOR]
    
    sleep 25
    [COLOR=Black]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[/COLOR]





    Anleitung für init.d-Scripte:

    Der Android-Bootup-Prozess beinhaltet 3 Teile.

    1. Zuerst wird der Bootloader ausgeführt.
    2. Dann bootet der Kernel und er lädt diverse Treiber, bereitet einige Hardware-Komponenten vor.
    3. 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++
    • Am Anfang 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.


    Ich habe neulich ein sehr interessantes App/Tool gefunden, mit dem man diverse Dinge modifizieren kann, ähnlich wie Voltage Control und ExTweaks, wie CPU-Taktfrequenz, Governor, Scheduler, Governor-Parameter, BLN, Spannungswerte der verschiedenen Taktfrequenzen etc. Schaut es euch selbst an...

    https://play.google.com/store/apps/details?id=mobi.cyann.nstools&hl=de

    Denkt daran immer sicherheitshalber ein Nandroid-Backup zu machen, wenn ihr euch nicht sicher seid. Ich übernehme keinerlei Haftung, da jeder selbst wissen muss, was er macht...

    euer (mad) mecss ;)
     
    Zuletzt bearbeitet: 29.05.2012
    diggens, RazorGTX, Pr0TuRk38 und 67 andere haben sich bedankt.
  2. mecss, 12.03.2012 #2
    mecss

    mecss Threadstarter Ehrenmitglied

    Beiträge:
    16,308
    Erhaltene Danke:
    11,089
    Registriert seit:
    14.03.2010
    Phone:
    Samsung Galaxy Note 3
    Jetzt werde ich einige Scripte vorstellen, die ihr auch nach eigenem Gutdünken ändern könnt, deshalb sollen jene als Vorgaben dienen:

    Ein akkusparendes Script:


    S1siyah

    Code:
    [FONT=Verdana]
    #!/system/bin/sh
    
    #hotplug parameters[/FONT] [FONT=Verdana]
    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
    [/FONT]


    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:
    [FONT=Verdana]#deepsleep levels 
    echo 4 >  /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_cpulevel[/FONT][FONT=Verdana]
    echo 0 >  /sys/devices/system/cpu/cpu0/cpufreq/deepsleep_buslevel[/FONT]

    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
     
    Zuletzt bearbeitet: 12.03.2012
    nexus161, fsi09, denyo81 und 22 andere haben sich bedankt.
  3. mecss, 12.03.2012 #3
    mecss

    mecss Threadstarter Ehrenmitglied

    Beiträge:
    16,308
    Erhaltene Danke:
    11,089
    Registriert seit:
    14.03.2010
    Phone:
    Samsung Galaxy Note 3
    Hot-Plug:

    Unser SGS2 hat eine Dual-Core-CPU, also Zwei-Kern-Prozessor. Das Standard-Verhalten ist der Dynamic-Hot-Plug-Modus, d.h. je nach Belastung wird der zweite Kern eingeschaltet. Kann also die Last von einem Kern getragen werden, wird der zweite Kern ausgeschaltet. Dieses Verhalten kann durch die Verwendung u.a. durch das App vom Siyah-Kernel, ExTweaks, gesteuert werden.


    Hotpluge-Modus


    • CPU Hotplug (default) - beschreibt das obige Verhalten
    • Second core always-off - der zweite Kern ist immer ausgeschaltet
    • Second core always-on - der zweite Kern ist immer gemeinsam mit dem ersten Kern aktiv


    loadl:

    • Wenn die Last unter 25% fällt, wird der zweite Kern ausgeschaltet.

    loadh:

    • Wenn die Last größer als 70% ist, wird der zweite Kern aktiviert


    loadh_scroff:

    • das Gleiche wie loadh, nur bei ausgeschaltetem Display


    loadl_scroff:

    • das Gleiche wie loadh, nur bei ausgeschaltetem Display

    rate:

    • ist das Abtast- bzw. Abfrageintervall, welches checkt, ob der zweite Kern aktiviert werden soll, falls vorhandene Last größer gleich loadh ist.

    rate_cpuon:

    • ist das Abtast- bzw. Abfrageintervall, welches checkt, ob der zweite Kern deaktiviert werden, sofern er schon aktiv ist, wenn die vorhandene Last kleiner loadl ist.

    rate_scroff:

    • ist das Abtast- bzw. Abfrageintervall beim ausgeschaltetem Display, welches checkt, ob der zweite Kern aktiviert werden soll, wenn die vorhandene Last größer gleich loadh_scroff ist

    freq_cpu1on:

    • wenn z.B. 600 MHz eingestellt wurde, dann bedeutet das, dass wenn die CPU-Frequenz kleiner gleich 600 MHz ist, dann wird der zweite Kern abgeschaltet

    AFTR + LPA (best battery):

    • lasst die Einstellung dabei, damit habt ihr die beste Akkuersparnis

    sched_mc:

    • 0 bedeutet Samsungs-Standard-Werte, d.h. keine Balance zwischen Performance und Akkuersparnis, somit laufen stets beide CPU-Kerne gleichzeitig.
    • 1 bedeutet, dass der erste CPU-Kern zuerst belastet wird. Dient auch zur Akkuersparnis.
    • 2 bedeutet, dass die CPU-Kerne teils im Schlaf-Modus gehen um bei Anfragen schnell reagieren zu können, was auch bedeutet, dass diese Einstellung mehr Performance bedeutet.
     
    Zuletzt bearbeitet: 03.04.2012
    Elo69, atonal, nexus161 und 34 andere haben sich bedankt.
  4. Obihörnchen, 12.03.2012 #4
    Obihörnchen

    Obihörnchen Android-Lexikon

    Beiträge:
    1,225
    Erhaltene Danke:
    755
    Registriert seit:
    27.02.2010
    Phone:
    Nexus 4
    Tablet:
    Nexus 7 (2013)
    Da ich hier im Forum so viele falsche Informationen über ZRAM sehe habe ich beschlossen mal etwas Klarheit in die ganze Materie zu bringen :thumbup:
    Oft wird über einen Performance Vorteil gesprochen, da ZRAM schneller als Swap ist. Das ganze mag für normale PCs stimmen aber wir sind hier mit Android unterwegs und da sieht das ganze etwas anders aus!

    Erst einmal eine kurze Feststellung für alle, die noch nicht so lange in der Android Szene unterwegs sind:
    ZRAM = ramzswap = Compcache

    Um ZRAM genauer zu erklären müssen erstmal andere Begriffe genauer geklärt werden:
    Swap kann man mit der Auslagerungsdatei unter Windows vergleichen werden. Wird der Arbeitsspeicher (RAM) zu voll kann der PC die Daten, die gerade nicht aktiv gebraucht werden (z.B. Hintergrundanwendungen) auslagern um so wieder RAM frei zu räumen. Dazu werden diese Daten auf eine Festplatte geschrieben. Bei Bedarf können diese Daten dann einfach wieder von dort aus gelesen werden. Selbst die schnellste SSD ist aber langsamer als der Arbeitsspeicher. Unter Android gibt es Swap nicht!

    Bei ZRAM werden nicht benötigte Speicherressourcen komprimiert und dann in einen fest reservierten Bereich im RAM verschoben (ZRAM). Also eine Art Swap Partition im Arbeitsspeicher.
    Dadurch ist mehr Ram frei, da die Daten dann nur noch ca. 1/4 des ehemaligen Speicherbedarfs haben. Allerdings muss die CPU dadurch mehr arbeiten, da sie die Daten komprimieren muss (oder auch wieder entpacken wenn sie wieder gebraucht werden). Der Vorteil hierbei liegt ganz klar in der Geschwindigkeit. Da die Swap Partition sich im RAM befindet ist diese viel schneller als eine Swap Partition auf einer Festplatte.

    An und für sich eine ganz tolle Sache. Aber Android besitzt keine Swap Partition und daher bringt ZRAM unter Android keinen Performance Gewinn wie es bei einem normalen PC der Fall wäre.

    Beim normalen PC würde das folgendermaßen aussehen:
    Swap = Auslagerungsdatei (auf Festplatte) --> Langsam
    ZRAM (Swap im RAM) --> Schneller als Swap
    RAM --> Schnell

    Bei Android gibt es keine Swap Partition und daher bringt ZRAM auch keinen Performance Boost.
    Das einzige was ZRAM bringt ist "mehr" RAM. Durch das komprimieren "vergrößert" sich sozusagen der verfügbare Arbeitsspeicher. Das ist auf Geräten mit sehr wenig RAM (<256MB) auch ziemlich nützlich. Das S2 hat aber 1GB und die reichen mehr als aus. Da muss nicht künstlich auf 1,5GB hochgepusht werden.

    Denn aktiviert man ZRAM hat das auch 2 Nachteile. Das komprimieren und dekomprimieren verbraucht CPU Time, welche wiederum höheren Stromverbrauch zur Folge hat.

    Grob kann man also sagen:
    Ohne ZRAM: +CPU Performance | +Battery | -RAM
    Mit ZRAM: -CPU Performance | -Battery | +RAM

    Für Geräte mit zu wenig RAM also durchaus sinnvoll. Aber wer ballert beim S2 schon sein kompletten RAM voll und braucht dann immer noch mehr?

    Überprüfen ob Swap läuft kann man im Terminal mit
    free oder cat /proc/meminfo

    Weiterführende Infos:
    Swap and Compcache - CyanogenMod Wiki
    http://obihoernchen.net/
     
    Zuletzt bearbeitet: 09.08.2012
    Elo69, wartemal, atonal und 6 andere haben sich bedankt.
  5. Bandit, 12.03.2012 #5
    Bandit

    Bandit Android-Guru

    Beiträge:
    3,552
    Erhaltene Danke:
    702
    Registriert seit:
    05.02.2010
    Super Arbeit *fättesLob* :thumbsup:
     
    Brillfix und mecss haben sich bedankt.
  6. HOTROADSTER, 12.03.2012 #6
    HOTROADSTER

    HOTROADSTER Fortgeschrittenes Mitglied

    Beiträge:
    331
    Erhaltene Danke:
    37
    Registriert seit:
    12.06.2011
    Super Anleitung und ich lese hier beste deutsch :) ich freue mich auf dich

    Gesendet von meinem GT-I9100 mit der Android-Hilfe.de App
     
    mecss bedankt sich.
  7. stefan1381, 12.03.2012 #7
    stefan1381

    stefan1381 Android-Hilfe.de Mitglied

    Beiträge:
    117
    Erhaltene Danke:
    54
    Registriert seit:
    14.08.2011
    @mecss
    Top Arbeit!!!!!!!!!!
    Danke Für die Mühe!!
    Mach weiter so
     
    mecss bedankt sich.
  8. Kjetal, 13.03.2012 #8
    Kjetal

    Kjetal Mitglied

    Beiträge:
    10,672
    Erhaltene Danke:
    9,510
    Registriert seit:
    27.04.2010
    Ich pinne den Thread oben an. Meiner ist dann überflüssig, gute Arbeit.

    Gesendet von meinem GT-I9100
     
  9. mecss, 13.03.2012 #9
    mecss

    mecss Threadstarter Ehrenmitglied

    Beiträge:
    16,308
    Erhaltene Danke:
    11,089
    Registriert seit:
    14.03.2010
    Phone:
    Samsung Galaxy Note 3
    Danke Kjetal, sorry, dass ich dir zuvor gekommen bin... ;)

    Der Rest der übrigen ExTweaks-Einstellungen wird heute noch fertig gestellt...
     
  10. Kjetal, 13.03.2012 #10
    Kjetal

    Kjetal Mitglied

    Beiträge:
    10,672
    Erhaltene Danke:
    9,510
    Registriert seit:
    27.04.2010
    Kein Problem mecss, ist ja kein Konkurrenz Kampf hier.:)

    Gesendet von meinem GT-I9100
     
    fsi09, krischii, ->TopAZ<- und eine weitere Person haben sich bedankt.
  11. Carew, 13.03.2012 #11
    Carew

    Carew Fortgeschrittenes Mitglied

    Beiträge:
    384
    Erhaltene Danke:
    151
    Registriert seit:
    16.06.2011
    Danke für den super Guide mecss, gute Arbeit. Werd ich mir auf jeden Fall genauer anschauen.

    Weiter so! ;)

    :thumbsup:
     
    mecss bedankt sich.
  12. mareis1973, 15.03.2012 #12
    mareis1973

    mareis1973 Android-Guru

    Beiträge:
    2,694
    Erhaltene Danke:
    791
    Registriert seit:
    04.10.2011
    Auch von mir besten dank. Sehr informativ. Hoffe dass ich jetzt mal besser :thumbup:durchblicke

    Gesendet von meinem GT-I9100 mit Tapatalk
     
    mecss bedankt sich.
  13. Neo-Droid, 16.03.2012 #13
    Neo-Droid

    Neo-Droid Android-Lexikon

    Beiträge:
    1,036
    Erhaltene Danke:
    399
    Registriert seit:
    17.07.2011
    Waaaahhhnnsinn...Top Arbeit mecss :thumbup: Ein fettes Danke :)
     
    mecss bedankt sich.
  14. MadMurdoc, 18.03.2012 #14
    MadMurdoc

    MadMurdoc Senior-Moderator Team-Mitglied

    Beiträge:
    16,288
    Erhaltene Danke:
    5,662
    Registriert seit:
    30.07.2011
    Phone:
    Samsung Galaxy Note 4
    Tablet:
    Sony Xperia Tablet Z2
    Wearable:
    Samsung Gear S2
    So und jetzt möchte ich noch eine Anleitung haben in der man die Kernel kompilation anspricht :D

    Nein Spaß, super Hilfestellung muss ich schon sagen :)
     
    mecss bedankt sich.
  15. Gene S, 22.03.2012 #15
    Gene S

    Gene S Android-Guru

    Beiträge:
    2,873
    Erhaltene Danke:
    788
    Registriert seit:
    13.04.2010
    @mecss
    Klasse arbeit,gut und Verständlich erklärt.
    Da hat man wieder einiges zum testen
     
    mecss bedankt sich.
  16. Obihörnchen, 03.04.2012 #16
    Obihörnchen

    Obihörnchen Android-Lexikon

    Beiträge:
    1,225
    Erhaltene Danke:
    755
    Registriert seit:
    27.02.2010
    Phone:
    Nexus 4
    Tablet:
    Nexus 7 (2013)
  17. mecss, 03.04.2012 #17
    mecss

    mecss Threadstarter Ehrenmitglied

    Beiträge:
    16,308
    Erhaltene Danke:
    11,089
    Registriert seit:
    14.03.2010
    Phone:
    Samsung Galaxy Note 3
    @Obihörnchen,

    schau mal in deinen Link, den du mir angeboten hast. Dort steht bzgl. Value 0 was Interessantes...

    In puncto Value 2 gebe ich dir Recht. Irgendwann haben wohl meine Augen schlapp gemacht und ich muss in der Zeile verrutscht sein...Danke für das Aufmerksam-Machen... ;)
     
  18. Obihörnchen, 04.04.2012 #18
    Obihörnchen

    Obihörnchen Android-Lexikon

    Beiträge:
    1,225
    Erhaltene Danke:
    755
    Registriert seit:
    27.02.2010
    Phone:
    Nexus 4
    Tablet:
    Nexus 7 (2013)
    ^Ja ich sehe gerade hab mich bei dir bei 1. etwas verlesen^^ Hab das falsch veranden :D
    sry
     
  19. trayzor, 12.04.2012 #19
    trayzor

    trayzor Android-Lexikon

    Beiträge:
    1,398
    Erhaltene Danke:
    327
    Registriert seit:
    03.04.2012
    hmm ich hoffe doch,dass ich hier richtig bin (oder doch hier : http://www.android-hilfe.de/kernel-fuer-samsung-galaxy-s2/180437-faq-governors-schedulers.html ?). seis drum, enthaupte man mich falls doch falsch hier :D
    smartassv2 scheint bei mir etwas instabil zu sein, habe random freezes während es im deepsleep is. benutze jetzt den siyah-kernel seit einigen versionen, aktuelle beta drauf, die wird dann noch mit smartv2 getestet.
    bin eben auf lulzactive umgestiegen, habe es manuell so eingestellt, wie es im akkuschonenden skript für lulz empfohlen wird (mit der lulza. app,hätte auch setcpu benutzen können,aber warum nicht :D). derzeit mit wlan verbunden und höre musik. kostet mich ca 7-8% akku/h :/ beim smartv2 waren es "nur" 3-4%.
    habe es jetzt mal auf drastische werte geändert,auf akku schonen ausgerichtet:
    -inc_cpu_load 90%
    -pump_up 1
    -pump_down 7
    -screen_off 6@200mhz
    -up_sample 50k millis
    -down_sample 40k millis

    vorschläge für eine bessere ausrichtung auf akku schonen vorhanden :D? habe die werte mit cpu spy mal beobachtet. im gegensatz zu smartv2 taktet lulz ab und zu auf 200-500 hoch. ab und zu im sinne von öfters als smart,was daran liegen dürfte, dass der letzgenannte auf minimal läuft,wenn der display aus ist.
     
  20. m505, 14.04.2012 #20
    m505

    m505 Android-Lexikon

    Beiträge:
    1,620
    Erhaltene Danke:
    680
    Registriert seit:
    11.10.2011
    noch Akku-sparender:

    -inc_cpu_load 70-80%
    -up_sample 40k millis
    -down_sample 10k millis

    da werden sich dann aber Ruckler bemerkbar machen
     
    trayzor bedankt sich.

Diese Seite empfehlen

Besucher kamen mit folgenden Begriffen auf unsere Seite:

  1. android kernel einstellungen