[How-To] vsel's, mpu_opps etc. [Overclocking]

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!!!

• 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

Overclocking/OC?? Was ist Overclocking??
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

B) OC per Open Recovery (Abk. OR):

• 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.

C) App vom Market installieren:

• 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"

Die App kann man immer installieren, auch nach OR oder Mod-ROM. Man hat dann die Möglichkeit, per App "wilde Werte" für max_rate und max_vsel auszuprobieren ohne Gefahr zu laufen, eine Rebootschleife zu erzeugen. Sind stabile Werte gefunden, können diese in die Scripte eingebaut werden, die bereits bestehen.


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.

• 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

!ACHTUNG! Das Ändern der mot_boot_mode und/oder der 71_overclock.sh und/oder 10overclock birgt IMMER das Risiko, eine Bootschleife zu erzeugen! Man sollte *OHNE AUSNAHME* bei solchen Änderungen immer ein nandroid Backup erstellen! Wer nicht weiß, was das ist, BITTE VORAB EINLESEN! Nandroid Backups sind mit ALLEN Open Recovery Versionen ohne Weiteres möglich und sehr, sehr schnell erledigt!

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... )

Allgemeine Hinweise zum Thema Overclocking:

• 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)

FAZIT für max_vsel: <56 wers braucht, 56 - 66 voll in Specs, 67 - 71 wahrscheinlich verträglich, 72 - 80 Variante für Mutigere oder kruzfristige Ausprobier-Geschichten, 81 und drüber: Burn baby burn.

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

Die meisten Governor können hier genauer betrachtet und downgeloadet werden: https://github.com/nadlabak/android_device_motorola_umts_sholes/tree/froyo/prebuilt/lib/modules

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.

• max_rate: 1,33 GHz
• max_vsel: 84
• SetCPU 250/1,33GHz (ondemant)
• Lief 4 Stunden stabil alledings hohe wärmeentwicklung beim Spielen (snes emulator)

• max_rate: 1,4 GHz
• max_vsel: 88
• SetCPU 250/1,4GHz (ondemant)
• Lief 30 Minuten stabil alledings sehr hohe wärmeentwicklung beim Spielen (snes emulator) und totaler absturz nach 20 Minuten ist wohl einfach zuviel

• max_rate: 1,2 GHz
• max_vsel: 80
• SetCPU 250/1,2GHz (ondemant)
• Lief 4 Stunden stabil wärmeentwicklung geht so beim Spielen (snes emulator)

• max_rate: 800 mHz
• max_vsel: 68
• SetCPU 125/800 mHz
• Hab das Gestern eingestellt und hatte seitdem einen FC. Muss aber nicht an der Taktung liegen.

P.S. ich bin schon in deiner Liste oben drinnen

• max_rate: 800 MHz
• max_vsel: 62
• SetCPU 250/800 MHz
• SetCPU sleep 125/125 MHz
• //Edit gelegentliche freezes

//EDIT
max vsel 62 sorgt für freezes bei sehr CPU lastigen anwedungen wie dem kopieren großer datenmengen oder dem taggen von MP3s. Mit 68mV gibts keine Probleme

• max_rate: 800 MHz
• max_vsel: 62
• OverclockWidget 250/800 MHz
• Lief 1 Tag stabil

• max_rate: 1000 MHz
• max_vsel: 70
  
• OverclockWidget 250/1000 MHz
• Läuft seit 6h stabil

@gmadzl: Macht nix, soll ja eine Mehrfachzählung werden. Auch wenn man schon drinnen steht, ruhig melden. Umso besser.

@moppelg: Hab jetzt mal bei Deinem Wert ein (?) dazu gesetzt. Nur wegen der bisherigen 3 h. Wenn das natürlich länger halten würde -> goiel. Weil Spannung noch in den Specs, aber Taktfrequenz weit drüber.

• max_rate: 1000 MHz
• max_vsel: 69
• OverclockWidget 250/1000 MHz
• Lief 1/2 Tag stabil
• Battery verbrauch ca. 10%

• max_rate: 1200 MHz
• max_vsel: 75
  
• OverclockWidget 250/1200 MHz
• Läuft seit 8 h stabil
• Battery verbrauch ca. 15% - 20%

• max_rate: 1000 MHz
• max_vsel: 72
  
• Lief 1/2 Tag stabil
• Battery verbrauch ca. 10%

• max_rate: 1000 MHz
• max_vsel: 69
  
• Läuft seit 1 h stabil

max_rate: 1000 Mhz
max_vsel: 70
seit 24h stabil

Meiner dreht inzwischen erfolgreich bei 65 seine Runden...

• 
  Max Rate 800Mhz

• Max Vsel 62

• OverclockWidget Screen On Max 800Mhz

• OverclockWidget Screen On Min 250Mhz

• OverclockWidget Screen Off Max 500Mhz

• OverclockWidget Screen Off Min 125Mhz

läuft seid gestern nachmittag stabil
kaum merklich erhöhter Akkuverbrauch

bin auf 1Ghz und 68 runter, mal sehen was noch geht

• max_rate: 1 GHz
• max_vsel: 67
• läuft super stabild seit einem tag !

kann jemand einschätzen wie stark die lebensdauer zurück geht ?
ich habe angst das mein steinchen in nem halben jahr tschüs sagt ...!