payce
Dauer-User
- 1.174
Hallo an Alle!
Hier findet Ihr einige Hinweise und Links zum Thema Overclocking des Milestones. Vor Allem: Installation per Open Recovery und App, Werte für max_vsel und vsel und Weiteres.
OBLIGATORISCH: NEIEN, ICH ÜBERNEHME KEINE VERANTWORTUNG ÜBER ZERSCHOSSENE HARDWARE! IHR BETREIBT HIER AUSSCHLIEßLICH NICHT UNGEFÄHRLICHEN PRIVATSPAß, DER NACH HINTEN LOSGEHEN KANN!!!
Da hierzu schon eine Menge geschrieben wurde, verweise ich einmal auf die obigen Links, vor Allem diesen hier: hier
In kürzester Kurzfassung:
Mit Overclocking (kurz OC) bzw. der App "Milestone Overclock" bzw. der Installation des Moduls overclock.ko habt Ihr die Möglichkeit einerseits die maximal mögliche Taktfrequenz (max_rate) einzustellen. Da bei der "normalen" Betriebsspannung der CPU normalerweise keine höheren Frequenzen stabil betreiben kann, habt Ihr zudem die Möglichkeit die zu der maximalen Taktfrequenz gehörige Betriebsspannung einzustellen (max_vsel). Zu allem Überfluss gibt es auch noch die Möglichkeit, *jede* einzelne Frequenz, die der Stein verwendet (im Normalfall 4 Stück, mit Tricks gehen auch 5), einzustellen und mit einer eigenen Spannung zu versehen (mpu_opps).
Installation von OC
Ich *empfehle* nach einigem rumprobieren Folgendes - in aufsteigender Kompliziertheit:
A) Irgendeine Mod-ROM
Mögliche Werte für max_vsel und max_rate
Die im Folgenden durch User gesammelten Werte für max_vsel haben unter "stable" typischerweise einen Stresstest hinter sich und liefen mehrere Tage problemlos durch. Falls auf Eurem Milestone Probleme auftauchen sollten, einfach max_vsel um 2 Punkte erhöhen und dann sollte alles sehr rund laufen.
Hinweis am Rande: Es sind Fälle bekannt, dass einige Spannungen bei Usern funktionieren, bei anderen nicht. Also aufpassen beim Copy/pasten in den eigenen Stein, hier schlagen Fertigungstoleranzen zu!
Zum Ausprobieren: Milestone Overclock App starten, Menu-Button drücken, Settings und unter "custom rate" und "custom vsel" die gewünschten Werte eintragen. Anschließend Mod installieren (Load module), den Schieberegler ganz nach rechts und auf "Apply". Falls der Stein freezet: Akku raus, Akku rein, neu booten
OVERCLOCK BEIM BOOT
Allgemein gilt heute (glücklicherweise): Bei Installation per Mod-ROM oder OR ist bereits alles Wichtige erledigt, Ihr müsst nur noch Anpassungen in einer Datei durchführen.
HOW TO: VSEL FÜR ALLE FREQUENZEN
Seit overclock.ko Ver. 1.2 ist es möglich, für jede Frequenz im Stein eine eigene vsel zu definieren. Man kann dies ausnutzen, um den Prozessor bei jeder möglichen Frequenz möglichst effizient (in Bezug auf Spannung und Akkuverbrauch) fahren zu lassen.
Vorteile: Optimales Spannungslevel, Lebensdauer der CPU sicher erhöht, Akkuverbrauch etwas gesenkt ("Android OS" und "Android System" typ. unter 10%).
Nachteile: Eventuell instabileres System bei schlechten Werten für vsel.
Wie auch sonst gilt hier heute ebenfalls: In den meisten Mod-ROMs bereits enthalten. (Ein Luxus ist das heute... )
FAQ: Mache ich meinen Stein damit kaputt oder sinkt die Akku-Laufzeit?
Infos zu Governorn
Was ist ein Governor?
Ein sog. "Governor" ist ein meist recht simpler Algorithmus, nach welchem entschieden wird, auf welcher Frequenz der CPU momentan laufen soll. Es gibt zich verschiedene Governor, die je nach Applikation variieren (bspw. "Performance" - CPU immer auf max. Frequenz, oder "PowerSave" - CPU immer auf minimaler Frequenz). Hier werde ich nur die für uns wichtigen behandeln.
Die Parameter der Governor bzw. die Governor selbst stellt man am Besten über Apps wie "SetCPU" ein (die man fürs OC eh braucht). Zu "Overclock Widget" kann ich nicht viel beitragen, da ich die App nicht verwende.
Welche Governor gibt es für Android?
Welchen Governor soll ich wie verwenden?
Ich verwende heute noch den ondemand (20000 µs refresh, 80% threshold, ansonsten 0/0), da ich einfach sehr zufrieden mit diesem governor bin. Ich würde inzwischen aber auch uneingeschränkt smartass empfehlen. Gute Akkulaufzeit bei hervorragender Reaktion.
Welchen Profiles bei SetCPU bzw. Overclock Widget?
Ich persönlich verwende gar keine Profiles, weil der Einfluss auf die Akkulaufzeit marginal ist. Notfalls kann man die max. Frequenz limitieren, wenn der Akku zu warm werden sollte (bspw. auf 500 MHz bei Temperatur > 50 °C). Im Sleep kann man ebenfalls runterregeln, wenn man will (bspw. auf 125/500). !Aber die max_rate nicht unter 500 setzen, vgl. dieser Thread! So richtig viel mehr Akkuleistung wird man aber nicht rauskitzeln können.
PS: Smartass regelt eh auf 250 MHz herunter, wenn der Display ausgeht. Bei Smartass sind also Profiles recht sinnfrei.
Hier findet Ihr einige Hinweise und Links zum Thema Overclocking des Milestones. Vor Allem: Installation per Open Recovery und App, Werte für max_vsel und vsel und Weiteres.
OBLIGATORISCH: NEIEN, ICH ÜBERNEHME KEINE VERANTWORTUNG ÜBER ZERSCHOSSENE HARDWARE! IHR BETREIBT HIER AUSSCHLIEßLICH NICHT UNGEFÄHRLICHEN PRIVATSPAß, DER NACH HINTEN LOSGEHEN KANN!!!
- Wiki-Page des Overclock Tools von tiagosousa alias mirage: hier
- Und hier gibts das OC-Tool als .apk zum Download: hier
- SPENDENLINK für Tiago alias miracle als Danke fürs Overclocking
- Zur Info: Alle einstellbaren CPU-Frequenzen im Überblick: hier
Da hierzu schon eine Menge geschrieben wurde, verweise ich einmal auf die obigen Links, vor Allem diesen hier: hier
In kürzester Kurzfassung:
Mit Overclocking (kurz OC) bzw. der App "Milestone Overclock" bzw. der Installation des Moduls overclock.ko habt Ihr die Möglichkeit einerseits die maximal mögliche Taktfrequenz (max_rate) einzustellen. Da bei der "normalen" Betriebsspannung der CPU normalerweise keine höheren Frequenzen stabil betreiben kann, habt Ihr zudem die Möglichkeit die zu der maximalen Taktfrequenz gehörige Betriebsspannung einzustellen (max_vsel). Zu allem Überfluss gibt es auch noch die Möglichkeit, *jede* einzelne Frequenz, die der Stein verwendet (im Normalfall 4 Stück, mit Tricks gehen auch 5), einzustellen und mit einer eigenen Spannung zu versehen (mpu_opps).
Installation von OC
Ich *empfehle* nach einigem rumprobieren Folgendes - in aufsteigender Kompliziertheit:
A) Irgendeine Mod-ROM
- Inzwischen sind alle wichtigen Mod-ROMs mit OC versehen. Die eigenen OC-Werte können meist in einer eigenen Datei (10_overclock.sh bspw.) angepasst werden. Siehe weiter unten.
- Wichtige Vertreter wären: Cronos, CyanogenMod, MIUI
- Hier sind inzwischen fast alle Open Recoveries geeignet. Bspw. Androidiani OR, GOT OR, oder FuFu's OR SE.
- Die Open Recovery nach den entsprechenden, oben verlinkten Anleitungen starten und per Optionen "Apply/Install Overclock" auswählen.
- Vorraussetzung: root (per obiger Open Recovery kein Problem)
- App "Milestone Overclock" im Market suchen, installieren und starten
- Per Settings gewünschte Werte für custom max_rate und custom max_vsel einstellen (siehe Tabelle weiter unten), zurück in den Anfangsschirm
- Schieberegler nach ganz rechts und auf "Apply"
Mögliche Werte für max_vsel und max_rate
Die im Folgenden durch User gesammelten Werte für max_vsel haben unter "stable" typischerweise einen Stresstest hinter sich und liefen mehrere Tage problemlos durch. Falls auf Eurem Milestone Probleme auftauchen sollten, einfach max_vsel um 2 Punkte erhöhen und dann sollte alles sehr rund laufen.
Code:
[max_vsel]
[frequ.] [stable] [possibly unstable] [probably unstable]
>= <=
550 56 (original setup)
800 48 46 .. 44 42
1000 60 58 .. 56 54
1100 64 62 .. 60 58
* 1200 76 74 .. 70 68
* 1330 84
*: Always unstable in some CPU's! Will damage CPU on prolonged use.
According to OMAP3430 datasheet, max_vsel up to 66 should be acceptable.
Above 80 will certainly severly damage the CPU on long-term scale.
The most appropriate and stable settings seem to be
either 800 MHz or 1000 MHz at max_vsel of 56 to 60.
Zum Ausprobieren: Milestone Overclock App starten, Menu-Button drücken, Settings und unter "custom rate" und "custom vsel" die gewünschten Werte eintragen. Anschließend Mod installieren (Load module), den Schieberegler ganz nach rechts und auf "Apply". Falls der Stein freezet: Akku raus, Akku rein, neu booten
OVERCLOCK BEIM BOOT
Allgemein gilt heute (glücklicherweise): Bei Installation per Mod-ROM oder OR ist bereits alles Wichtige erledigt, Ihr müsst nur noch Anpassungen in einer Datei durchführen.
- Vorraussetzung: root (klar), App "Root Explorer" oder Ähnliches
- Navigiert nach /system/bin
- Dort findet Ihr eines von folgenden Szenarien vor:
- Verzeichnis "boot_script": Alle folgenden Änderungen beziehen sich auf die Datei /system/bin/boot_script/71_overclock.sh
- Wenn Ihr es NICHT findet: Alle folgenden Änderungen beziehen sich auf die Datei /system/bin/mot_boot_mode *oder* (bei FuFus OR Script) mot_boot_mode.71.oc - je nachdem, welche Ihr findet.
- Wenn Ihr dort keine korrekten Einträge findet (also keine, die wie unten aussehen): /system/etc/init.d/10overclock
- (LETZTERES ist heute am Häufigsten anzutreffen)
- Öffnet die entsprechende Datei und durchsucht sie nach einem Eintrag der ungefähr so aussieht:
Code:echo 56 > /proc/overclock/max_vsel echo 800000 > /proc/overclock/max_rate
- Nun könnt Ihr in obigen Beispiel die Werte für max_vsel und max_rate so einstellen, wie Ihr es (anhand von vorherigem Ausprobieren) für gut findet.
- Obiges Beispiel würde nach der Anpassung folgendermaßen aussehen:
Code:
echo 60 > /proc/overclock/max_vsel echo 1000000 > /proc/overclock/max_rate
HOW TO: VSEL FÜR ALLE FREQUENZEN
Seit overclock.ko Ver. 1.2 ist es möglich, für jede Frequenz im Stein eine eigene vsel zu definieren. Man kann dies ausnutzen, um den Prozessor bei jeder möglichen Frequenz möglichst effizient (in Bezug auf Spannung und Akkuverbrauch) fahren zu lassen.
Vorteile: Optimales Spannungslevel, Lebensdauer der CPU sicher erhöht, Akkuverbrauch etwas gesenkt ("Android OS" und "Android System" typ. unter 10%).
Nachteile: Eventuell instabileres System bei schlechten Werten für vsel.
Wie auch sonst gilt hier heute ebenfalls: In den meisten Mod-ROMs bereits enthalten. (Ein Luxus ist das heute... )
1. In einem Terminal (bspw. Better Terminal Emulator) folgende Befehle nacheinander ausführen. Die ersten beiden Befehle dienen dazu, den momentanen Stand abzufragen, denn: Man muss nur die Einträge in mpu_opps ändern, die auch in freq_table auftauchen. Dann die echos entsprechend anpassen (Syntax: echo "[Index] [Frequenz in Hz] [vsel]" > ...).
Mein Beispiel hier gilt für meine Einstellung, in der ich als max_vsel 58 und max_rate 1 GHz vorab gewählt habe. Über den letzten Befehl könnt Ihr nochmal prüfen, ob alles korrekt eingetragen wurde.
WICHTIG: Die Werte für vsel, die ihr oben seht, sollten funktionieren, müssen aber nicht!!! Das sind die Werte, die bei MEINEM Stein stolze 8 - 10 Punkte vom sofortigen Reboot entfernt sind und bei vielen Usern einwandfrei laufen. Also wahrscheinlich auf der sehr sicheren Seite. Falls bei Euch trotzdem etwas schief geht, setzt alle Werte um 2 rauf, bis alles rund läuft. Womit wir bei Punkt ...
2. ... wären. Testen. Testen, ausprobieren, rumspielen. Das Handy mal ein paar Stunden im StandBy liegen lassen. Bei vielen Usern reagiert der Stein vor Allem bei Nutzung der Kamera empfindlich (anscheinend wird sehr oft rauf/runtergerampt und daher ein perfekter Test für obige Einstellungen). Sollten keine spontanen Reboots auftauchen: Herzlichen Glückwunsch! Wenn Ihr lustig seid, könnt Ihr zum Test alle vsels um 2 Punkte runtersetzen. Falls doch: vsel für alle Raten um 2 Punkte raufsetzen.
3. NUR, WENN IHR !WOLLT! und Euch SEHR SICHER seid, dass Ihr stabile Werte gefunden habt, könnt Ihr die folgenden Zeilen am Ende der mot_boot_mode bzw. der 71_overclock.sh bzw. der 10overclock (ob die eine oder andere: Siehe oben unter "Overclock beim Boot") einsetzen bzw. modifizieren, damit die Spannungen beim Boot gleich eingepflegt werden (die ersten drei Zeilen dienen dem Laden der overclock.ko beim Booten und sind schon vorhanden):
Dabei wieder alle Werte für max_vsel, max_rate und die mpu_opps entsprechend Eures Steins anpassen.
Ein letzter Hinweis am Rande: Da der Stein hier *sehr* weit am unteren Limit gefahren wird (bei nur 85% - 90% der Originalspannung) kann es sein, dass der CPU mit dem Alter höhere Spannungen benötigen wird. Leider haben wir hierzu noch nicht allzu viel Langzeiterfahrung. Aber behaltet das bitte im Hinterkopf, wenn Euer Stein in einem halben Jahr oder später mal das Spinnen anfangen sollte.
Vergleich vsel Einstellungen original, Datenblatt OMAP3530 und Mod:
PS: Es ist zwar schon länger nicht mehr vorgekommen, aber als Hinweis: Es gab mal einen Kamera-Freeze-Bug bei zu niedrigen vsels für 125 MHz. Sollte Euer Stein nach einem Schnappschuss und *anschließendem StandBy* einfrieren: Erhöht die vsel für 125 MHz um 4 - 8 und Ihr solltet Ruhe haben. Kommt heut aber nur noch sehr selten vor.
Allgemeine Hinweise zum Thema Overclocking:
Code:
su
cat /proc/overclock/mpu_opps
cat /proc/overclock/freq_table
echo "1 125000000 18" > /proc/overclock/mpu_opps
echo "2 250000000 28" > /proc/overclock/mpu_opps
echo "3 500000000 36" > /proc/overclock/mpu_opps
cat /proc/overclock/mpu_opps
2. ... wären. Testen. Testen, ausprobieren, rumspielen. Das Handy mal ein paar Stunden im StandBy liegen lassen. Bei vielen Usern reagiert der Stein vor Allem bei Nutzung der Kamera empfindlich (anscheinend wird sehr oft rauf/runtergerampt und daher ein perfekter Test für obige Einstellungen). Sollten keine spontanen Reboots auftauchen: Herzlichen Glückwunsch! Wenn Ihr lustig seid, könnt Ihr zum Test alle vsels um 2 Punkte runtersetzen. Falls doch: vsel für alle Raten um 2 Punkte raufsetzen.
3. NUR, WENN IHR !WOLLT! und Euch SEHR SICHER seid, dass Ihr stabile Werte gefunden habt, könnt Ihr die folgenden Zeilen am Ende der mot_boot_mode bzw. der 71_overclock.sh bzw. der 10overclock (ob die eine oder andere: Siehe oben unter "Overclock beim Boot") einsetzen bzw. modifizieren, damit die Spannungen beim Boot gleich eingepflegt werden (die ersten drei Zeilen dienen dem Laden der overclock.ko beim Booten und sind schon vorhanden):
Code:
insmod /data/data/pt.com.darksun.milestoneoverclock/files/overclock.ko
echo 60 > /proc/overclock/max_vsel
echo 1000000 > /proc/overclock/max_rate
echo "4 500000000 36" > /proc/overclock/mpu_opps
echo "3 250000000 28" > /proc/overclock/mpu_opps
echo "2 125000000 18" > /proc/overclock/mpu_opps
echo "1 500000" > proc/overclock/freq_table
echo "2 250000" > proc/overclock/freq_table
echo "3 125000" > proc/overclock/freq_table
Dabei wieder alle Werte für max_vsel, max_rate und die mpu_opps entsprechend Eures Steins anpassen.
Ein letzter Hinweis am Rande: Da der Stein hier *sehr* weit am unteren Limit gefahren wird (bei nur 85% - 90% der Originalspannung) kann es sein, dass der CPU mit dem Alter höhere Spannungen benötigen wird. Leider haben wir hierzu noch nicht allzu viel Langzeiterfahrung. Aber behaltet das bitte im Hinterkopf, wenn Euer Stein in einem halben Jahr oder später mal das Spinnen anfangen sollte.
Vergleich vsel Einstellungen original, Datenblatt OMAP3530 und Mod:
Code:
[FONT=Courier New] Werte für vsel
MHz MS orig. OMAP3530 Stand. OMAP3530 Min. Mod-Werte
125 32 31 27 18
[/FONT][FONT=Courier New]250 39 37 33 28
[/FONT][FONT=Courier New]500 50 48 44 36[/FONT]
- Durch Übertakten wird der CPU evtl heißer, was aber NICHTS ausmacht. Der OMAP3430 ist bis auf 90°C spezifiziert! Da gibt der Akku sehr viel früher den Geist auf. Wichtiger sind Elektromigration (=Lebensdauer niedriger) und erhöhter Akkuverbrauch aufgrund größerer Versorgungsspannung.
- Der Temperatursensor im Stein überwacht den AKKU und NICHT den CPU. Der OMAP3430 hat zwar einen integrierten Temp.sensor, dieser wird im jetzigen Kernel aber nicht ausgelesen. Dazu wäre ein Custom Kernel nötig (welchen es für den Droid bereits gibt).
- Der OMAP ist *offiziell* bei Taktraten von 550 MHz und drüber auf eine Spannung von 1,35 V spezifiziert (also vsel = 60). Laut Datenblatt sind bei 1,35 V 720 MHz Taktrate möglich. Datenblatt OMAP3530 - der 3530 ist zum 3430 nahezu baugleich. Als maximale Spannung sind laut Datenblatt 1,425 Volt möglich (also vsel = 66). Siehe hierzu Tabellen 3-3 und 4-15. Über 1,42 Volt bzw. 720 MHz ist man nicht mehr in den Specs und beschädigt eventuell den OMAP. Bereits bei 720 MHz garantiert TI keinen fehlerfreien, aber einen schädigungsfreien Betrieb.
- Nochmal zum Thema Unterspannung (max_vsel gleich oder unter 55): Nach bisherigen Kenntnissstand können Unterspannungen den CPU nicht beschädigen. Das gilt aber nur dann, wenn eine Unterspannung NICHT völlig sinnfrei für eine viel zu hohe Frequenz gewählt wurde (bspw. max_vsel 20 bei max_rate 1330 - das wäre Schwachsinn). In einem solchen Fall können in sehr, sehr seltenen Fällen anscheinend Schäden am Flash Speicher entstehen.
- Bezüglich der Umrechnung von max_vsel in die tatsächliche Spannung: Tatsächliche Spannung = 0,6 Volt + (vsel * 0,0125 Volt)
FAQ: Mache ich meinen Stein damit kaputt oder sinkt die Akku-Laufzeit?
- Zur Akku-Laufzeit siehe dieser Thread (Zusammenfassung: vsel wirkt sich linear aus, cpu_rate wirkt sich linear aus. Die kombinierte Erhöhung von vsel und cpu_rate, die ja beim OC Pflicht ist, wirkt sich in Summe also wieder quadratisch aus): https://www.android-hilfe.de/forum/...os-ladekurven-leistungsverbraucher.73360.html
- Die Erhöhung der Taktfrequenz *alleine* (ohne max_vsel zu verändern): Die Lebensdauer der CPU ist davon kaum beeinflusst (zumindest nicht so sehr, dass es einem innerhalb der typischen Handylebensdauer auffallen wird)! Es wird lediglich nicht garantiert, das fehlerfreie Berechnungen durchgeführt werden.
- Ganz anders die Erhöhung der Spannung (max_vsel): Hier schlägt sich der Wert DIREKT auf Lebensdauer der CPU nieder. Die Elektromigration (also das Ausdünnen der Leiterbahnen auf den Chips - umgangssparachlich "ausbrennen") schlägt ebenfalls voll zu.
- Laut Datenblatt sind Werte für max_vsel zwischen 56 und 66 noch voll in der Spec und werden daher weder die Laufzeit noch die Lebensdauer entscheidend beeinflussen. Ich persönlich würde sogar 110% der Nennspannung (max_vsel = 71) noch als sicher betrachten. Das Datenblatt von TI gibt als absolute Obergrenze 1,6 V an (max_vsel = 80). Aus dem Desktop-Bereich ist bekannt, dass eine Spannung über 125% der Nennspannung zu einem recht flotten Durchbrennen der CPU führen kann. In unserem Falle sind das max_vsel = 85 und höher. Diese Werte würde ich tunlichst vermeiden, eventuell halbiert (oder schlimmer) man damit die Lebensdauer des Steins.
Infos zu Governorn
Was ist ein Governor?
Ein sog. "Governor" ist ein meist recht simpler Algorithmus, nach welchem entschieden wird, auf welcher Frequenz der CPU momentan laufen soll. Es gibt zich verschiedene Governor, die je nach Applikation variieren (bspw. "Performance" - CPU immer auf max. Frequenz, oder "PowerSave" - CPU immer auf minimaler Frequenz). Hier werde ich nur die für uns wichtigen behandeln.
Die Parameter der Governor bzw. die Governor selbst stellt man am Besten über Apps wie "SetCPU" ein (die man fürs OC eh braucht). Zu "Overclock Widget" kann ich nicht viel beitragen, da ich die App nicht verwende.
Welche Governor gibt es für Android?
- UserSpace: Hier kann man wahrscheinlich irgendwie einen eigenen Algorithmus einpflegen. Bisher gibt es aber keine Infos, wie das Ganze genau ausschauen soll. Daher einfach ignorieren.
- Performance: Der CPU läuft immer auf max. Frequenz. Sehr schlecht für die Laufzeit des Steins. Für Benchmarks allerdings super.
- Conservative: Das ist ein Governor, der nachträglich installiert werden muss (über das Modul conservative.ko), siehe diese Page. Wer nicht weiß, wie das geht, einfach die Finger davon lassen. Der Conservative Governor regelt die CPU-Frequenz durchgängig schrittweise. Und zwar so, dass die CPU-Last immer zwischen eine "Up Threshold" und "Down Threshold" liegt. D.h. ist die CPU-Last über "Up-Threshold" wird bspw. 125 -> 250 -> 500 -> 1000 gerampt und umgekehrt bei Unterschreitung von "Down Threhold" 1000 -> 500 -> ... das Ganze passiert minmal alle 125000 µs "Refresh Rate", also alle 125 ms. Im schlechtesten Fall heißt das, der CPU ist nach 375 ms auf maximaler Rate.
- Interactive: Ebenfalls ein Governor, der nachträglich installiert werden kann, siehe hier. Der Governor ist in so mancher OR bereits integriert. Der Interactive Governor funktioniert ähnlich wie OnDemand (siehe nächster Punkt), mit zwei kleinen, aber sehr feinen Unterschieden: Kommt der Stein aus dem Sleep-Modus wird der CPU "vorsichtshalber" erst einmal auf volle Bulle gefahren (ohne Überprüfung). Das ist sehr sinnvoll, da man ja typischerweise eine hohe Belastung dann zu tragen hat. Und zweitens: Statt die Belastung *nach* einer Zeitspanne zu messen (wie bei ondemand oder conservative) wird hier die sog. workqueue abgefragt - sprich, wieviel liegt *jetzt* gerade an Aufgaben an. Einziger Nachteil: Interactive "überschätzt" sehr gerne mal und saugt daher etwas mehr Akku als andere Governor.
- Smartass: Ein recht neuer Governor der prinzipiell ähnlich zum interactive läuft, allerdings bei bestimmten Vorgängen vorsichtshalber auf volle Bulle schaltet (daher auch das "smart"). Dazu gehören bspw. Display On oder auch offensichtliche Überlastungen der CPU. Genaue Infos gibts wie immer bei nadlabak, dem Gott der Governor. Ist momentan der beliebteste, weil ausgeglichenste Governor. Wer ihn sich mal ganz genau zu Gemüte führen will: Hier
- OnDemand: Der On-Demand Governor funktioniert etwas simpler wie der Conservative und ist bei Android Standard. Überschreitet die CPU-Last die "Up-Threshold" wird sofort auf maximale CPU-Frequenz geregelt (125 -> 1000). Anschließend wird die CPU-Frequenz schrittweise so zurück geregelt, dass die CPU-Last "Up Threshold" nicht überschreitet (1000 -> 500 -> 250 -> 125). Hier ist die minimale "Refresh Rate" 15625 µs, also etwa 16 ms. Es gibt noch die Parameter "PowerSave Bias" und "Nice load". Beide sind in Android recht unwichtig und können auf 0 gesetzt werden. Wer genaueres dazu erfahren will, kann sich diese beiden Links anschauen: Einmal Zweimal
Welchen Governor soll ich wie verwenden?
Ich verwende heute noch den ondemand (20000 µs refresh, 80% threshold, ansonsten 0/0), da ich einfach sehr zufrieden mit diesem governor bin. Ich würde inzwischen aber auch uneingeschränkt smartass empfehlen. Gute Akkulaufzeit bei hervorragender Reaktion.
Welchen Profiles bei SetCPU bzw. Overclock Widget?
Ich persönlich verwende gar keine Profiles, weil der Einfluss auf die Akkulaufzeit marginal ist. Notfalls kann man die max. Frequenz limitieren, wenn der Akku zu warm werden sollte (bspw. auf 500 MHz bei Temperatur > 50 °C). Im Sleep kann man ebenfalls runterregeln, wenn man will (bspw. auf 125/500). !Aber die max_rate nicht unter 500 setzen, vgl. dieser Thread! So richtig viel mehr Akkuleistung wird man aber nicht rauskitzeln können.
PS: Smartass regelt eh auf 250 MHz herunter, wenn der Display ausgeht. Bei Smartass sind also Profiles recht sinnfrei.
Zuletzt bearbeitet: