[KERNEL][CM7/MIUI/CM9] Platypus;SECURITY,VOODOO,OC/UV

[Bodo]

Jetzt kommt die These mit dem "guten" Linux Speichermanagement.

Fakt ist, das voller Speicher Strom kostet, Anwendungen unnötig laufen, damit cpu last verursachen und somit wieder strom verbraucht. Dazu kommt noch, wenn man ein Programm startet, das dann erst Speicher frei gemacht werden muss. Was wieder cpu last erfordert, Strom verbraucht und unnütz Zeit dauert.

Ich will nicht das irgendwelche Sachen, die ich beendet habe, weiter laufen. Deswegen habe ich sie beendet und nicht in den Hintergrund verschoben.

Wenn die Speicherverwaltung so gut wäre, bräuchte man da nicht ewig frickeln, damit es vernünftig läuft.

 

[DerTeufel]

aber welche app braucht denn zum starten 100+x mb freien speicher?
dein argument mit dem stromverbrauch kann ich nicht widerlegen (ob speichern im ram wirklich strom verbraucht... keine ahnung). auf jeden fall hilft dir aber das superchargerscript auch nicht dabei programme die du beendet hast direkt aus dem speicher zu werfen, da erstmal andere sachen rausgeworfen werden.
ich für meinen teil werde mal nachsehen, inwiefern das script dazu beiträgt, dass der launcher nicht so schnell geschlossen wird, und das dann händisch vornehmen.

 

[Deepthrow]

mir is ehrlich gesagt was das script macht bei mir läuft es sehr gut und besser als ohne. ihr macht euch gedanken...

 

[extralife]

ihr macht euch gedanken...

... dachte ich mir auch gerade

... using tapatalk

 

[domy1985]

Werden alle Kernel aettings gelöscht wenn ich die nightly neue aufspielen oder brauche ich den cleaning script

Sent from my GT-I9000 using Tapatalk

 

[zacharias]

@domy1985:

am besten ein Cleaning-Skript, das die Skripte entfernt und auch evtl. Voltage-Control-Einstellungen löscht verwenden sonst könnte es Probleme geben


@DerTeufel:

ist korrekt die Werte werden nicht in die frequency_voltage_table eingetragen - liegt an der initialen Implementierung von Glitch, die ich portiert hatte

ich hatte das die ganze Zeit nicht korrigiert bzw. verändert, da mir anfangs die Erfahrung fehlte

und jetzt, wenn ich das machen könnte - fehlt mir die Zeit (ich mache das lieber langsam & gründlich und lese mich in die Materie etwas ein bzw. recherchiere dafür, dass ich richtig verstehe, wie das funktioniert und dabei nichts zu Schaden kommt)


falls jemand Zeit und Lust hat am Kernel mit zu helfen,

kann er sich das anschauen und die fehlenden Teile dazu beitragen:

1.6 GHz OC/UV Implementierung


und im Folgenden die Implementierung mit 1.3 GHz und (wohl) funktionierender frequency_voltage_table, die in ähnlicher Weise auch im stock cm7 kernel eingesetzt wird, meine Umsetzung beinhaltet noch einen Übertaktungsschutz, dass die Hardware nicht zu arg gestresst wird

 

[das Neutrum]

Also bringt UV quasi nichts? Oder wie ist das fehlende übertragen der Voltages zu verstehen?

Gesendet mit der Android-Hilfe.de-App

 

[DerTeufel]

das bewirkt, dass die cpu einfach von deinen einstellungen nichts mitbekommt und mit den standardspannungen läuft

 

[gantroxx]

Also wenn ich uv einstelle freetzt das Phone bei zu niedrigen settings - also werden die uv settings wohl auch funktionieren oder?

Noch was anderes: Geht bei euch der normale neustart? Bei mir bleibt das SGS schwarz und es passiert nichts. Muss immer zunächst herunterfahren und neu anschalten damit es funktioniert!

 

[DerTeufel]

es steht doch jetzt schon fest, dass undervolting nicht funktioniert.
vielleicht nutzt du ein tool, dass die werte anders setzt als voltage control. welches hast du?
neustarts funktionieren.
@zach: ich kenne mich mit der materie nicht weiter aus. nach was muss man denn bei den verlinkten seiten überhaupt erstmal schauen, damit man gucken kann, wo die unterschiede sind

edit:

Also wenn ich uv einstelle freetzt das Phone bei zu niedrigen settings - also werden die uv settings wohl auch funktionieren oder?

ok. das ist in der tat komisch. nach der aussage von zach ging ich davon aus, dass die werte tatsächlich nicht an die cpu weitergereicht werden. ich habe jetzt aber auch nochmal probiert, was passiert wenn ich die spannung zu weit senke, und tatsächlich habe auch ich dann freezes und reboots bekommen. dies ist natürlich ein deutliches indiz dafür, dass es doch funktioniert.
die frage die sich mir da jetzt stellt ist: wie?

 

[fetteente]

BT Problem:
ich stell das mal hier rein, da es möglicherweise ein kernelproblem ist.
Habe Boogies 3.1 drauf, das Problem sowohl mit neo 15 als auch neo17 und ja ich habe sauber geflasht.
BT ist bei mir immer an. Koppelt das SGS ans Autoradio, ist der Akkuverbrauch naturgemäß höher. Verlasse ich das Auto und ist BT getrennt, normalisiert sich der Akkuverbrauch. Aber nicht immer. Es scheint da eine sporadische Hakelei zu geben (wurde von einem anderen User auch bestätigt). Gelegentlich koppelt das SGS nicht automatisch, muss dann manuell koppeln. Wenn ich in solchen Fällen den BT Bereich verlasse, normalisiert sich der Akkuverbrauch nicht, dann hilft nur noch Neustart. Vielleicht können die User, die das SGS auch so nutzen, das mal testen.
Was mir aufgefallen ist: der accelerator sensor ist in diesem Fall permanent an.
Evtl. fällt Zach dazu etwas ein.
Es ist nicht so dramatisch, aber lästig, weil man jedesmal daran denken muss, auf den Akku zu sehen.

Ein ähnliches Problem besteht mit googlemaps. Nach Beenden der app geht der Akkuverbrauch mehr runter als sonst, der accelerator sensor bleibt an, hilft nur Neustart.

Grüße an die Flashergemeinde und: Miui ist wirklich das beste ROM, was ich bisher getestet habe.

 

[SGSundIch]

Ein ähnliches Problem besteht mit googlemaps. Nach Beenden der app geht der Akkuverbrauch mehr runter als sonst, der accelerator sensor bleibt an, hilft nur Neustart.

Das kann ich bestätigen! Ist bei mir NEO 17 r5 auch so. Allerdings habe ich das Gefühl, dass es auch nicht immer passiert und auch bei Kompass und Wasserwaage Apps auftritt (benutzen ja auch accelerator sensor) .

 

[Queens23]

BT Problem:
ich stell das mal hier rein, da es möglicherweise ein kernelproblem ist.
Habe Boogies 3.1 drauf, das Problem sowohl mit neo 15 als auch neo17 und ja ich habe sauber geflasht.
BT ist bei mir immer an. Koppelt das SGS ans Autoradio, ist der Akkuverbrauch naturgemäß höher. Verlasse ich das Auto und ist BT getrennt, normalisiert sich der Akkuverbrauch. Aber nicht immer. Es scheint da eine sporadische Hakelei zu geben (wurde von einem anderen User auch bestätigt). Gelegentlich koppelt das SGS nicht automatisch, muss dann manuell koppeln. Wenn ich in solchen Fällen den BT Bereich verlasse, normalisiert sich der Akkuverbrauch nicht, dann hilft nur noch Neustart. Vielleicht können die User, die das SGS auch so nutzen, das mal testen.
Was mir aufgefallen ist: der accelerator sensor ist in diesem Fall permanent an.
Evtl. fällt Zach dazu etwas ein.
Es ist nicht so dramatisch, aber lästig, weil man jedesmal daran denken muss, auf den Akku zu sehen.

Ein ähnliches Problem besteht mit googlemaps. Nach Beenden der app geht der Akkuverbrauch mehr runter als sonst, der accelerator sensor bleibt an, hilft nur Neustart.

Grüße an die Flashergemeinde und: Miui ist wirklich das beste ROM, was ich bisher getestet habe.

Habe das selbe Problem mit dem Accelerometer Sensor!
Aber in meinem Fall ist wahrscheinlich "Google Suche" das Problem. Diese Nacht in 8 Stunden nur 2% Verbrauch gehabt, dann gegen Mittag nur ein paar mal "Goolge Suche"-App genutzt und dann innerhalb von 4 Stunden 30% Verbrauch gehabt....

Der Sensor ist, nach dem ich die App genutzt habe, immer aktiv geblieben obwohl ich das Handy kaum genutzt habe. Nach einem Neustart läuft alles wieder Normal.

Weiß jemand was da schief läuft??

 

[OL-Langer]

Benutzt eine alte maps Version und gut ist.

Sent from my GT-I9000 using Tapatalk

 

[Queens23]

Benutzt eine alte maps Version und gut ist.

Sent from my GT-I9000 using Tapatalk

Was gibts du denn hier für unnötige kommentare von dir?!
Anscheinend liegt es nicht nur an Google Maps und anscheinend mcöhten hier leute das Problem lösen!

Bevor man so unnötige antworten schreibt, am besten garnihct schreiben

 

[Deepthrow]

Was gibts du denn hier für unnötige kommentare von dir?!
Anscheinend liegt es nicht nur an Google Maps und anscheinend mcöhten hier leute das Problem lösen!

Bevor man so unnötige antworten schreibt, am besten garnihct schreiben

digga, merkst du was?

genau so überflüssig dein post!

"jaaaa meiner nu auch"

Sent from my GT-I9000 using Tapatalk

 

[DerTeufel]

@zach oder wer es sonst so weiß:
ist in dem kernel (neo 17r7) ein tweak für das touchscreen eingebaut?
ich habe das gefühl, dass es "weicher" reagiert, als z.b mit dem glitch kernel.

und müsste sich logcat nicht deaktivieren lassen, wenn ich das logger script aus der init.d lösche bzw den befehl darin auskommentiere? bei mir läuft es nämlich trotzdem noch. wird das modul durch den kernel auch geladen, und das script in der init.d ist nur ein altes überbleibsel?

welchen grund gibt es eigentlich hierfür?

1. • BFQ as default i/o scheduler (in script)
2. • noop should be default without scripts [via kernel]

 

[OL-Langer]

Naja ich weis nicht was daran unnötig war. Tatsache ist das ich das Problem damit gelöst habe.



Sent from my GT-I9000 using Tapatalk

 

[zacharias]

@DerTeufel:

ja, accidental touchkey prevention, ist im stock cm7 kernel auch drin - ein port from stock samsung kernel

logcat ist jetzt standardmäßig aktiviert, da mehr und mehr entwickler den kernel einsetzen und das benötigen - weiters hilft es bei der fehlersuche & braucht unerheblich mehr Akku

also ist das logger script ein altes überbleibsel und somit quasi in Rente


noop führte zu Problemen und Daten-Korruption (lost.dir)

jetzt ist cfq im kernel wieder standard & bfq festgelegt,

wenn du bfq nicht magst, kannst du das im S98system_tweak script umstellen


zum Undervolten:

ich undervolte seit einiger Zeit die CPU nicht mehr, da ohnehin RAM, ADC und LCD undervoltet sind und mir in der Vergangenheit cpu-undervolting nicht sehr viel gebracht hat


wenn es läuft ok - wenn nicht: ich kann mich frühestens ab Oktober darum kümmern, für größere Dinge habe ich jetzt leider keine Zeit; ich hab jetzt einfach andere, wichtigere Sachen im Kopf & zu tun

 

[DerTeufel]

liegt es eigentlich am cyanogenmod, oder am kernel, dass zram noch nicht unterstützt wird? in deinem script steht die option ja bereits auskommentiert zur verfügung.

gegen bfq hab ich nichts einzuwenden. hatte mich nur gewundert, warum einmal dies und einmal das als standard verwendet wird/wurde.

und kann es denn sein, dass undervolting funktioniert, auch wenn die werte nicht in den frequency_voltage_table übernommen werden? oder funktionieren die vielleicht auch nur, wenn sie gerade direkt gesetzt werden (kenne die genaue routine von voltage control und deinem kernel ja nicht), und nach einem neustart z.b nicht?