Alles Wichtige und Informative zu einem Android Kernel

[chris264 5.155]

Mein Dank geht an

Swissdroid der sich die Mühe gemacht hat und diesen ganzen Infos zusammengetragen hat.

Dieser Thread, wird immer wieder erneuert bzw aktualisiert, wie ihr ja wisst, die Android Welt steht nie still

Dieser Thread dient als Informationsquelle, wenn ihr Gerätespezifische Fragen habt, dann stellt die bitte in eurem passenden Geräteforum.

[chris264 5.155]

I/O Scheduler

(Thanks to chillzz // dhlalit11 )

Was ist ein Scheduler?

Der IO-Scheduler verwaltet die Input / Output Zugriffe der Anwendungen auf die Speichermedien. Der IO-Scheduler dient zur Organisation der Reihenfolge von Zugriffen, je nach Scheduler wird versucht folgendes zu verbessern:

1. Höherer Datendurchsatz

2. niedrige Zugriffszeit

3. ausgewogenes Antwortverhalten der Anwendungen

Die Verschiedenen I/O Scheduler

anticipatory:

Dieser Scheduler arbeitet ähnlich wie der Deadline-Scheduler, allerdings wird eine Statistik zwischen Blöcken und Prozessen erstellt. Durch die Statistiken ist es dem Scheduler möglich zu erahnen, wann der nächste Block von welchem Prozess angefordert wird.

complete fair queuing (cfq) :

Dies ist der aktuelle Standard Scheduler, er hat einen anderen Ansatz als die anderen Scheduler. Er führt auch eine Block- und Prozessstatistik, benutzt diese allerdings um die Bandbreite „Fair“ an die Prozesse zu verteilen. Durch dieses Verhalten werden zwar keine geringen Antwortzeiten oder hohe Datendurchsätze garantiert, aber alle Anwendungen erhalten ein ausgewogenes Antwortverhalten.

deadline:

Dieser Scheduler sortiert die I/O-Request(Anfragen) anhand der Blocknummer der Daten auf der Festplatte. Damit auch Blöcke mit stark abweichenden Blocknummern bearbeitet werden, erhält jeder Request eine maximale Auslieferungszeit.

noop:

Der NOOP-Scheduler ist der einfachste Scheduler, die Daten die zuerst kommen werden als erstes geschrieben. Dieser Scheduler ist für intelligente Hardware gedacht, welche das Scheduling selbst übernimmt.

sio:

Der Sio-Scheduler basiert auf dem Deadline-Scheduler, aber er ist mehr wie eine Mischung vom Noop und Deadline-Schedulder. In anderen Worten, Sio ist eine leichtere Version vom Deadline, wobei Sio keinerlei Sortierung vornimmt. Seine Hauptsächliche Ziele sind Direktspeicher-Geräte (wie SSD-Harddisk), welche keine Anfragen-Sortierung benötigen. So das jeder Sektor in einer konstanten Zeit bearbeitet werden kann, unabhängig von seinem physischen Speicherort.

Budget Fair Queueing (bfq):

Der bfq-scheduler (basierend auf cfq),

arbeitet mit "Budgets". Einem Prozess wird solange gewährt, bis sein Budget (Anzahle der Sektoren z.b. einer Flashdisk) abläuft.bfq weist hohe Budgets für nicht-Lese-Aufgaben zu. Das zugeordnete Budget eines Prozesses variiert über die Zeit in Abhängikeit zum Verhalten einen Prozesses.

Welchen I/O-Scheduler soll ich verwenden?

Diese Frage lässt sich nur schwer beantworten und hängt von vielen Faktoren ab, z.B. welche Prozesse aktiv sind und wie diese auf die Festplatte zugreifen.

Des Weiteren kann es Unterschiede geben, ob normale Festplatten oder SSD's verwendet werden. Hier kann z.B. Anwendung A mit einer Magentfestplatte und I/O-Scheduler CFQ perfekt zusammenarbeiten, aber wenn eine SSD verwendet wird, kann das Ergebnis ganz anders aussehen.

Anticipatory ist normalerweise effizienter wenn z.B. Batch-Jobs laufen, die selbst jede Menge sequenzielle Dateien gleichzeitig bearbeiten. Zum ansehen von Videos ist er vermutlich der geeignetste. Deadline hat seine stärken bei Randon-Zugriffen, die z.B. sehr oft bei Datenbanken vorkommen. Deadline sorgt dafür, das die Seeks minimiert werden, welche für die Random-Zugriffe wichtig sind. Anticipatory ist zwar Deadline sehr ähnlich aber durch die kleinen Wartepausen die eingelegt werden um Sequenzialität zu erkennen, welche bei Datenbankzugriffen nicht vorkommen vergeudet Anticipatory Zeit aber Deadline wiederum nicht. Sollten auf dem besagten Datenbankserver weitere Dienste laufen, die z.B Batch-Jobs verarbeiten und auch normal gearbeitet wird. Kann wieder der CFQ der empfehlenswertere sein. Denn CFQ kann bei mehreren nebeneinander Laufenden Augaben effizienter bedienen. Das bedeutet, dass alle zugreifenden Prozesse gleichermassen bedient werden.

CPUIdle Modus

Was ist der CPU Idle-Modus ?

Der so genannte „Deep Idle“-Modus ist einer der Zustände, in der sich die CPU des Geräts befinden kann, wenn der Bildschirm abgeschaltet ist. Anders als der „Sleep“-Modus schaltet dieser nicht nur die Taktfrequenz der CPU herunter, sondern minimiert auch den Stromverbrauch der restlichen im Gerät verbauten Hardware.

Dazu gibt es folgende Einstellungen:

Die CPUidle-Modi(Ruhezustands Modi)

Idle

Bei diesem Idle- Modus wird die CPU nicht mehr getaktet, wobei aber keine Hardware abgeschaltet wird.

LPA

Der tiefe Leerlauf (LPA), ein Zustand nach Idle, wird die CPU wieder nicht mehr getaktet, wobei aber einige Teile der Hardware heruntergefahren werden. Der Tiefschlaf(bzw. der LPA) bringt ist Akkuschonender als der normale Idle-Modus. Dieser Modus wird nicht verwendet zu Beginn nach dem Ausschalten des Bildschirm, und vor dem Aufwachen nach dem deep-sleep.

AFTR (ARM OFF TOP RUNNING)

Der AFTR ist ein CPUidle Modus des EXYNOS4210 Prozesseros des S2. Der L2 Chache (also der der Chache mit der 2. schnellsten Zugriffszeit) hat seine Daten dort gelagert. Deshalb wird dieser bei dem Modus abgeschalten und beim wiedereinschalten des Bildschirm wider zugeschalten.

AFTR + LPA

Dieser Modus ist der beste Akkuschoner, da er beide Modis (AFTR und LPA ) verwendet und somit am meisten Teile des System herunterfährt.

Die Sched_MC Levels

(Big Thanks to mecss )

Es gibt diese Folgende Levels:

0 (bzw.Level 0 /disable)

Bedeutet Samsungs-Standard-Werte, d.h. keine Balance zwischen Performance und Akkuersparnis, somit laufen stets beide CPU-Kerne gleichzeitig.

1 (bzw Level 1)

Bedeutet, dass der erste CPU-Kern zuerst belastet wird. Dient auch zur Akkuersparnis.

2 (bzw. Level 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.

[chris264 5.155]

LCD-Density

Die LCD-Density beschreibt ganz einfach die Auflösung, je kleiner der Wert, desto kleiner wird’s dargestellt.

Helligkeit / Gammakorrektur

Mit der Helligkeit werden ALLE Pixel um einen bestimmten (absoluten) Betrag linear aufgehellt oder abgedunkelt.

0 stellt den Standartwert dar.

+ Werte lassen das Bild Heller erscheinen, - Werte lassen es dunkler erscheinen

Touchscreen Empfindlichkeit

Beschreibt den Schwellenwert des Drucks auf den Touchscreen.

Der Wert wird in einer Skala von 0-100 angegeben, wobei nicht immer 0-100

ausgewählt werden kann. Als Beispiel nenne ich hier mal den Fluxi-Kernel welcher ein Schwellenwert von 25-75 zulässt.

Hier sind manchmal noch einige Untereinstellungen zufinden, wie :

Schwellenwerte für Berührung

Schwellenwerte für Rauschen

Bewegungsfilter

Welche wiederum noch seperat Eingestellt werden können, für Handy am Ladegerät oder nicht.

Ich persönlich bemerke keinen Unterschied bei verschiedenen Einstellungen deshalb kann ich dazu auch nichts sagen. Aber vielleicht bin ich auch zu Unsensibel und bemerke es nicht... Deshalb bei anderen Meinung bitte PN oder Bemerkung unten, dann kann ich es anpassen.

BLN (B-ack L-ight N-otification)

Was ist BLN?

BLN Beschreibt das Verhalten der Optionen- und Zürucktaste (LED-Tasten) neben dem Homebutton bei Verpassten Anrufen oder ungelesen SMS/MMS.

Was bringt das? Nun man weis ohne auf den Bildschirm zuschauen ob man neue Nachrichten erhalten hat.

Mögliche BLN-Modis sind:

Aus:

Kein BLN Benachrichtigung

Dauerhaft:

BLN leutet konstant

Breathing-Effekt

BLN geht langsam An und Ab, als wurde es atmen (vom engl. Breahting)

Blinking-Effekt:

BLN blink (schnell An / Ab )

Zu den Modis gibt es dann folgende Einstellungen:

Benachrichtigungsdauer:

Einstellung wie lange BLN nach Einschalten (z.b. nach SMS empfang) aktiv bleibt

Neue Benachrichtungen

Einstellung ob BLN verlängert (bei mehr als 1 ungelesen Nachricht) werden soll oder nicht.

Verhalten beim Laden

Selbsterklärend

Niedriger Ladezustand:

Ab welchem Akkustand BLN ausgeschalten werden soll.

LED

Unter LED sind meist , die wie der Name schon sagt LED-Software Tasten gemeint. (Gleich wie bei der BLN )

Nur geht es bei diesen Einstellungen nicht um die Benachrichtigungs-Beleuchtung sondern um das Verhalten bei Eingeschaltetem Bildschirm.

Beleuchtungsintervall:

Beschreibt, wie lange die Tasten leuchten nach einer Berührung.

Es sind auch verschiedene Helligkeitsstufen einstellbar.

Fadeout-Effekt (Verzögertes Auschalten):

Ein: Die Led-Tasten werden nach Ablauf des Beleuchtungsintervall abgedunkelt bis sie ganz erlöschen.

Aus: Nach Ablauf der Beleuchtungsintervallzeit erlischen die Tasten sofort.

[chris264 5.155]

Maximale CPU-Frequenz

(je nach dem auch "max freq", "max" , "max_freq_cpu" usw.)

Beschreibt die Maximale Taktung des Prozessor, bzw. der Prozessoren.

Je höher der Wert desto Leistungsfähiger das System,jedoch hoher Akkuverschleiss

Je tiefer der Wert desto weniger Leistungsfähiger wird das System, erhöht jedoch die Akkulaufzeit.

Maximum Suspend

Beschreibt die maximale Prozessortaktung bei abgeschaltenem Bildschirm

Minimum CPU-Frequenz

(je nach dem auch "min freq", "min" , "min_freq_cpu" usw.)

Beschreibt die minimale Taktung des Prozessors, bzw der Prozessoren.

Eine kleiner Wert mindert den Akkuverbrauch, senkt jedoch auch die Reaktionsfähigkeit des Systems

Ein hoher Wert steigert den Akkuverbrauch, führt aber auch zu einem besseren Ansprechverhalten.

Minimum Suspend

Beschreibt die minimale Prozessortaktung bei ausgeschaltenem Bildschirm

Und nun zu einem wichtigen Thema:

Der Covernors

Was ist ein Governor?

Ein Governor ist ein Treiber zur Regulierung der CPUFreq - CPU-Frequenz. Wie der Name uns schon sagt, ist der Governor der Entscheider, wann bei Vollauslastung die maxFreq - maximale Frequenz - erreicht wird oder wie schnell die minFreq - minimale Frequenz bzw. mittlere Frequenz erreicht wird. Er entscheidet, wann, wie und wie lange die CPU reagiert und trotzdem akkusparend bleibt und trotzdem weiterhin weich arbeitet.

Es gibt sehr sehr viele Arten von Governors. Einige sind für Einkern-Prozessoren und einige nur für Zweikern-Prozessoren ausgelegt. In Stock-Kernels gibt es 5 Governors und in Quasar-Kernels gibt es noch viel mehr.

Die verschiedenen Governors und dessen Parameter

Very Big Thanks to

Mecss

Die Governors:

Die Parameter:

Info:

Die Parameter treffen nicht nur auf den entsprechenden Governor zu, unter dem sie stehen. Da aber einige "nur" Weiterentwicklungen des jeweiligen Covernor sind, sind die Parameter beim "Originalen" Covernor untergebracht.

Bei den Weiterentwicklungen steht beschrieben von welchem er abstammt.

1) Ondemand *&

2) Powersave *@

3) Userspace *

4) Conservative *

5) Performance *

6) Interactive +

7) Interactivex +

8) Smartass (Removed as of 2.2i) +

9) Smoothass +

10) Brazilianwax +

11) SavagedZen +

12) Minmax +

13) Scary +

14) Lazy

15) Lulzactive

16) Lagfree

17) SmartassV2

18) Ondemandx

19) Intellidemand

20) Lionheart

21) Sleepy #

22) Hyper #

Legende:

& = Default (standardmäßig eingestellt)

@ = standardmäßig abgestellt

* = im Stockkernel vorhanden

+ = in Quasarkerneln vorhanden

# = im RedPill-Kernel enthalten

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.

1) Ondemand:

Der Ondemand-Governor ist die Standardauswahl, die aufgrund seiner ausgewogenen Einstellungen, die einen guten Kompromiss zwischen Akkulaufleistung und Performance bietet. Allerdings hat er keine Profile beim Ausschalten des Displays (Screen-Off-Profile) oder für das Aufwecken des Handys und reagiert auf Eingaben gleich mit hohen Sprüngen zur Leistung.

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.

2) Powersave:

Bei diesem Governor entspricht die maxFreq der minFreq. Für den alltäglichen Gebrauch ist dieser Governor nicht zu empfehlen.

3) Userspace:

Hier können individuelle Einstellungen statt automatischen Vorgaben eingestellt werden. Ob es funktioniert und wie, weiß anscheinend niemand. Ist schon komisch.

4) Conservative:

Er ist eher ein langsamer Vertreter seiner Art und ist eher ein langsamer Ondemand, welcher langsam hochskaliert um den Akku zu schonen. Zur Verdeutlichung ein Beispiel an Hand des Ondemand. Der Ondemand erhöht bei einer Interaktivität des Smartphones die Frequenz bis auf maxFreq. Der Conservative hingegen tut das um die Hälfte langsamer und spart dabei Akkulaufleistung, aber auf Kosten der Performance.

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.

5) Performance:

Hier entspricht die minFreq der maxFreq, also genau umgekehrt wie beim Powersave, was bedeutet, dass beim Performance-Governor immer die maximale Frequenz eingestellt ist und den Akku in die Knie zwingt. Ist somit nur für Benchmarks zu gebrauchen.

6) Interactive:

Dieser Governor ist eher ein schnellerer Ondemand. Etwas flotter und akkufreundlicher. Anstelle von regelmäßigen Anfragen in jedem Intervall wie der Ondemand, bestimmt der Interactive wie er hochskaliert, wenn die CPU aus dem Standby aufgeweckt wird. Er ist wegen seiner Stabilitätsoptimierung ein intelligenter Ondemand. Dies ist der beliebteste Governor der letzten Jahre.

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.

7) Interactivex:

Dies ist ein Interactive nur mit Aufweck-Profilen und ist auch akkufreundlicher als der Interactive. Grundsätzlich hat er die gleiche Leistung wie der Interactive, nur mit besserer Akkulaufleistung.

8) Smartass:

Dies ist der Vorgänger des SmartassV2. Er begrenzt die maxFreq, wenn der Bildschirm aus ist. Er gilt nicht als sehr akkufreundlich wie der SmartassV2. Das liegt daran, dass die minFreq bei eingeschaltetem Display höher ist als die Frequenz-Skalierung während des Standby.

9) Smoothass:

Dieser Governor ist auch ein aufgebohrter Smartass, welcher nur etwas flotter skaliert, was zur Folge hat, dass alles noch etwas weicher und schneller reagiert, aber auch auf Kosten des Akkuverbrauchs geht.

10) Brazilianwax:

Er ist ähnlich wie der SmartassV2, nur aggressiveres Hochskalieren, was mehr Leistung und auch Akkuverbrauch mit sich bringt.

11) SavagedZen:

Ein weiterer SmartassV2-Governor. Er erzielt eine gute Balance zwischen Leistung und Akkuverbrauch und wird eigentlich unterschätzt.

12) Minmax:

Dieser Governor sei eine angenehme Überraschung gewesen. Obwohl er an den Conservative anlehnt, soll er wohl die beste Performance von allen haben. Er habe wohl eine etwas schlechtere Akkulaufleistung wie der SmartassV2, aber soll die beste Spritzigkeit haben, weshalb er auch der Standardgovernor im Nova-Kernel sei.

13) Scary:

Dies sei einer der seltsamsten Governors. Er basiert auf den Conservative, welcher für seine langsame Skalierung bekannt sei, aber habe wiederum Elemente des Smartass, der wiederum als einer der schnellsten skalierfähigen Governore bekannt ist. Einige Leute berichten, dass sie von ihm fasziniert seien. Hörensagen eben.

14) Lazy:

Dieser Governor von ezekeel ist im Grunde einer, der auf den Ondemand basiert, nur mit dem zusätzlichen Parameter min_time_state, was die minimale Zeit der CPU auf einer Frequenz vor der Skalierung nach oben und unten beibehält. Hierbei werden Instabilitäten durch zu schnelle Frequenzwechsel, wie beim Ondemand, vermieden. Der Lazy-Governor stellt zwar öfter Anfragen als der Ondemand, aber wechselt die Frequenz erst nach Abschluss der min_time_state, was heißt so viel wie Stufe nach Stufe (erst 200 MHz, dann 300 MHz, dann 400 MHz, etc.). Dazu kommt noch, dass der Lazy-Governor von Haus aus Parameter beim Abschalten des Displays (Screenoff_maxfreq) mitbringt, d.h. man kann einstellen was die höchste Frequenz in MHz beim Abschalten des Displays sein darf.

15) Lulzactive:

Dieser Governor ist noch recht neu und stammt von tegrak. Er basiert sowohl auf den Interactive- als auch auf den Smartass-Governor.

Die etwas ältere Version: Wenn bei ihr die Arbeitsbelastung größer als oder gleich 60% war, skalierte dieser Governor die CPU in die nächst höhere Stufe. Wenn die Arbeitsbelastung weniger als 60% war, dann skalierte dieser Governor die CPU zur nächst niedrigeren Stufe. Und wenn der Bildschirm ausgeschaltet war, dann wurde die CPU auf die niedrigste skalierbare Frequenz gesperrt.

Die neue Version: Diese Version beinhaltet noch drei weitere konfigurierbare Parameter. inc_cpu_load, pump_up_step und pump_down_step. Diese Parameter verhelfen dem Anwender zu einer größere Kontrolle. Somit kann man den Schwellenwert, bei dem der Governor beschließt auf- oder abzuskalieren, festlegen. Man kann auch eine bestimmte Anzahl von Frequenzstufen festlegen, die beim Abfragen übersprungen werden sollen.

LulzactiveParameter:

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.

16) Lagfree:

Auch dieser Governor ähnelt dem Ondemand. Der Hauptunterschied liegt darin, dass er wesentlich akkufreundlicher ist. Die Frequenz wird entweder weich herunter gesetzt oder weich herauf gesetzt, anders als beim Ondemand, der bei Anfragen eher gleich auf 100% steigt, obwohl nicht gebraucht. Der Lagfree steigt also stufenweise und überspringt keine Frequenz während die CPU skaliert. Das bedeutet auch, dass dieser Governor bei akut starkem Leistungsbedarf nicht sofort auf 100% steigt und es somit zu Rucklern, wie z.B. bei der Video-Wiedergabe, kommen kann.

17) SmartassV2:

Das ist die überarbeitete Version des Smartass-Governor von erasmux. Dieser Governor verfolgt das Ziel, eine ideale Frequenz zu erreichen und versucht dieses aggressiv zu erreichen und weniger aggressiv zu verlieren. Er benutzt verschiedene ideale Frequenzen beim Anschalten und Abschalten des Displays. Wenn der Display ausgeschaltet ist, skaliert dieser Governor abwärts sehr schnell (aggressiv) und skaliert beim Anschalten des Displays auf bis zu 500 MHz schnell. Im Gegensatz zum kleinen Bruder Smartass gibt es keine Obergrenze für die Frequenz, wenn der Display ausgeschaltet ist. Bei diesem Governor geht es auch um ein Gleichgewicht zwischen Leistung und Akkulaufzeit.

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.

18) Ondemandx:

Dieser Governor ist eigentlich auch ein Ondemand, nur mit dem Unterschied, dass er von Haus aus Profile beim Abschalten und Anschalten des Displays mitbringt. Dieser Governor wurde erstellt um noch akkufreundlicher zu sein. Wenn der Bildschirm ausgeschaltet ist, wird die maximale Frequenz auf 500 MHz gesetzt. Trotz dessen, dass der Ondemand in vielen Kerneln vorhanden ist, da er als stabil gilt, ist die Unterstützung durch den Ondemandx weitreichender, da er trotz der schnellen Schaltfrequenz und dadurch eine geringe Übergangsverzögerung hat, eben auch akkufreundlicher sei. Bei diesem Governor spiele, im Gegensatz zu anderen Governorn, der I/O-Scheduler eine große Rolle.

19) Intellidemand:

Der Intellidemand aka Intelligent Ondemand von faux ist ein weiterer Governor, der auf Ondemand basiert. Anders als manche Nutzer glauben, ist dieser Gouverneur nicht der Ersatz für OC Daemon. Der ursprüngliche Intellidemand verhält sich anders je nach GPU-Nutzung. Wenn die GPU wirklich beschäftigt ist (Spiele, Karten, Benchmarking usw.) verhält sich dieser wie der Ondemand. Wenn die GPU im "Leerlauf" ist (also eher mäßig beansprucht ist), begrenzt der Intellidemand die maximale Frequenz abhängig von den verfügbaren Frequenzen in eurem Gerät bzw. eurem Kernel um Akkuleistung zu sparen. Dies wird als Browsing-Modus bezeichnet. Wir können auch einige "Spuren" vom Interaktive-Governor finden. Frequenz-Skalierungen im unteren Segment hängen von der Leerlaufzeit der CPU ab. Untere Leerlauf-Zeit (<20%) bedeutet eine Herabsetzung der Frequenz-Skalierung von der aktuellen Frequenz. Frequenz-Skalierungsherabsetzungen geschehen in 5%-Schritten von der aktuellen Frequenz.

Zusammenfassend lässt sich sagen, dass dies ein intelligenter Ondemand-Governor ist, der durch den Browsing-Modus die maximale Frequenz begrenzt, wenn die GPU im Leerlauf ist, und, sofern der Browsing-Modus vorhanden ist, sich wie der Ondemand verhält, wenn die GPU nicht ausgelastet ist. Auch der Intellidemand schaltet nicht auf die höchste Frequenz, wenn der Bildschirm ausgeschaltet ist.

20) Lionheart:

Der Lionheart-Governor ist ein optimierter Conservative-Governor und stammt auch von Knzo. Er ist auf extreme Reaktionsfähigkeit und Leistung getrimmt, leider auf Kosten der Akkuleistung.

21) Sleepy:

Der Sleepy (früher bekannt als solo) ist ein Versuch um ein Gleichgewicht zwischen Leistung und Akkulaufleistung zu schaffen. Er basiert auf den getweakten Ondemand von arighi und ist für das SGS2 optimiert. Er beinhaltet imoseyon’s Ondemandx-Tweaks mit einigen Down_sampling- und anderen Features,welche der User mittels sysfs durch das Setzen von "echo" abrufen kann. Sleepy ist dem Verhalten des Ondemandx , wenn er in Aktion ist, sehr ähnlich.

Er verfügt auch über die arighi’s fast_start und deep_sleep-Erkennung-Features. Darüber hinaus ist die maximale Frequenz im Suspend-Modus 500Mhz.

21) Hyper

Der Hyper (früher bekannt als kenobi) ist ein aggressiver Smart und Smooth, getweakt und optimiert für das SGS2, basierend auf den Ondemand, welcher von arighi getweakt wurde und mit einigen Ondemandx-Suspend-Features von imoseyon ausgestattet wurde. (Hinzugefügt wurden die Einstellungen suspend_freq mittels sysfs und Imoseyon’s Suspend Code) Hyper ist dem Verhalten des Ondemand, wenn er in Aktion ist, sehr ähnlich. Er verfügt auch über die arighi’s fast_start und deep_sleep-Erkennung-Features. Darüber hinaus ist die maximale Frequenz im Suspend-Modus 500Mhz.

CPU-Spannung

Bei jedem Kernel den ich kenne gibt es die Einstellung CPU-Spannung.

Dort lässt sich für verschiedene Frequenzen die Spannung Einstellen. Der Sinn des ganzen ist wie immer Akkusparen oder Leistung herausholen.

Aber Achtung Undervolting (Herabsetzten der Spannung) kann zu Freezes führen und im schlimmsten Falle (wenn bei "Werte nach Neustart Speicher/Laden) zu Bootloops.

Auch beim Overclocking (Hochsetzten der Spannung) ist Vosicht geboten. So können Hardwareschaden die Folge sein.

Diese Einstellungen immer mit Vorsicht geniessen und langsam an die gewünschten Werte herantasten.

HotPlug:

Diese Einstellung wird nur bei Mehr-Kern Prozessoren zufinden sein. Es regelt das Verhalten zwischen den mehreren Kernen.

Als Beispiel verwende ich einen 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.

HotPlug-Modis:

CPU Hotplug (default/standart)/ Dynamic Hotplug

beschreibt das obige Verhalten

Second core always-off/ Single Core Modus

der zweite Kern ist immer ausgeschaltet

Second core always-on/ Dual Core Modus

der zweite Kern ist immer gemeinsam mit dem ersten Kern aktiv

Die Eigenschaften betreffend Akkuverbrauch und Leistungsfähigkeit kann sich jeder selber denken

Loadl / Schwellenwert Down

Wenn die Last unter 25%(meistens Standarteinstellung) fällt, wird der zweite Kern ausgeschaltet.

Loadh / Schwellenwert Up

Wenn die Last größer als 70%(Standartwert) 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

Busfrequenzen

Was ist mit diesen Busfrequenzen (FSB = Front-Side-Bus) gemeint? Dazu das: Im Zusammenhang mit Prozessoren, Chipsätzen und Motherboards wird immer wieder vom Front-Side-Bus, kurz FSB, gesprochen. Zu Deutsch "Vorderseitenbus" ist er nichts anderes als die Schnittstelle bzw. eine Direktverbindung (ohne Protokoll und Datenflusskontrolle) zwischen Prozessor und Chipsatz (Northbridge). Die Hardware-Schnittstelle des FSB ist ein Sockel oder ein Slot, je nach Bauform des Prozessors.

Die Taktfrequenz und die Bus-Breite (in Bit) bestimmen die Geschwindigkeit, mit der die Daten zwischen Prozessor (CPU) und Chipsatz übertragen werden.

Der Front-Side-Bus entscheidet über die Bandbreite der CPU zum Chipsatz, zum Arbeitsspeicher, zur Grafikkarte und zum Rest des Systems. Die Bandbreite der CPU sollte im Idealfall gleich der Bandbreite des Hauptspeichers sein. Ansonsten sind Prozessor und Speicher schlecht aufeinander abgestimmt und die Leistung der einen oder anderen Komponente wird schlicht verschwendet.

Hierzu gibt es folgende Einstellungen (welche eigentlich Selbsterklärend sind) :

Schwellenwert Up (Hoch)

Schwellenwert Down (Tief)

Und Die Spannungstabellen (in mV ) fur die Busfrequenzen (Hoch/Normal/Tief)

GPU (Der Grafik Prozessor)

Eine Erklärung des GPU erspare ich mir an dieser Stelle, wer denoch mehr wissen will, kann auf den Titel drücken der zum Wikipedia Artikel führt.

Die Einstellungen:

Hier werden die Einstellungen in 3 Untereinstellungen Getrennt (wobei es auch hier wider nur um Performance oder Akkulebensdauer geht):

Und zwar in Low Power / Medium Performance / High Performance, welche alle die gleichen Einstellungen zulassen:

Frequenz:

Beschreibt die Taktfrequenz (in Mhz) des GPU: Zu hohe Einstellung können zu Zerstörung der Hardware führen also immer mit vorsicht geniessen.

Auch hier kann man durch das herabsetzten der Frequenz Strom sparen, doch dadurch kann es zu rucklern und Freezes kommen.

Spannung:

Beschreibt die Spannung (in mV) welche an der GPU bei unterschiedlichen Belastungen anliegt. Höhere Werte führen zu mehr Leistung aber auch zu einer höheren Wärmeentwicklung welche u. U. die Hardware zerstört.

Schwelle Up:

Beschreibt die Schwellenlast (in %) ab welcher der GPU zur nächsten Stufe springt.

Höhere Einstellungen bewirken, dass erst bei hoher Last auf die nächste Stufe gesprungen wird.

Schwelle Down:

Beschreibt die Schwellenlast (in %) ab welcher der GPU wieder auf eine tiefer Stufe zurückspringt.

Höhere Werte zwingen die GPU bei nachlassender Belastung schneller wieder auf eine tiefere Spannung und Frequenz zu springen.