Kaio
Fortgeschrittenes Mitglied
- 29
Habe ich mir schon fast gedacht aber danke für dein Statement . Naja besser als nix ne 
Sent from my GT-I9100 using Tapatalk
Sent from my GT-I9100 using Tapatalk
[FAQ] Governors & Schedulers
- 258 Antworten
- Letztes Antwortdatum
alf328
Ambitioniertes Mitglied
- 15
1. 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.
2.Welche Governors gibt es?
Ich habe bis jetzt 20 Arten von Governors gefunden, wozu ich etwas schreiben kann und ich nachfolgend aufgelistet habe.
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
Legende:
& = Default (standardmäßig eingestellt)
@ = standardmäßig abgestellt
* = im Stockkernel vorhanden
+ = in Quasarkerneln vorhanden
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.
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.
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.
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.
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.
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.
3. Was ist ein Scheduler?
In einem Multitasking-Betriebssystem muss es eine Instanz geben, die den Prozessen, die laufen wollen, Rechenzeit zuteilt und sie nach Ablauf der zugeteilten Zeitspanne (Timeslice) wieder schlafen legt. Diese Instanz bildet der sog. Scheduler, z.B. beim Öffnen und Schließen von Anwendungen. d.h. wie schnell werden sie geöffnet und wie lange sie im RAM gehalten werden.
I/O-Scheduler können viele Zwecke haben wie:
Zeit beim Suchen auf der Festplatte zu minimieren
Prioritäten setzen bei bestimmten Prozess-Anfragen
Einen bestimmten Teil der Bandbreite des Datenträgers zu jedem laufenden Prozess zu regulieren
Bestimmte Prozess-Anfragen innerhalb einer bestimmten Zeit zu garantieren
4. Welche Scheduler gibt es?
Noop *
Anticipatory *@+
CFQ *&
Deadline *@+
VR +
Simple +&
BFQ #
Sio &+
Legende:
&=Default(standardmäßigeingestellt)
@=standardmäßigabgestellt
*=imStockkernelvorhanden
+=inQuasarkernelnvorhanden
Noop:
Der Noop-Scheduler ist der einfachste von ihnen. Er ist am Besten geeignet für Speichergeräte, die nicht von mechanische Bewegungen abhängig sind, wie unsere Flash-Laufwerke in unseren SGSII's, um den Datenzugriff zu verwenden. Der Vorteil ist, dass Flash-Laufwerke keine Neuanordnung der I/O-Anfragen im Gegensatz zu normalen Festplatten benötigen. d.h. die Daten, die zuerst kommen, werden auch als erstes geschrieben. Er ist im Grunde kein richtiger Scheduler, da er das Scheduling der Hardware überlässt.
Vorteile:
- Fügt alle eingehenden I/O-Anfragen in eine Wer-zuerst-kommt- mahlt- zuerst-Warteschlange und realisiert Anfragen mit der geringsten Anzahl von CPU-Zyklen, deshalb auch akkufreundlich
- Ist bestens für Flashlaufwerke geeignet, da es zu keinerlei Such-Fehlern kommt
- Guter Datendurchsatz auf db-Systemen
Nachteile:
- die Verringerung der Anzahl der CPU-Zyklen entspricht einem gleichzeitig einhergehendem Leistungsabfall
Anticipatory:
Zwei wichtige Dinge sind hier bezeichnend für diesen Scheduler:
- Das Suchen auf dem Flashlaufwerk geht sehr langsam von Statten
- Schreibvorgänge können zwar jeder Zeit abgearbeitet werden, jedoch werden Lesevorgänge vorgezogen, d.h. dieser Scheduler gibt den Lesevorgängen eine höhere Priorität als den Schreibvorgängen.
Vorteile:
- Anfragen von Lese-Zugriffen werden nie sekundär behandelt, d.h. hat ähnlich gute Leseleistung auf Flashlaufwerken wie der Noop
Nachteile:
- Anfragen von Prozessvorgängen sind nicht immer verfügbar
- Verringerte Schreib-Performance auf High-Performance- Festplatten
CFQ:
Der CFQ Completely Fair Queuing , ähnlich wie beim Deadline, verwaltet eine skalierbar durchgehende Prozess-I/O-Warteschlange, d.h. er versucht die verfügbare I/O-Bandbreite fair und gleichmäßig auf alle I/O-Anfragen zu verteilen. Dabei erstellt er eine Statistik zwischen den Blöcken und Prozessen. Durch diese Statistik kann er "erahnen", wann der nächste Block von welchem Prozess angefordert wird, d.h. jede Prozess-Warteschlange enthält synchrone Anfragen von Prozessen, die wiederum abhängig von der Priorität des Ursprungsprozesses ist. Es gibt eine V2 vom CFQ und hat einige Fixes, wie z.B. den I/O-Anfrage-Hunger zu stillen und einige kleine Rückwärtssuchen wurden eingebaut um die Reaktionsfähigkeit zu verbessern.
Vorteile:
- hat das Ziel eine ausgewogene I/O-Performance zu liefern
- am einfachsten einzustellen
- hervorragend auf Multiprozessoren-Systemen
- beste Datenbank-Performance nach dem Deadline
Nachteile:
- Einige User berichteten, dass das Medien-Scanning hierbei sehr sehr lange dauern würde und dies eben durch die faire bzw. gleichmäßige Verteilung der Bandbreite auf die I/O-Operationen während des Bootvorgangs bedingt ist, wobei das Medien-Scanning nicht unbedingt die höchste Priorität haben sollte
- Jitter (worst-case-delay) kann manchmal sehr hoch sein, da die Anzahl der Prozess-Aufgaben untereinander konkurrieren
Deadline:
Dieser Scheduler hat das Ziel, die I/O-Wartezeit einer Prozess-Anfrage zu verringern. Das geschieht anhand der Blocknummern der Daten auf dem Laufwerk. Damit aber auch Blöcke mit stark abweichenden Blocknummern bearbeitet werden, erhält jede Anfrage eine maximale Auslieferungszeit. Dieser Governor ist neben dem BFQ sehr beliebt und in vielen bekannten Kerneln wie Netarchy für das Nexus S enthalten. Er sei zwar besser als der BFQ, aber im Vergleich zum VR soll er schwächer sein.
Vorteile:
- Ist annährend ein Echtzeit-Scheduler.
- Zeichnet sich durch Verringerung der Wartezeit von einzelnen Prozessen aus - Bester Scheduler für Datenbankzugriffen und Abfragen.
- Bandbreitenbedarf eines Prozesses, z.B. wieviel Prozent eine CPU braucht, ist leicht zu berechnen.
- Wie der Noop-Governor hervorragend geeignet für Flashlaufwerke
Nachteile:
- Wenn das System überlastet ist, können eine Reihe von Prozessen verloren gehen, und ist nicht so einfach vorhersehbar
VR:
Im Gegensatz zu anderen Schedulern, werden synchrone und asynchrone Anfragen nicht getrennt behandelt, sondern es wird eine faire bzw. ausgeglichene Frist innerhalb dieser Anfragen verhängt, d.h. die nächste Anfrage, die bedient werden soll, ist abhängig von Abstand der letzten Anfrage. Der VR ist ein sehr guter Scheduler mit Elementen des Deadline-Schedulers. Er soll wahrscheinlich der Beste für MTD-Android-Geräten sein. Er ist derjenige, der die meisten Benchmarkpunkte machen kann, aber er sei auch einer instabilsten Schedulern sein, da seine Leistung schwanke. Mal schwankt sie unterhalb des Durchschnitts, mal schwankt sie oberhalb des Durchschnitts, aber wenn oberhalb, dann ist er der Beste.
Vorteile:
- Ist der beste Scheduler für Benchmarks
Nachteile:
- Performance-Schwankungen können zu unterschiedlichen Ergebnissen führen
- sehr unzverlässig bzw. meistens instabil
Simple:
Wie der Name schon sagt, ist er eher ein simpler bzw. einfacher Scheduler. Speziell für EMMC-Geräte geeignet. Er ist zuverlässig, vielleicht nicht so gut wie der VR, wenn dieser mal einen guten Tag hat, aber er ist trotzalledem sehr leistungsbezogen und gibt sein Bestes. Im Moment ist er der Standard-Scheduler bei Quasar-Kernels.
Vorteile: - nicht bekannt
Nachteile: - nicht bekannt
BFQ:
Anstelle Anfragen in Zeitabschnitte aufzuteilen wie der CFQ, weist der BFQ Budgets auf. Dem Flashlaufwerk wird ein aktiver Prozess gewährt, bis es sein Budget (Anzahl der Sektoren auf dem Flashlaufwerk) aufgebraucht hat. Der BFQ vergibt hohe Budgets an nicht gelesene Aufgaben.
Vorteile:
- Hat eine sehr gute USB-Datentransferrate.
- Sei der beste Scheduler zum Abspielen von HD-Videoaufzeichnungen und Video-Streaming ( da weniger Jitter als CFQ und andere Scheduler)
- Gilt als ein sehr genau arbeitender Scheduler
- Erzielt ca. 30% mehr Datendurchsatz als der CFQ
Nachteile:
- Nicht der beste Scheduler für Benchmarks - Höhere Budgets, die einem Prozess zugewiesen wurden, können die Interaktivität beeinflussen und erhöhte Wartezeit mit sich bringen.
SIO:
Er hat das Ziel, bei minimalem Aufwand eine niedrige Wartezeit bei I/O-Anfragen zu erreichen. Keine Priorität bei Warteschlangen zu setzen, stattdessen einfach die Anfragen zusammenzuführen. Dieser Scheduler ist eine Mischung zwischen dem Noop und dem Deadline. Bei ihm gibt es keine Umstellung oder Sortierung bei Anfragen.
Vorteile:
- Er ist einfach und stabil. - Minimierte Starvations (Hungertod) bei Anfragen
Nachteile:
- Langsame zufällige Lesegeschwindigkeiten auf Flashlaufwerken im Gegensatz zu anderen Schedulern. - Sequentielle Lesegeschwindigkeiten auf Flashlaufwerken auch nicht so gut
Persönlich benutze ich unterschiedliche Governors wie Ondemandx, Smartassv2 oder auch mal den Intellidemand, tendenziell eher den Intellidemand, und wenn der nicht vefügbar ist, dann den Ondemandx. Bei den Schedulern favorisiere ich den Deadline und BFQ, aber momentan eher den Deadline.
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.
2.Welche Governors gibt es?
Ich habe bis jetzt 20 Arten von Governors gefunden, wozu ich etwas schreiben kann und ich nachfolgend aufgelistet habe.
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
Legende:
& = Default (standardmäßig eingestellt)
@ = standardmäßig abgestellt
* = im Stockkernel vorhanden
+ = in Quasarkerneln vorhanden
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.
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.
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.
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.
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.
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.
3. Was ist ein Scheduler?
In einem Multitasking-Betriebssystem muss es eine Instanz geben, die den Prozessen, die laufen wollen, Rechenzeit zuteilt und sie nach Ablauf der zugeteilten Zeitspanne (Timeslice) wieder schlafen legt. Diese Instanz bildet der sog. Scheduler, z.B. beim Öffnen und Schließen von Anwendungen. d.h. wie schnell werden sie geöffnet und wie lange sie im RAM gehalten werden.
I/O-Scheduler können viele Zwecke haben wie:
Zeit beim Suchen auf der Festplatte zu minimieren
Prioritäten setzen bei bestimmten Prozess-Anfragen
Einen bestimmten Teil der Bandbreite des Datenträgers zu jedem laufenden Prozess zu regulieren
Bestimmte Prozess-Anfragen innerhalb einer bestimmten Zeit zu garantieren
4. Welche Scheduler gibt es?
Noop *
Anticipatory *@+
CFQ *&
Deadline *@+
VR +
Simple +&
BFQ #
Sio &+
Legende:
&=Default(standardmäßigeingestellt)
@=standardmäßigabgestellt
*=imStockkernelvorhanden
+=inQuasarkernelnvorhanden
Noop:
Der Noop-Scheduler ist der einfachste von ihnen. Er ist am Besten geeignet für Speichergeräte, die nicht von mechanische Bewegungen abhängig sind, wie unsere Flash-Laufwerke in unseren SGSII's, um den Datenzugriff zu verwenden. Der Vorteil ist, dass Flash-Laufwerke keine Neuanordnung der I/O-Anfragen im Gegensatz zu normalen Festplatten benötigen. d.h. die Daten, die zuerst kommen, werden auch als erstes geschrieben. Er ist im Grunde kein richtiger Scheduler, da er das Scheduling der Hardware überlässt.
Vorteile:
- Fügt alle eingehenden I/O-Anfragen in eine Wer-zuerst-kommt- mahlt- zuerst-Warteschlange und realisiert Anfragen mit der geringsten Anzahl von CPU-Zyklen, deshalb auch akkufreundlich
- Ist bestens für Flashlaufwerke geeignet, da es zu keinerlei Such-Fehlern kommt
- Guter Datendurchsatz auf db-Systemen
Nachteile:
- die Verringerung der Anzahl der CPU-Zyklen entspricht einem gleichzeitig einhergehendem Leistungsabfall
Anticipatory:
Zwei wichtige Dinge sind hier bezeichnend für diesen Scheduler:
- Das Suchen auf dem Flashlaufwerk geht sehr langsam von Statten
- Schreibvorgänge können zwar jeder Zeit abgearbeitet werden, jedoch werden Lesevorgänge vorgezogen, d.h. dieser Scheduler gibt den Lesevorgängen eine höhere Priorität als den Schreibvorgängen.
Vorteile:
- Anfragen von Lese-Zugriffen werden nie sekundär behandelt, d.h. hat ähnlich gute Leseleistung auf Flashlaufwerken wie der Noop
Nachteile:
- Anfragen von Prozessvorgängen sind nicht immer verfügbar
- Verringerte Schreib-Performance auf High-Performance- Festplatten
CFQ:
Der CFQ Completely Fair Queuing , ähnlich wie beim Deadline, verwaltet eine skalierbar durchgehende Prozess-I/O-Warteschlange, d.h. er versucht die verfügbare I/O-Bandbreite fair und gleichmäßig auf alle I/O-Anfragen zu verteilen. Dabei erstellt er eine Statistik zwischen den Blöcken und Prozessen. Durch diese Statistik kann er "erahnen", wann der nächste Block von welchem Prozess angefordert wird, d.h. jede Prozess-Warteschlange enthält synchrone Anfragen von Prozessen, die wiederum abhängig von der Priorität des Ursprungsprozesses ist. Es gibt eine V2 vom CFQ und hat einige Fixes, wie z.B. den I/O-Anfrage-Hunger zu stillen und einige kleine Rückwärtssuchen wurden eingebaut um die Reaktionsfähigkeit zu verbessern.
Vorteile:
- hat das Ziel eine ausgewogene I/O-Performance zu liefern
- am einfachsten einzustellen
- hervorragend auf Multiprozessoren-Systemen
- beste Datenbank-Performance nach dem Deadline
Nachteile:
- Einige User berichteten, dass das Medien-Scanning hierbei sehr sehr lange dauern würde und dies eben durch die faire bzw. gleichmäßige Verteilung der Bandbreite auf die I/O-Operationen während des Bootvorgangs bedingt ist, wobei das Medien-Scanning nicht unbedingt die höchste Priorität haben sollte
- Jitter (worst-case-delay) kann manchmal sehr hoch sein, da die Anzahl der Prozess-Aufgaben untereinander konkurrieren
Deadline:
Dieser Scheduler hat das Ziel, die I/O-Wartezeit einer Prozess-Anfrage zu verringern. Das geschieht anhand der Blocknummern der Daten auf dem Laufwerk. Damit aber auch Blöcke mit stark abweichenden Blocknummern bearbeitet werden, erhält jede Anfrage eine maximale Auslieferungszeit. Dieser Governor ist neben dem BFQ sehr beliebt und in vielen bekannten Kerneln wie Netarchy für das Nexus S enthalten. Er sei zwar besser als der BFQ, aber im Vergleich zum VR soll er schwächer sein.
Vorteile:
- Ist annährend ein Echtzeit-Scheduler.
- Zeichnet sich durch Verringerung der Wartezeit von einzelnen Prozessen aus - Bester Scheduler für Datenbankzugriffen und Abfragen.
- Bandbreitenbedarf eines Prozesses, z.B. wieviel Prozent eine CPU braucht, ist leicht zu berechnen.
- Wie der Noop-Governor hervorragend geeignet für Flashlaufwerke
Nachteile:
- Wenn das System überlastet ist, können eine Reihe von Prozessen verloren gehen, und ist nicht so einfach vorhersehbar
VR:
Im Gegensatz zu anderen Schedulern, werden synchrone und asynchrone Anfragen nicht getrennt behandelt, sondern es wird eine faire bzw. ausgeglichene Frist innerhalb dieser Anfragen verhängt, d.h. die nächste Anfrage, die bedient werden soll, ist abhängig von Abstand der letzten Anfrage. Der VR ist ein sehr guter Scheduler mit Elementen des Deadline-Schedulers. Er soll wahrscheinlich der Beste für MTD-Android-Geräten sein. Er ist derjenige, der die meisten Benchmarkpunkte machen kann, aber er sei auch einer instabilsten Schedulern sein, da seine Leistung schwanke. Mal schwankt sie unterhalb des Durchschnitts, mal schwankt sie oberhalb des Durchschnitts, aber wenn oberhalb, dann ist er der Beste.
Vorteile:
- Ist der beste Scheduler für Benchmarks
Nachteile:
- Performance-Schwankungen können zu unterschiedlichen Ergebnissen führen
- sehr unzverlässig bzw. meistens instabil
Simple:
Wie der Name schon sagt, ist er eher ein simpler bzw. einfacher Scheduler. Speziell für EMMC-Geräte geeignet. Er ist zuverlässig, vielleicht nicht so gut wie der VR, wenn dieser mal einen guten Tag hat, aber er ist trotzalledem sehr leistungsbezogen und gibt sein Bestes. Im Moment ist er der Standard-Scheduler bei Quasar-Kernels.
Vorteile: - nicht bekannt
Nachteile: - nicht bekannt
BFQ:
Anstelle Anfragen in Zeitabschnitte aufzuteilen wie der CFQ, weist der BFQ Budgets auf. Dem Flashlaufwerk wird ein aktiver Prozess gewährt, bis es sein Budget (Anzahl der Sektoren auf dem Flashlaufwerk) aufgebraucht hat. Der BFQ vergibt hohe Budgets an nicht gelesene Aufgaben.
Vorteile:
- Hat eine sehr gute USB-Datentransferrate.
- Sei der beste Scheduler zum Abspielen von HD-Videoaufzeichnungen und Video-Streaming ( da weniger Jitter als CFQ und andere Scheduler)
- Gilt als ein sehr genau arbeitender Scheduler
- Erzielt ca. 30% mehr Datendurchsatz als der CFQ
Nachteile:
- Nicht der beste Scheduler für Benchmarks - Höhere Budgets, die einem Prozess zugewiesen wurden, können die Interaktivität beeinflussen und erhöhte Wartezeit mit sich bringen.
SIO:
Er hat das Ziel, bei minimalem Aufwand eine niedrige Wartezeit bei I/O-Anfragen zu erreichen. Keine Priorität bei Warteschlangen zu setzen, stattdessen einfach die Anfragen zusammenzuführen. Dieser Scheduler ist eine Mischung zwischen dem Noop und dem Deadline. Bei ihm gibt es keine Umstellung oder Sortierung bei Anfragen.
Vorteile:
- Er ist einfach und stabil. - Minimierte Starvations (Hungertod) bei Anfragen
Nachteile:
- Langsame zufällige Lesegeschwindigkeiten auf Flashlaufwerken im Gegensatz zu anderen Schedulern. - Sequentielle Lesegeschwindigkeiten auf Flashlaufwerken auch nicht so gut
Persönlich benutze ich unterschiedliche Governors wie Ondemandx, Smartassv2 oder auch mal den Intellidemand, tendenziell eher den Intellidemand, und wenn der nicht vefügbar ist, dann den Ondemandx. Bei den Schedulern favorisiere ich den Deadline und BFQ, aber momentan eher den Deadline.
Veyron93
Fortgeschrittenes Mitglied
- 74
Das gibts sogar schonmal und ihr hattet anscheinend sogar die selben Quellen der Wortlaut ist ja sogar identisch:
-> https://www.android-hilfe.de/forum/...y-s2.521/faq-governors-schedulers.180437.html
Also besser vor dem Erstellen von solchen Threads mal suchen obs einen solchen nicht schon gibt, sonst macht man sich die ganze Mühe umsonst.
der Wortlaut ist ja sogar identisch:-> https://www.android-hilfe.de/forum/...y-s2.521/faq-governors-schedulers.180437.html
Also besser vor dem Erstellen von solchen Threads mal suchen obs einen solchen nicht schon gibt, sonst macht man sich die ganze Mühe umsonst.
Zuletzt bearbeitet:
alf328
Ambitioniertes Mitglied
- 15
Ja das stimmt, ist die gleiche Quelle
GT I9100 MIUI Sakaschi edition
GT I9100 MIUI Sakaschi edition
Kjetal
Mitglied
- 10.214
Wie gesagt, gibt es schon. Danke
SGS II Cyanogen Tapatalk
SGS II Cyanogen Tapatalk
S
Svendrae
Stamm-User
- 369
Hallo,
ich habe jetzt div. Govenors ausprobiert, aber irgendwie habe ich immer das Problem, dass die, die angeblich gut sein sollen als Mix aus Energie sparen und Leistung bei mir zu lags in den Menüs als auch bei Videos (Full HD 1080p MKV) führen.
Z.B. Smartass, lulzactiv, intellidemand, ...
Kernel ist Siyah 2.6.3. Welcher bringt denn trotz guter Leistung eurer Erfahrung nach auch vernünftigen Akkuverbrauch oder schließt das eine das andere generell aus?
Ich brauche ja "nur" etwas, dass im Leerlauf und bei wenig Last sparsam läuft aber bei Last eben dann auch voll aufdreht und das zeitnah
mfg
ich habe jetzt div. Govenors ausprobiert, aber irgendwie habe ich immer das Problem, dass die, die angeblich gut sein sollen als Mix aus Energie sparen und Leistung bei mir zu lags in den Menüs als auch bei Videos (Full HD 1080p MKV) führen.
Z.B. Smartass, lulzactiv, intellidemand, ...
Kernel ist Siyah 2.6.3. Welcher bringt denn trotz guter Leistung eurer Erfahrung nach auch vernünftigen Akkuverbrauch oder schließt das eine das andere generell aus?
Ich brauche ja "nur" etwas, dass im Leerlauf und bei wenig Last sparsam läuft aber bei Last eben dann auch voll aufdreht und das zeitnah
mfg
mecss
Ehrenmitglied
- 11.925
- Themenstarter
- #27
Schau mal, die Governors und Scheduler hier sind Richtwerte bzw. sind eigentlich reine Theorie. Warum? Ganz einfach, weil jeder Dev seine Kernel an den einen oder anderen Governor anpasst und somit die Richtwerte nicht mehr stimmen. Im Großen und Ganzen sieht, leider, die Praxis anders aus und da hilft nur das simple Probieren...vor allem ist es bei jeden Handy/Smartphone immer anders...lese dir die Richtwerte einzelner Governors und Scheduler durch und entscheide nach deinem Gefühl...
C
Corndude
Gast
So wie ich das sehe ist conservative fuer mich der beste governor aus dem einfachen grunde dass er als einziger alle frequenzen abklappert und nur dann noch weiter hochtaktet wenn es wirklich notwendig ist, dass das mehr akku spart als alles andere kann man ja diesem krassen akkuthread entnehmen.
Meine frage ist jetzt: kann ich den governor noch weiter modifizieren? Z.b. Einstellen ab welcher auslastung er in die nächste stufe springt oder zusätzliche screen-off profile einstellen?
Meine frage ist jetzt: kann ich den governor noch weiter modifizieren? Z.b. Einstellen ab welcher auslastung er in die nächste stufe springt oder zusätzliche screen-off profile einstellen?
Mayday
Enthusiast
- 1.018
zu 1.) nein
zu 2.) ja, z.B. mit SetCPU
C
Corndude
Gast
Habs grad ausprobiert, geht b'ides mit setcpu, danke
Jaffi
Stamm-User
- 127
Mayday schrieb:
Falsch! [REF][&Tweaks] Kernel Governors, Modules, I/O Schedulers & CPU Tweaks: Siyah & Others - xda-developers am Ende des ersten Posts findest du die Parameter für den conservative governor.
Mayday
Enthusiast
- 1.018
Dann hätte die Frage vielleicht etwas genauer formuliert werden sollen.
M
mikex
Neues Mitglied
- 0
zuerst danke für den beitrag!
hab grad erfahren dass man die schedulers via "Voltage Control" auswählen kann. und die governors?
ich dachte jeder governor is ne eigene app im market?! oder kommen die schon mit der rom mit?
fahre zur zeit miui
thx miki
hab grad erfahren dass man die schedulers via "Voltage Control" auswählen kann. und die governors?
ich dachte jeder governor is ne eigene app im market?! oder kommen die schon mit der rom mit?
fahre zur zeit miui
thx miki
Dr.Franz
Gesperrt
- 616
mikex schrieb:
Die kannst du auch auswählen mit Voltage Control oder SetCPU
Pletat
Erfahrenes Mitglied
- 145
Hallo zusammen. Vielen Dank für die Mühe des übersetzen. Ich hab zur Zeit mit meiner Checkrom und den DarkKnight Kernel den vr und Lukrative laufen. Kann davon nur schwärmen. Im Quadrat((nicht soo aussagekräftig) 4600 Punkte. Der Akku hält bei intensiver Nutzung locker über einen Tag, d. H. 6 std Display an mit WLAN. Über schwanken Leistungen kann ich nicht klagen.
Mayday
Enthusiast
- 1.018
Welche Einstellungen nutzt Du bei dem Lulz Governor?
Vom Taktverhalten ähnelt der Lulzactiv sehr dem Ondmand, denn die 1000Mhz werden auch da relativ selten genutzt.
Gesendet von meinem S2
Vom Taktverhalten ähnelt der Lulzactiv sehr dem Ondmand, denn die 1000Mhz werden auch da relativ selten genutzt.
Gesendet von meinem S2
Zuletzt bearbeitet:
D
droidstar
Fortgeschrittenes Mitglied
- 2
Kann ich mit Set CPU auch einen Scheduler auswählen oder brauch ich dazu Voltage Control ?
mecss
Ehrenmitglied
- 11.925
- Themenstarter
- #38
Mit SetCPU kannst du nur den Governor einstellen und mit VC beides, d.h. sowohl Governor als auch Scheduler... 
Manu-1
Dauer-User
- 486
Ich muß mich ja auch mal für deine super Anleitung hier bedanken!
Das du, dir so ne Mühe machst, find ich wirklich klasse.
Danke @mecss
Das du, dir so ne Mühe machst, find ich wirklich klasse.
Danke @mecss
Kjetal
Mitglied
- 10.214
SetCpu ist in die Jahre gekommen , Voltage Controle ist momentan einfach die Beste alternative.
SGS II Cyanogen Mod Tapatalk
SGS II Cyanogen Mod Tapatalk
Ähnliche Themen
allstar79
- Gesperrt
- ->TopAZ<-
->TopAZ<-
