[Diskussion] CyanogenMod 7 mit 2ndboot für das Milestone (CM7)

[fipsy]

fipsy: Why have you decided to use vsel values for completely different CPU family?

The reason was, that I already used the values that were marked as 'ideal' on maemo.org for frequencies above 500 MHz. So testing with the same values wouldn't have made much sense if the high frequency values would have been responsible for the problem.

But I think we both believe that the low frequency values are responsible, do you? So at low frequencies I use the values from maemo.org.

I didn't have the 'cpufreq stuck issue' until now. So the assumption condenses that you have been right with your supposition!

Der ursprüngliche Beitrag von 19:21 Uhr wurde um 19:28 Uhr ergänzt:

[APP] CPUStats - simple cpu statistics (updated 06.03.2011) - xda-developers
da sieht man auch den deepsleep anteil besser ^^

Ich finde CPUStats wirklich super! Einfach und informativ. So muss das sein. Man kann damit auch gut rausbekommen, welche Frequenzen häufig und welche so gut wie gar nicht benutzt werden. Damit kann man seine Frequenztabelle in 10overclock sehr gut im Hinblick auf die am häufigsten genutzten Frequenzbereiche optimieren.

 

[-FuFu-]

ich nutz es hauptsächlich um den deepsleep anteil zu bestimmen...
bei meinem 2.2.1 mod ist 550mhz am meisten benutzt, 900 und 700 sind fast identisch und 250 ist auch recht hoch, da der stein am ladegerät ja nicht in den deepsleep geht...

aber bei cm7 hab ich noch immer nur nullen, ber da ich morgen besuch krieg, war es das erstmal mit der fehlersuche

 

[fipsy]

Ist sehr seltsam, dass bei dir das Modul nicht funktioniert. Wird es denn in /etc/init.d/99cpufreq_stats geladen?

Seitdem ich nadlabaks Hinweise umgesetzt habe und die Frequenzen und vsel Werte geändert habe, ist der Akku-Drain / 'cpufreq stuck issue' nicht mehr aufgetreten. Schon seit über 24 Stunden nicht mehr. Außerdem hält der Akku nun rund 27 Stunden bei recht intensiver Nutzung. Früher war da nach spätestens 19 Stunden schluss.

Daher noch ein fetter Dank an nadlabak! Dass die CPU-Spannung bei niedrigen Frequenzen für dieses kuriose Problem verantwortlich ist, obwohl das Gerät sonst völlig fehlerfrei lief, hätte ich nie gedacht!

Auch bei mir liegt der Hauptanteil der Frequenznutzung bei 600 MHz und bei 250 MHz (siehe beigefügte Grafik). Obwohl ich das Gerät nicht am Ladegerät lade und es rund 65% der Zeit im Deep Sleep war. Die niedrigste Frequenz wird also in jedem Fall gerne genutzt.

Deshalb werde ich auch nochmal einen Test mit 150 MHz und höherer CPU-Spannung machen. Eigentlich sollte es so sein, dass der Stromverbrauch bei konstanter Spannung umso niedriger ist, desto niedriger die Frequenz ist. Wenn man also 250 MHz nutzt, obwohl auch 150 ausreichen würden, verplempert man eigentlich Strom. Würde zumindest der Elektrotechniker sagen. Ich habe hier aber immer wieder gelesen, dass dem nicht so ist. Ich habe aber nie eine physikalisch einleuchtende Erklärung dafür gelesen. Vielleicht hat ja irgendjemand eine?

Wie auch immer, da hauptsächlich 250 und 500-600 MHz genutzt werden, wäre es sinnvoll, die Frequenzen um diese Werte herum anzusiedeln und die Frequenzen in der Mitte ganz wegzulassen. Also z.B.: 150, 300, 500, 650 und 800 MHZ.

Und so am Rande: Auch der Modemfehler, der von einigen immer wieder beklagt wurde, tritt bei mir gehäuft auf, wenn ich zu niedrige vsel-Werte wähle. Also auch dieses Problem könnte mit der CPU-Spannung zusammenhängen!

 

[fipsy]

Alles Quark, was wir bisher zu dem 'frequency stuck' bzw. Akku-Drain-Problem geschrieben und vermutet haben! Alle bisherigen Vermutungen waren falsch. Auch die mit dem vsel-Wert. Ich habe mir die ganze Nacht um die Ohren geschlagen, um dem Fehler auf die Spur zu kommen. Keiner wird glauben, was das Problem wirklich ist. Auch der Modemfehler, der bei manchen auftritt, hat dort seine Ursache. Aber dazu gleich mehr.

Ich hatte zu Beginn meine 10overclock wieder etwas modifiziert gehabt: Ein paar andere vsel-Werte und eine neue Frequenz. Ich habe die Abstufung auf 250, 400, 500, 650 und 800 MHz gesetzt. Danach bekam ich plötzlich bei jedem Neustart einen Modemfehler. Teilweise kam ich auch gar nicht über die PIN-Eingabe hinaus: Das Handy hängte sich weg und startete neu. Ich habe dann wie ein Bekloppter die vsel-Werte geändert und sukzessive hochgesetz: Ohne jeden Erfolg. Ich war kurz vor dem Verzweifeln, als mir plötzlich eine Idee kam: Könnte es vielleicht gar nichts mit den Spannungen, sondern mit den Frequenzen zu tun haben? Ich verglich die Frequenzliste und stellte fest, dass die Frequenz 650 MHz neu war. Die hatte ich noch nie getestet. Also habe ich den vsel-Wert mal auf den selben gesetzt, wie bei 800 MHz (56): Sofort wieder Absturz! Dann auf 60 hochgesetzt: Und auch Absturz! Das konnte eigentlich nicht sein - ich wurde hellhörig. Daher habe ich die 650 MHz in 600 MHz umgewandelt. Und siehe da: Alles lief plötzlich wieder einwandfrei.

Es gibt also beim Milestone schlichtweg "forbidden frequencies", wenn man diese nutzt, hängt sich das Gerät totsicher weg. Und dazu gehören 150 und 650 MHz. Völlig unabhängig vom vsel-Wert. Dies habe ich bisher noch niemals irgendwo gelesen, aber es ist reproduzierbar.

Ich bin gespannt, ob andere diesen Fehler reproduzieren können: Einfach in 10overclock eine Frequenz in 650 MHz umwandeln (vsel zwischen 50 und 60). Ich bin mir sicher, dass ihr dann nicht mehr über die PIN-Eigabe hinaus kommt oder zumindest einen Modemfehler bekommt. Aber Achtung: Ihr könnt euer Gerät dann nur noch "reanimieren", indem ihr über die OpenRecovery in der Konsole die Datei 10overclock löscht. Wer sich also mit der Konsole oder der OpenRecovery nicht auskennt, sollte den Test sein lassen.

Schöne Grüße, Volker

 

[-FuFu-]

sehr komisches verhalten, aber wenn es repruduzierbar ist, kann es weiter helfen
ich hab nicht die zeit es es zutesten, aber ich werd mal sehen, ob ich es die Tage mal hinbekomme....

interessant ist es sicher für die, die ein ähnliches problem haben und auch eigene OC Werte nutzen...

aber komisch ist es schon, das einzelne frequenzbereiche so probleme verursachen können


und ja, das Modul ist bei mir geladen, mit dem befehl lsmod wird es angezeigt, entweder hat es was mit meinen oc werten zu tun oder meinen build.prop änderungen, das ich nur nullen hab, das muß ich noch rausfinden denn was anderes hab ich nicht geändert

 

[fipsy]

aber komisch ist es schon, das einzelne frequenzbereiche so probleme verursachen können

Eigentlich nicht unbedingt. Ich kenne das aus der Microcontroller-Programmierung: Frequenzen können ja immer nur durch ganzzahlige Werte geteilt werden und der Teiler selbst hat meist nur 16 Bit. D.h. man teilt immer nur durch ein Vielfaches des 16-Bit-Wertes. Wenn man eine hohe Frequenz hat, aber eine relativ niedrige braucht, wird die Sache so etwas ungenau. Soll- und Istwert weichen dann voneinander ab. Wenn man bei einem Microcontroller auf diese Weise z.B. den Takt für eine serielle Schnittstelle erzeugt, so driftet dieser bei bestimmten Taktraten immer wieder weg, so dass in regelmäßigen Abständen Datenfehler auftreten.

Etwas ähnliches könnte ich mir für das Milestone und seinen Modem vorstellen. Ich weiß nicht, was der Modem dort genau macht, aber auf jeden Fall moduliert und demoduliert er. Da dies ganz sicher etwas mit Frequenzen zu tun hat, ist diese Erklärung für das Problem nicht unbedingt abwegig. Seltsam ist nur, dass man darüber bisher noch nirgendwo was gelesen hat.

 

[TeCci]

Hmmm mag mir keiner was zu meinem Post auf der vorigen Seite sagen? :E
Nichtmal das mit den Zahlen bei setCPU?

@fipsy:
So wie ich es verstanden hatte, liegt der Unterschied zwischen 250Mhz und 500/550Mhz in der Definition zwischen Effektiv und Effizient.

500 oder 550Mhz sollen am Effizientesten laufen, da auf dieser Stufe am wenigsten Strom im Vergleich zur Rechengeschwindigkeit verbraten wird. Wenn du halb so viel Strom verbrauchst pro Minute, aber anstatt 1 Minute dann 3 Minuten brauchst, um etwas zu berechnen, ist Rechenleistung/Stromverbrauch-faktor natuerlich bei dem hoeheren Wert effizienter.

So war meine Interpretation. WENN Rechenleistung gebraucht wird, ist der Wert ( ich glaube payce schrieb in seinem Beitrag was von zwischen 500 und 600Mhz ) am effizientesten, wenn der CPU aber nur idelt und keine Rechenleistung benoetigt wird ist die niedrigste Spannung natuerlich am Stromsparensten.

Du darfst nicht den Fehler machen und denken, dass vsel 30 halb so viel Strom verbraucht wie vsel 60, da ich glaube ( und sei mir nicht boese wenn ich mich hier mit PC-hardware-Spannungen vertuhe, da ich die von der Arbeit her im Kopf habe ^^ ) beim Standart-vsel von 56 liegt eine Spannung von 1,350Volt an, bei einer vsel von 60 eine Spannung von 1,400Volt. Ergo sind eine Erhoehung oder Verminderung um 2 vsel ein Unterschied um 0,025Volt.

Ich kann die keine Garantie darauf geben, dass diese Logik und Rechenbeispiele tatsaechlich zutreffen, aber so habe ich es interpretiert. Korrigiert mich, wenn ich falsch liege .


So, ich habe gestern die 2.4.7f drauf gemacht, vsels etwas runter gesetzt wie immer ( werde sie aber auf Stock zurueckstellen heut Abend oder morgen ) und bei 2 Telefonaten heute hatte ich im 10-Sekunden-Takt ein leises "tut" zu hoeren bekommen. So, als wuerde ein Anruf reinkommen und die Anklopfaktion macht Alarm.
Jedoch bekam ich bei beiden Telefonaten weder einen Anruf noch war irgend eine andere Aktion ersichtlich.
Hab in den Einstellungen geguckt und nichts neues gefunden, was das haette gewesen sein koennen?!

Zweite Frage: Standartgemaess habe ich gesehen ist bei mir der Haken bei "Record Calls" gesetzt. Muss ich beim Telefonat nun noch im Menu irgend was druecken, damit der aufgenommen wird oder passiert das nun bei jedem? Und wo werden die Dateien gespeichert?
Hatte leider noch keine Zeit selbst zu suchen und jetzt grad ist mein Handy Spielzeug der Kids .

 

[fipsy]

Sorry TeCci, ich hatte dein Posting irgendwie gar nicht gesehen. Seltsam!?

Okay, mir erschliesst sich zwar noch nicht, in welchem Format er mir das anzeigt, aber er tut da was. Sekuendlich aendern sich die Zahlen hinter 400Mhz und 600Mhz fast immer gleichzeitig, 800 auch ab und an obwohl ich nix im Hintergrund laufen habe und nur den Bildschirm anstarre :x

Es ändern sich aber nur die Prozentangaben, nicht die Laufzeiten! Ist doch logisch: Wenn die CPU auf 800 MHz läuft, nimmt der prozentuale Anteil hier zu, gleichzeitig muss aber der Anteil bei allen anderen Taktraten logischerweise abnehmen ;-).

In dieser Zeit hatte ich eine CPU Auslastung von Nahezu 0% und der Akku macht nen schoenen Abflug.

Ja, das sieht verdächtig nach einem Drain aus. Aber wieso hört dieser gegen 17 Uhr von alleine wieder auf? Was hast du denn da gemacht? Ohne Handy-Neustart hörte der Drain bei mir nämlich nicht wieder auf. Aber vielleicht hat dein Handy da ja rebootet ohne dass du es gemerkt hast?!

Vielleicht hilfts ja zur Fehlersuche, dass er bei mir jetzt praktisch durchs kurz aktivieren des Displays und nach 2 Sek wieder ausschalten ausgeloest wurde?

Wenn die Ursache tatsächlich dort liegt, wo ich sie derzeit vermute, kann Alles und Jedes diesen Drain auslösen. Kannst du mal einen Screenshot von CPUStats nach einem solchen Drain posten? Das ist aussagekräftiger für eine Bewertung.

Noch etwas Interessantes: Scheinbar hatte ich um kurz vor 5 einen reboot, jedenfalls sieht man ja, dass kurz das Wlan weg war.

Durchaus möglich. Erzeuge doch bitte mal ein Reboot-Script, indem du dir eine Scriptdatei mit folgendem Inhalt auf die SD-Karte legst und diese von SManager bei jedem Bootvorgang ausführen lässt:

#!/system/bin/sh

date >> /mnt/sdcard/.reboot.log

Dann hast du in .reboot.log eine Liste aller Neustarts. Nur so kannst du "verdeckte" Reboots identifizieren.

Der ursprüngliche Beitrag von 18:22 Uhr wurde um 18:56 Uhr ergänzt:

500 oder 550Mhz sollen am Effizientesten laufen, da auf dieser Stufe am wenigsten Strom im Vergleich zur Rechengeschwindigkeit verbraten wird. Wenn du halb so viel Strom verbrauchst pro Minute, aber anstatt 1 Minute dann 3 Minuten brauchst, um etwas zu berechnen, ist Rechenleistung/Stromverbrauch-faktor natuerlich bei dem hoeheren Wert effizienter.

Aber warum brauche ich bei 250 MHz für die selbe Aktion mehr als doppelt so lange wie bei 500 MHz? Das ist irgendwie nicht einleuchtend. Das würde ja heißen, dass ich für ein und dieselbe Aktion mal mehr und mal weniger Takte benötige!?

Für eine bestimmte Aktion benötige ich doch eigentlich immer eine bestimmte Anzahl von Taktzyklen. D.h. bei 250 MHz dauert diese Aktion genau doppelt so lange, wie bei 500 MHz. Wenn ich bei 500 MHz doppelt so viel Strom verbrauche, wie bei 250 MHz, wäre es also ein Nullsummenspiel. Aber es scheint ja anders zu sein: Bei 500 MHz benötigt der Prozessor für diese Aktion weniger Energie? Ist doch irgendwie seltsam. Aber wie du schon sagst: Wenn der Prozessor bei einer Aktion nicht voll ausgelastet wird, ist er zwischendurch vermutlich immer mal wieder "idle" (nicht mit "deep sleep" zu verwechseln!). Und solche "Idle-Takte" sollten bei 250 MHz weniger Energie verbrauchen als bei 500 MHz. Das passt alles nicht zusammen. Ich finde das immer noch unlogisch.

Du darfst nicht den Fehler machen und denken, dass vsel 30 halb so viel Strom verbraucht wie vsel 60

Nein, das war mir schon klar. Es gibt immer eine Offset-Spannung, die bei vsel=0 gilt.

und bei 2 Telefonaten heute hatte ich im 10-Sekunden-Takt ein leises "tut" zu hoeren bekommen. So, als wuerde ein Anruf reinkommen und die Anklopfaktion macht Alarm.

Hast du "call recording" eingeschaltet? Hört sich nach der Signalisierung für die Anfruf-Aufzeichnung an:

"the libaudio that allows beepless call recording has been made optional, because some users reported BP panics on incoming calls
-- you can enable it under Device settings > Experimental libaudio (the change requires reboot)"

Zweite Frage: Standartgemaess habe ich gesehen ist bei mir der Haken bei "Record Calls" gesetzt.

Das erklärt die Tuterei ;-).

Muss ich beim Telefonat nun noch im Menu irgend was druecken, damit der aufgenommen wird oder passiert das nun bei jedem? Und wo werden die Dateien gespeichert?

Ja, jeder Anruf wird dann automatisch aufgezeichnet in /sdcard/CallRecordings. Das steht aber auch bei dem Menüpunkt dabei .

 

[Loader009]

Ich kenne das aus der Microcontroller-Programmierung[...]

Ne kleine Annahme, wenn der Teiler für 550 MHz nicht klappt, würde es dann nicht auf 520/540/560/580 MHz klappen?
Entweder das oder es klappen nur 100ter Schritte.

 

[fipsy]

Ne kleine Annahme, wenn der Teiler für 550 MHz nicht klappt, würde es dann nicht auf 520/540/560/580 MHz klappen?
Entweder das oder es klappen nur 100ter Schritte.

Es war 650, was nicht klappt. 550 geht. Da man nicht genau weiß, welcher Teiler benutzt wird, kann man das nicht so ohne weiteres sagen. Man weiß zudem auch nicht, wie "Drift-Tolerant" der Modem ist.

 

[Loader009]

Verstehe... naja, da kann man tatsächlich nur raten.

Hab noch ne nette Theorie, allerdings hat sie nichts mit dem Problem zutun.
Würde ein bestimmter Takt nicht mit der "Handyfrequenz" interferieren?
Je nach Provider könnte doch dadurch der Empfang gestört werden -> Global System for Mobile Communications

 

[TeCci]

Durchaus möglich. Erzeuge doch bitte mal ein Reboot-Script, indem du dir eine Scriptdatei mit folgendem Inhalt auf die SD-Karte legst und diese von SManager bei jedem Bootvorgang ausführen lässt:

Code:
#!/system/bin/sh

date >> /mnt/sdcard/.reboot.log
Dann hast du in .reboot.log eine Liste aller Neustarts. Nur so kannst du "verdeckte" Reboots identifizieren.

Wenn du mir sagst wie genau ich dieses erzeuge also was fuer eine datei ich wo anlegen muss mach ich das gern

Screenshots sind uebrigens dabei :x

Der Drain hoerte durch den reboot vermutlich auf, da ich sonst keine andere Erklaerung dafuer habe, wieso Wlan fuer einen kurzen Moment aus war.


Zu der 250 vs 550Mhz Sache:
Wie gesagt, ist nur meine interpretation, WARUM das so ist, oder sein koennte, kann ich dir auch nicht erklaeren .

Ist Payce eigentlich noch in diesem Forum aktiv? Vill koennte eine PM helfen? Er ist schliesslich das Elektrotechnichgenie von uns

 

[fipsy]

Wenn du mir sagst wie genau ich dieses erzeuge also was fuer eine datei ich wo anlegen muss mach ich das gern

Wie du eine Datei von deinem Rechner auf die SD-Karte bekommst, weißt du sicher . Also legst du eine Datei an mit dem Inhalt

#!/system/bin/sh
 
date >> /mnt/sdcard/.reboot.log

und kopierst diese auf die SD-Karte. Du kannst die Datei natürlich auch mit jedem beliebigen Editor auf dem Handy selbst erstellen. Bei mir heißt sie 11reboot. Im SManager wählst du diese Datei aus, setzt bei ihr das Flag "Boot" und klickst auf "Speichern" und dann auf "Beenden" -> fertig.

Screenshots sind uebrigens dabei :x

Ich dachte eher an einen Screenshot von CPUStats.

Ist Payce eigentlich noch in diesem Forum aktiv?

Gute Frage. Ich bezog mich ja in meinem Wissen bis dato auch auf den wirklich außerordentlich guten Artikel von Payce, den jeder gelesen haben sollte: https://www.android-hilfe.de/forum/...os-ladekurven-leistungsverbraucher.73360.html. Dort steht zum Beispiel auch "Zur Taktfrequenz: Hier war lineares Verhalten zu erwarten und das bewahrheitet sich zum Glück auch.". Ich hoffe, nadlabak hat Payce deshalb nicht schon erschossen und wir hören nur deshalb nichts mehr von ihm .

Ich hatte den Inhalt dieses Postings einfach unreflektiert in meinen "Wissensschatz" übernommen, dann durch die Ereignisse der letzten Zeit jedoch mehr darüber nachgedacht. Da begannen sich plötzlich über einigen Erkenntnissen zunehmend Fragezeichen zu bilden. Payce sagt ja selbst, dass das Verhältnis zwischen Taktrate und Leistungsverbrauch quadratisch ist. Das belegt auch sein zweites Diagramm in dem zitierten Artikel. So kenne ich das selbst als E-Techniker auch von der Microcontroller-Technik her. Im dritten Diagramm stellt er dann aber den Leistungsverbrauch je Operation dar. Und da stimmt der Zusammenhang plötzlich nicht mehr. Er schreibt selbst von einem "verblüffenden Ergebnis" und dass er davon "überrascht" sei. Aber eine Erklärung liefert er leider nicht. Und ich hätte gerne eine plausible physikalisch/technische Erklärung dafür. Denn mir erscheint es einfach unlogisch .

Der entscheidende Absatz aus diesem Artikel ist dabei folgender:

Update: Nachdem ich ein paar mehr Stützpunkte aufgenommen habe, bin ich einmal hergegangen und habe zusätzlich geplottet, wie effizient der Stein bei bestimmten Taktfrequenzen arbeitet. D.h. ich teile den Leistungsverbrauch (bei angepasster vsel) durch die MHz und komme so auf einen Wert der entweder als mW pro MHz bzw. mWh pro Taktzyklus/Operationen interpretiert werden kann. Es bringt ja nichts, wenn underclockt/undervoltet wird, der Stein aber pro Rechenoperation trotzdem mehr Saft verbraucht. Anbei das verblüffende Ergebniss als Bild 3.
Fazit: Der Stein rennt unter Volllast offensichtlich am Effektivsten zwischen etwa 500 MHz und 900 MHz! Bitte Achtung bei der Interpretation: D.h. NICHT, dass ein underclocken auf 250 MHz keinen Sinn macht, da die Werte nur für die Volllast gelten! Aber man kann trotzdem festhalten, dass ein underclocken auf 125 MHz tatsächlich nicht viel ausrichtet! Das hat mich doch etwas überrascht, muss ich zugeben, aber die Zahlen sprechen hier recht klare Worte. Die gleiche Operation (bspw. ein jpg öffnen) verbraucht bei 125 MHz Taktung *MEHR* Akku als bei 250 MHz oder gar 500 MHz. D.h. bei Screen Off sollte die max. Taktung *NICHT* auf 250 MHz oder 125 MHz beschränkt werden, sondern ~ 500 MHz betragen (!). Erst wenn der Prozessor in Ruhe ist (idle) sollte auf 125/250 heruntergetaktet werden.

Im Grunde heißt das doch, dass Rechenoperationen bei 500 MHz weniger Energie verbrauchen, als bei 250 MHz, wohingegen Idleoperationen bei 500 MHz mehr Energie verbrauchen als bei 250 MHz. Ich finde das echt krass und es klingt für mich irgendwie mächtig unlogisch.

Der ursprüngliche Beitrag von 00:12 Uhr wurde um 00:25 Uhr ergänzt:

Würde ein bestimmter Takt nicht mit der "Handyfrequenz" interferieren?

Im Prinzip ja. GSM sendet bei 900 MHz (D-Netze) bzw. 1800 MHz (E-Netze). Die Aufgabe des Ingenieurs sollte nun darin liegen, das Sendeteil so gut vom Prozessor abzuschirmen, dass keine Interferenzen entstehen. Deshalb werden im Handy ja auch ordentlich EMV-Abschirmfolien verbaut. So ganz gelingt das nicht immer, es gab eine zeitlang Nokia-Handies, bei denen während des Telefonierens im Lautsprecher immer ein mächtiges GSM-Brummen zu hören war. Besonders extrem beim Nokia 6310i aber auch vorher schon ein Problem z.B. im 6150 und 7110. Aber mittlerweile ist das alles gut im Griff. Und ich glaube auch, dass selbst ein Prozessortakt von 900 MHz kein Problem wäre .

 

[TheSpiritof69]

Um auf den Punkt der höheren Taktung unter Volllast, die in niedrigerem Energieverbraucht resultiert mal folgendes, bekannt als race-to-idle:

Dynamic frequency scaling by itself is rarely worthwhile as a way to conserve switching power. Saving the most power requires dynamic voltage scaling too, because of the V2 component and the fact that modern CPUs are strongly optimized for low power idle states. In most constant-voltage cases it is more efficient to run briefly at peak speed and stay in a deep idle state for longer (called "race to idle"), than it is to run at a reduced clock rate for a long time and only stay briefly in a light idle state. However, reducing voltage along with clock rate can change those tradeoffs.

Kurz, wenn der Prozessor unter Volllast schneller mit seiner Aufgabe fertig ist und idlen kann, kann das auch bei höherer Taktung weniger Energie kosten als erledigen derselben Aufgabe mit geringerer Taktung, wurde glaube ich so schonmal kürzlich im Thread erwähnt..

 

[fipsy]

Kurz, wenn der Prozessor unter Volllast schneller mit seiner Aufgabe fertig ist und idlen kann, kann das auch bei höherer Taktung weniger Energie kosten als erledigen derselben Aufgabe mit geringerer Taktung, wurde glaube ich so schonmal kürzlich im Thread erwähnt..

Das ist ja auch das, was Payce bei seinen Messungen festgestellt hat. Nur hatten wir bisher keine einleuchtende Erklärung für dieses Phänomen erhalten.

Wenn ich den von dir zitierten Artikel richtig verstehe, liegt die Erklärung in dem Unterschied zwischen dem Stromverbrauch im 'deep idle state' und dem im 'light idle state', sofern die CPU beide states unterstützt, was beim Milestone offenbar der Fall ist. Ich nehme an, der deep idle wird automatisch aktiviert, wenn die CPU sich für längere Zeit im light idle befunden hat. Es ist daher also günstiger, die CPU bei hohem Takt länger in den Idle-Zustand zu legen, als sie bei niedrigem Takt kürzer in diesen Zustand zu versetzen, weil im ersten Fall zwar kurzzeitig viel Energie verbraucht wird, sich die CPU dafür aber hinterher lange bei extrem wenig Energie im deep idle ausruhen kann. Und das ist bei niedriger Taktrate nicht möglich. Da hängt die CPU meist nur im light idle, der deutlich mehr Energie verbraucht als der deep idle.

WOW, echt krass! Wieder richtig geil was dazu gelernt!

Das heißt aber auch: Wenn die CPU keine unterschiedlichen Idle-States kennt, sondern nur einen einzigen, gilt diese Regel nicht. Denn im Microcontroller-Bereich gibt es i.d.R. keine unterschiedlichen Idle-States, weshalb mir diese Sache bisher unbekannt war.

 

[TheSpiritof69]

Ich wüsste nicht, bzw. würde nicht behaupten, dass "deep idle" bzw "light idle" absolute CPU states sind, hab das eher verstanden als bspw. "deep idle = Leerlauftakt von 125 Mhz und light idle = Spartakt von 250 MhZ" gegenüber Volllast von 550Mhz.

 

[nadlabak]

Ich nehme an, der deep idle wird automatisch aktiviert, wenn die CPU sich für längere Zeit im light idle befunden hat.

No, when the screen is off, the device wants to go to deep sleep (clocks off) immediately at any given moment. Only wakelocks prevent it. When all processes that held the wakelocks finish their work and wakelocks are released, the device enters deep sleep and clocks are stopped (till the next wake-up by interrupts or scheduled wake alarm). If you prevent quick release of wakelocks by forcing the CPU to crawl at very low frequency, you're actually not helping your battery life.

Also, the 'deep idle state' and 'light idle state' from the mentioned article mean the same thing - deep idle state that is light on the battery...

Der ursprüngliche Beitrag von 13:40 Uhr wurde um 14:20 Uhr ergänzt:

Btw., I've managed to fix the smartreflex when overclock is used, so the effective vsel in use won't be necessarily the one written by the overclock script. This will prevent too big undervolting or overvolting - the ideal vsel for a given frequency on a particular device will be automatically determined and continuously adjusted by the smartreflex technology.

 

[fipsy]

If you prevent quick release of wakelocks by forcing the CPU to crawl at very low frequency, you're actually not helping your battery life.

So deep sleep is entered only when screen is off and wakelocks are released?! And because deep sleep consumes nearly no energy it's always better to quickly finish work at high frequencies (even if it needs more energy) and then enter deep sleep as long as possible? This means "deep sleep" and "idle" are the same?! I always thought these were different modes on the device.

Also, the 'deep idle state' and 'light idle state' from the mentioned article mean the same thing - deep idle state that is light on the battery...

So that article is quite mistakable.

Btw., I've managed to fix the smartreflex when overclock is used

But smartreflex is not implemented in 7.2.4f, isn't it? I would appreciate that smartreflex could be enabled/disabled by choice.

As I supposed the "insanely low" vsel values were NOT responsible for my problems with 'frequency stuck' and 'battery drain'! It was only the 150 MHz frequency I used. For testing I got back to these 'insanely low' vsel values, banned the 150 MHz and converted it to 125 MHz. And now the device is running for 48 hours without any problems!

So there really are forbidden frequencies on the milestone that cause the device to fail and also cause frequent modem errors! Independent from the chosen vsel. 150 MHz and 650 MHz belong to these forbidden frequencies.

 

[hellfire]

@fipsy: Könntest du deine oc-Werte mal posten? Mit denen scheint es bis jetzt ja sehr gut zu laufen.

 

[nadlabak]

So deep sleep is entered only when screen is off and wakelocks are released?! And because deep sleep consumes nearly no energy it's always better to quickly finish work at high frequencies (even if it needs more energy) and then enter deep sleep as long as possible? This means "deep sleep" and "idle" are the same?! I always thought these were different modes on the device.



So that article is quite mistakable.



But smartreflex is not implemented in 7.2.4f, isn't it? I would appreciate that smartreflex could be enabled/disabled by choice.

As I supposed the "insanely low" vsel values were NOT responsible for my problems with 'frequency stuck' and 'battery drain'! It was only the 150 MHz frequency I used. For testing I got back to these 'insanely low' vsel values, banned the 150 MHz and converted it to 125 MHz. And now the device is running for 48 hours without any problems!

So there really are forbidden frequencies on the milestone that cause the device to fail and also cause frequent modem errors! Independent from the chosen vsel. 150 MHz and 650 MHz belong to these forbidden frequencies.

That article seems to be pretty clear and simple to me.

The power management topic is indeed very complex and there are many levels of it that could be discussed. But I'm not sure what exact depth of talk here could be actually productive. So I'll rather skip the talk and I'll better focus on the actual work I'm able to do.

The smartreflex works just fine in all the so far released CM builds for Milestone, but only until the /proc/overclock interface is used.

The overclock/smartreflex bug has been fixed now, so it won't be an issue in the future builds...

Obviously, I wouldn't bother to warn you about the dangers of using too low vsel values if the overclock interface would be fool proofed by the smartrelex in the past builds...

If you've encountered issues while using frequencies solely invented by you, then I'm indeed feeling sorry for you. But... what have you expected?