[DISKUSSION] Strategien den OC und NOOC Kernel zu vereinigen

[u.k-f]

Hallo zusammen

In diesem Thread möchte ich über veschiedene Möglichkeiten diskutieren, den OC und den NO-OC Kernel mit einander zu vereinigen.

Mein Problem ist etwa das folgende:

Ich kann beim initialisieren des Kernel die Range der möglichen Taktfrequenzen beeinflussen. Zu diesem Zeitpunkt ist jedoch das Filesystem nicht gemountet Folglich kann ich hier keine config Datei auswerten. Das einzig was ich (bisher) zu diesem Zeitpunkt auswerten kann, ist die Kernel-Command-Line die im boot.img drin steht.

Um in einem Kernel das OC vom Tablet her dynamisch setzen können, müsste ich also die Kernel-Command-Line die im boot.img steht aus dem Tablet heraus setzen können. Besteht dazu eine Chance?

Die Alternative wäre ein 'Speed-Down-Governor', der im Kernel als Default-Governor gesetzt wird. Dieser Governor ist, da er der Default ist, zur Boot-Zeit aktiv und verhindert das Übertakten der CPU, solange gebootet wird. Wenn nach dem Booten ein User-Tool andere CPU-Speed-Werte oder einen User-Governor setzt, kann auf User-Wunsch das OC genutzt werden, wird nichts eingestellt, behält der 'Speed-Down-Governor' die Kontrolle und verhindert damit das übertackten der CPU

Bitte schreibt mir Eure Meinungen und Vorschläge

Danke Uwe

 

[SkyfaR]

Finde die zweite Idee sehr gut, das das OC ja eigentlich nur auf User Wunsch genutzt weil er wenn das Tablet gestartet ist mehr Power haben will, von daher da der Auto-Normal User kein CPU brauch mit mehr Power beim Booten würde es für mich nicht viel sinn machen das man den CPU von Anfang an mit mehr Power versehen muss. Man könnte aber falls einer eine kleine App schreiben könnte ein Tool zum steuern des CPU´s zuständig ist was den CPU beschleunigt nach Startvorgang von alleine sofern der User das vorher eingestellt hat.

 

[ChrisHa]

Also von anderen Kernel (für andere Geräte) kenne ich das eigentlich nur so... der Standardtakt ist voreingestellt und per oc- Tool kann dieser nach oben oder unten geregelt werden... vielleicht solltest Du mal bei Nothrills aus dem A510 Forum nachfragen wie der das regelt...

 

[u.k-f]

Also von anderen Kernel (für andere Geräte) kenne ich das eigentlich nur so... der Standardtakt ist voreingestellt und per oc- Tool kann dieser nach oben oder unten geregelt werden... vielleicht solltest Du mal bei Nothrills aus dem A510 Forum nachfragen wie der das regelt...

Den kenne ich doch garnicht...

Also was ich meine ist, dass ich mich nicht trauen würde, so eine tiefgehende Frage an jemanden, mit dem ich bisher keinen Kontakt hatte, zu stellen. Wenn Du Ihn kennst, frage Du ihn doch, ich wäre durchaus an der Info interessiert.

Grüsse Uwe

 

[ChrisHa]

Ich kenne den auch nicht, hätte aber da keine Berührungsängste... man ist hier ja anonym... außerdem habe ich aber nicht die notwendigen Kenntnisse um mich da über den Bau eines Kernel zu unterhalten...

 

[Touchscreen-Lover1]

Ich finde die Variante 2 auch sehr gut da ich finde wenn das tab die power braucht ,sie dann auch bekommen sollte. Mein Vorschlag wäre jetzt dass man den kernel so regelt dass er am Anfang und auch als Standart mit 1.2-1.3 GHz taktet und man ihn dann nach Belieben UC oder OC kann. Würde aber als Grenze nach oben die 1.6 oder max 1.7 machen, da ich denke dass das Tab das nicht auf Dauer mitmachen kann/will. Aber coole Idee

LG Ardian

Gesendet von meinem A210 mit James Rom 3.0 avec le Tap à talk

 

[u.k-f]

Es ist mir gelungen, eine ganz andere Strategie zu implementieren.

Ich werde den Kiwi+Kernel mit einem OC-Modul ausliefern.

Ist das Modul nicht geladen, so läuft er mit 1,3 GHz.

Wird das Modul mit insmod geladen, läuft er ab dann mit 1.7 Ghz.

Wird das Modul mit rmmod entfernt, läuft er wieder auf 1.3 GHz.

Vielleicht gelingt es mir sogar, dem Modul eine config-Datei zu verpassen, um Zwischengeschwindigkeiten (z.B. 1.5 GHz) zu ermöglichen.

Grüsse Uwe

 

[SkyfaR]

Ich denke auf dauer wird deine Variante zu Akkubelastend sein, vorallem wie soll, bzw kannst du wohl kaum verlangen das ein Laye was 90% der Android Community sind mit insmod und rmod was anfangen kann.

 

[u.k-f]

Die 1.7 GHz sind genau die gleichen wie beim jetztigen OC-Kernel . Mögliche Obergrenze bei Last, wird durch den Governor nur Last abgerufen (Im Moment läuft der Kernel doch auch nicht permanent mit 1.3 GHz). Das Laden des Modules wird insofern nicht als Benutzerinteraktion sonder eher als Installation zu verstehen sein, indem eine Datei OCinit.sh ins init.d Verzeichnis gelegt wird:

#!/system/init.d/OCInit.sh
Insmod /system/lib/modules/....ko

Das lässt jedem die Freiheit zu entscheiden, was er möchte, Insider können auch zu und abschalter 'on the fight'

Grüsse Uwe

 

[SkyfaR]

Okay wusste jetzt nicht das du es soweit durchdacht hattest schon, so ergibt das auch wesentlich mehr sinn für normale Anwender.

Und wenn der CPU nur Ressourcen zieht wenn lasst vorhanden dann dürfte der Akkuverbrauch nicht sonderlich leiden und man geht kein Risiko ein das dass Tablet schmort.

 

[u.k-f]

Und wenn der CPU nur Ressourcen zieht wenn lasst vorhanden dann dürfte der Akkuverbrauch nicht sonderlich leiden und man geht kein Risiko ein das dass Tablet schmort.

Da sollte (nach meinem Verständnis des Linux/nVidia Source-Codes) sowieso kein Grund zur Sorge sein, da der Acer-Standard-Kernel (und somit mein Kernel auch, da ich das NICHT geändert habe) über eine Thermal-Throttel verfügt. Das ist Code, der bei zu hoher CPU-Temperatur den Takt runter zwingt...

Grüsse Uwe

 

[SkyfaR]

Okay das war mir nicht bekannt ich kenne das zwar vom Handy aber das der Acer Kernel sowas hat wusste ich nicht.

Die frage ist nur die ich mir jetzt stelle in wie fern lässt sich der Kernel denn überhaupt sinnvoll übertakten? Da es logisch sein wird das der CPU warm laufen wird bei Übertaktung.
Da der Kernel ja von alleine erkennt das dass Gerät wärmer wird wie lange bleibt die effektive Leistung von 1,6-1,7 Ghz wirklich bestehen bevor die Temperatur Kontrolle ein strich durch die Rechnung macht und bei welcher Temperatur regelt der CPU runter.

 

[u.k-f]

Die frage ist nur die ich mir jetzt stelle in wie fern lässt sich der Kernel denn überhaupt sinnvoll übertakten? Da es logisch sein wird das der CPU warm laufen wird bei Übertaktung.

ARM Prozessesoren sind auf Grund ihrer genial einfachen Struckur erstaunlich wenig anfällig fürs zu heiss werden. Bei zu hohem Takt kommt es eher vor, dass der Prozessor sich 'verhaspelt' (d.h. es haben noch nicht alle Transistoren geschaltet, bis der Taktzyklus rum ist) und es kommt zu einem falschen Ergebnis und mithin zu einem Software-Absturtz...

Da der Kernel ja von alleine erkennt das dass Gerät wärmer wird wie lange bleibt die effektive Leistung von 1,6-1,7 Ghz wirklich bestehen bevor die Temperatur Kontrolle ein strich durch die Rechnung macht...

Nach Aussage einiger User des OC bleibt die Temperatur auf Dauer in einem Bereich, wo nicht runter geregelt wird...

...und bei welcher Temperatur regelt der CPU runter.

Das konnte ich leider noch nicht rausfinden.

Ich möchte noch anmerken, dass nach meinem Empfinden der größte Performance-Gewinn der Schritt von 1.3 GHz nach 1.5 GHz ist, darüber hinaus fällt es nur noch weing auf.

Mit einem Tool wie System-Tuner kann man bei aktiviertem OC einstellen, in welchem Bereich dann tatsächlich der Takt sich bewegen darf. Da würde ich als Obergrenze 1.5 GHz empfehlen. Das muss aber jeder für sich entscheiden.

Grüsse Uwe

 

[mastera4]

antutu benchmark 1.5 Ghz 14600 Punkte - 1.7 Ghz 14800 Punkte kaum unterschiede, da 1.5 Ghz sinnvoller.

 

[u.k-f]

antutu benchmark 1.5 Ghz 14600 Punkte - 1.7 Ghz 14800 Punkte kaum unterschiede, da 1.5 Ghz sinnvoller.

Jepp! Das meinte ich...