Beiträge von hellsgod

CM9 wird schlussendlich sterben, da jedes Gerät welches auf CM9 läuft auf CM10 aktualisiert werden wird. CM9 ist dann somit sinnlos.

hells

[video]

[video]

[video]

[video]

Have Fun!

hells

Wenn, dann brauchst du ein Team dafür. Leute die das Rom machen, Leute die Support geben, Leute die das Rom auf Herz und Nieren testen... Schau dir galnet an, der hatte auch ein Team, doch wie oft hat er das Handtuch geschmissen...? Jetzt macht er nur noch Roms fürs S3, das S2 kommt glaub ich auch bald dazu, viel mehr aber nicht.

Es kostet Zeit und Nerven. Hast du genug davon, dann zieh es durch

hells

Guten Tag liebe Forengemeinde,

Wer kennt es nicht, das Telefon liegt rum aber die Prozente purzeln und purzeln... Die Ursache(n) ist/sind nicht immer klar ersichtlich. Wo fängt man also an zu suchen?

Geht das Gerät in den Deep Sleep?

Ladet euch CPU Spy aus dem Market, startet es, setzt die Werte zurück und lasst das Tel mal eine Stunde oder so nur rumliegen. Schläft das Tel ordentlich ist die Ursache für den Drain eine andere. Schläft es nicht gut, gibt es da eine oder mehrere Apps die es immer wieder Wachrütteln.

Welche Apps / Prozesse rauben dem Gerät den Schlaf?

Ladet euch Better Battery Stats von xda runter und installiert es. Link hier: Tweaks / Parameter für Govenors Dann könnt ihr entweder über Menütaste/More/Set Custom Ref. einen neuen Punkt setzten, dann Display aus und es liegen lassen, oder ihr geht in die Einstellungen/Watchdog Settings und schaltet Screen Off ein, schaltet das Display aus und lasst es liegen. Wenn ihr das Display dann wieder einschaltet und BBS öffnet, schaut mal unter Partial Wakelogs, Kernel Wakelog und Alarms was denn so alles euer Gerät aus dem Schlaf gerissen hat.

Nutzt das Telefon dann mal einen Tag lang ganz normal. Schaut aber immer wieder unter Other wie es bei Awake und Screen On aussieht. Da lässt sich relativ schnell erkennen, ob das Gerät gut schläft

Schläft das Gerät ordentlich und hat kaum Wakelogs, dann kann es auch am Modem liegen, oder der Kernel saugt einfach zu viel im Standby. Im schlimmsten Falle einfach mal Wipen und Rom neu flashen. Das kann manchmal auch helfen.

hells

Guten Tag liebe Forengemeinde,

UV wird immer beliebter, doch den meisten Usern ist nicht bekannt, wie der CPU Verbrauch errechnet wird. Es wird davon ausgegangen, dass wenn man der CPU bei 500mhz gleich viel Saft gibt wie bei 200mhz, dass die CPU dann bei 500mhz genau gleich viel saugt. Das stimmt NICHT! Der Verbrauch wird folgendermassen errechnet:

P = f*c*V^2*

P=power
f=frequency
c=capacitance
V=voltage

Das heisst also, dass die Frequenz an sich auch eine Rolle spielt.

Zum Thema UC:

Je niedriger die max Freq, desto weniger Verbrauch, so die Theorie. Nun aber zu den Fakten:

Current processors are quite good about saving power when idle; so much so that many show a behavior around power saving that surprises many people.This behavior, called race-to-idle, is best explained with a simplified example:Lets take a typical commercially available processor that consumes 34 Watts when running at full speed, and 24 Watts when running at half speed and 1 Watts when idle (using frequency and voltage scaling using P-states).On this processor, we're decoding one second of a MP3 file or some HDTV media every second. This decoding takes 0.5 seconds at half speed, and, consequently, 0.25 seconds at full speed.The energy consumption for one second isHalf speed: 0.5s * 24W + 0.5s * 1W = 12.5 JoulesFull speed: 0.25s * 34W + 0.75s * 1W = 9.25 JoulesEven
though the above example is simplified from reality, the same paradigm tends to hold for real systems: It's generally better to run as fast as you can so that you can be idle longer.

Kurz gesagt:

Wenn die CPU auf max 800mhz läuft, kann es sein, dass sie länger auf diesem Takt verbringen muss, als wenn die CPU auf 1400 läuft. Das kann also dazu führen, dass die CPU im Endeffekt mehr Strom verbratet.

Überlegt euch also gut was ihr macht.

QUELLE: Eigenerfahrung und Siyah Thread bei xda.

hells

Guten Tag liebe Forengemeinde,

Beim Galaxy S3 wurde ein neuer Govenor hinzugefügt, der pegasusq. Hier versuche ich zu erläutern, wie man das "Biest" etwas zähmen kann. Gökhan hat ihn bereits auf das S2 portiert, und daher kennen ihn vielleicht einige schon. Nun, wie verändere ich dessen Parameter, und was bedeuten sie? Ich habe hier einige der Punkte Sinngemäss übersetzt, um es auch Usern die mit der Englischen Sprache etwas Mühe haben zugänglich zu machen. Bin aber für Vorschläge, Tipps oder Anregungen offen.

FAQ - Govenors u. Sheduler
Tweaks / Parameter für Govenors

sampling_rate: (wie oft die CPU abgefragt wird, um zu entscheiden ob hoch -oder runter skaliert wird)

up_threshold: (% Auslastung ab der hoch skaliert wird)

sampling_down_factor: (Dient als Multiplikator des "sampling_rate" Wertes, um zu entscheiden wie schnell nach Neuberechnung der aktuellen Auslastung bei Vollast runter skaliert wird. "1" bedeutet "sampling_rate = "sampling_down_factor", jede andere Zahl multipliziert die 500000 mikrosekunden. Dieser Wert gilt nur für die oberen Frequenzen, oder hoher Auslastung. Beachte dass die CPU automatisch auf "max frequency" skaliert, wenn "max_load_freq" grösser ist als "up_threshold" x "current frequency". "max_load_freq" ist ein willkürlicher Wert, der aus "maximum of load_frequencies" berechnet wird. "load_frequency" ist auch ein willkürlicher Wert, welcher die Frequenz beschreibt, bei der das Gerät theoretisch mit 100% Auslastung umgehen kann, errechnet aus "load" x "average_frequency" (Durchschnitts-Frequenz))

ignore_nice_load: (0) (Auf "1" werden "low-level prozesse" beim skalierien ignoriert)

io_is_busy: 0() (bei "1" werden ressourcenintensive Anwendungen durch den Sheduler etwas anders behandelt)

down_differential: (5) (Nachdem die Zeit von "sampling_rate* x "sampling_down_factor" verstrichen ist, wird Versucht eine niedrigere Frequenz zu wählen, welche aber nicht den "up_threshold"
(85%) bei der nächsten Abfrage auslösen wird. Das "down_differential" ist auch dazu da, dass nicht zu schnell herunterskaliert wird. Gerechnetwird Folgendermassen: "Max_load_freq" (bei mir 1400mhz) wird gegen (up_threshold - down_differential) x "current frequency" (aktuelle Frequenz) gerechnet)

freq_step: (40) (Definiert um wieviel Prozent der "max_frequency" hochskaliert werden soll, wenn die Auslastung den "up_threshold" erreicht. Der Wert entspricht "40" = 1400mhz/100x40 =
560mhz. Das heisst, wenn bei 200mhz die 85% erreicht werden, skaliert die CPU 560mhz hoch, gerundet auf 100 = 600mhz = 800mhz entspricht dann der nächsten Frequenz. Hier können Akkufreaks natürlich rumspielen und schauen ab wann es zu Lags kommt)

cpu_up_rate: (Anzahl der Abfragen um die Auslastung beim hoch skalieren zu berechnen. Sobald die Abfragen für eine Frequenz ausgeführt wurden, wird die "scale-up logic ausgeführt. Bevor die CPU hoch skaliert wird, bleibt die CPU auf "cpu_up_rate" x "sampling_rate" in Mikrosekunden auf der jeweiligen Frequenz)

cpu_down_rate: (Anzahl der Abfragen um die Auslastung beim runter skalieren zu berechnen. Sobald die Abfragen für eine Frequenz ausgeführt wurden, wird die "scale-down logic" ausgeführt.
Bevor also runter skaliert wird, bleibt die CPU auf "cpu_down_rate" x "sampling_rate" in Mikrosekunden auf der jeweiligen Frequenz)

cpu_up_freq: (Nicht ganz schlüssig, führt aber dazu, dass 300mhz und 400mhz nicht genutzt werden)

cpu_down_freq: (Nicht ganz schlüssig, hat aber etwas mit der min_freq zu tun)

up_nr_cpus: (Wie viele CPUs mindestens im Einsatz sind, und bei der Entscheidung des Hot Pluggings berücksichtigs wird)

max_cpu_lock:

hotplug_lock:

dvfs_debug: (Kernel debugging aus "0" an "1")

hotplug_freq 1 1: (zuschalten des nächsten Kernes beim hoch skalieren)

hotplug_freq 2 0: (abschalten des Kernes beim runter skalieren)

hotplug_freq 2 1: (wie 1 1)

hotplug_freq 3 0: (wie 2 0)

hotplug_freq 3 1: (wie 1 1)

hotplug_freq 3 0: (wie 2 0)

hotplug_rq 1 1: (Schwellenwert für die Lauflänge der Warteschlange bis der nächste Kern beim hoch skalieren zugeschaltet wird)

hotplug_rq 2 0: (Schwellenwert für die Lauflänge der Warteschlange bis der nächste Kern beim runter skalieren ausgeschaltet wird)

hotplug_rq 2 1: (wie 1 1)

hotplug_rq 3 0: (wie 2 0)

hotplug_rq 3 1: (wie 1 1)

hotplug_rq 4 0: (wie 2 0)

up_threshold_at_min_freq: (Schwellenwert der mit freq_of_responsiveness zusammenarbeitet, d.h bei Mindestfrequenz bis zur freq_of_responsiveness (500mhz z.B.) wird ab diesem threshold hoch
skaliert. Danach wird der obere up_threshold genutzt)

freq_for_responsiveness: (Bis zu dieser Frequenz wird der up_threshold_at_min_freq als Trigger genutzt. Danach löst der up_threshold den Trigger zum hoch skalieren aus .Diese Frequenz wird
auch dazu genutzt, um der CPU beim runter skalieren zu helfen die beste Frequenz zu finden. Eine, die beim nächsten Abfragen den "up_threshold" nicht sofort wieder auslöst.

[DLMURL]http://forum.xda-developers.com/show...03&postcount=3[/DLMURL] <------ QUELLE

Höhere Werte bei den "hotplug_freq" führen dazu, dass die Kerne erst ab "Wert" der kH (500000 = 500mhz) beim hoch skalieren zugeschalten (hotplug_freq 1 1, 2 1, 3 1) und beim runter skalieren wieder ausgeschalten werden (hotplug_freq 2 0, 3 0, 4 0)

Höhere Werte bei "hotplug_rq" führen dazu, dass die Kerne erst ab "Wert"der Warteschlange beim hoch skalieren zugeschalten (hotplug_rq 1 1, 2 1, 3 1), und beim runter skalieren wieder ausgeschalten werden (hotplug_rq 2 0, 3 0, 4 0)

Experimentiert selber etwas damit rum, und nutzt um es zu beobachten die App "Cool Tool". Vergesst nicht unter "Advanced" die "Multicore CPU Gauge" einzuschalten.

hells

Guten Abend,

Ich bins, der hells :hello:

Der eine oder andere wird mich von MIUI Germany oder AH kennen. Wenn nicht, auch egal. Habt nichts verpasst :bääh:

Gruss,
hells