[KERNEL][JB][JSS15J / JWR66V / CM] hells-Core b41 [28/11/2013]

[ocp11]

der b26 läuft ohne probleme.

simple gov hat bei mir mit stock keine probleme gemacht.

 

[bugz]

Wie bereits bugz schon mal gesagt, versuche an den load Werten rumzuspielen:

echo "80 40 25 50" > /sys/devices/virtual/misc/mako_hotplug/load_levels

Sind die standardwerte. Spiel damit rum und schau obs besser wird.

hells

Habe jetzt mal ein paar andere Sceduler probiert und das hat auch schon einiges an Auswirkung. Der fiops scheint gar nicht der beste zu sein... Dachte halt weil er für Flashspeicher ausgelegt ist, dass es Sinn macht.

 

[vetzki]

ich fahr eigentlich mit cfq am besten (bzw. merk da nicht soo die unterschiede)

 

[bugz]

Mh und was für eine Buffergröße wäre sinnvoll? Hatte immer 2048, aber was ist besser viel oder weniger ist mehr?

 

[blue8]

Die Puffergröße ist meines Wissens nach eine Balance zwischen vielen Daten, die vorgeladen werden (große Größe, dafür mehr CPU Overhead) und weniger Daten, dafür isses halt akkusparender. So ganz dahintergestiegen bin ich auch noch nicht. Fahre mit 512 gut. Hells, kannst du etwas dazu sagen?

Danke!

Gesendet von meinem Nexus 4 mit der Android-Hilfe.de App

 

[Nexus4ever]

Muss echt feststellen das er b26 um einiges flüssiger läuft als der b25
Wenn jetzt noch die Akkulaufzeit stimmt :thumpsup:

 

[bandit1976]

Ich habe eine Buffergröße von 1024 eingestellt und fahre gut damit.
Bin auch der Meinung, dass der 26 besser läuft als der 25, die Akkuzeit ist gefühlt auch besser und auch die Hitzeentwicklung ist bei mir wieder im normalen Bereich.

Hells, wie immer sehr gute Arbeit, danke dafür...

 

[bugz]

Ich könnte mir nur vorstellen, dass in einem kleinen Puffer die Daten viel schneller verarbeitet werden müssen, daher fühlt es sich vielleicht schneller an mit wenig Puffer. Also schneller voll und somit auch schnell wieder leer...

Probiere mal 128!

 

[rusak2]

128 ist Linux Standard. Zuviel Read Ahead Cache ist auch nicht gut. Das System liest dann zuviel im Voraus obwohl man es vllt. gar nicht nötig hat. Dieses Lesen kostet dann Rechenpower. Es könnten auch andere Operationen dadurch ausgebremst werden, was zu einer Verlangsamung des Systems führen könnten.
Vllt. wenn man viele große Dateien auf der Storage hat, bringt eine größere Cache etwas mehr Speed. Bei vielen kleinen Dateien ist es eher zum Nachteil würde ich sagen.

PS: Mein LG Optimus Speed damals lief mit 128 Cache am flüssigsten.

 

[papn2]

ich weiss nicht ob es am kernel liegt jedoch hatte ich jetzt 2 mal einen netzwerk crash.half nur noch ein neustart
flugmodus aus ein brachte auch nix
bin erstmal auf b25 zurück

 

[hellsgod]

Komisch dass diese Mikroruckler beim Simple nur mir auffallen... Der Simple Governor nach faux wurde so konstruiert, dass er bei wenig Belastung nicht so viel Springt und bei etwas höherer Belastung dann so "Peak" mässig nach Oben springt. Zu 100% genau sagen was sich faux genau dabei gedacht habe, kann ich auch nicht. Gut finde ich jedenfalls, dass bei der faux Implementierung zwei Werte geändert werden können. Nach franco nur noch einer.

Ich setze bei den Schedulern auf ROW, da wir wie der Name "Read over Write" mehr mit Leseoperationen zutun haben und diese eine höhere Priorität bekommen, was den Lesedurchsatz ziemlich nach Oben schraubt. Beim Readahead bin ich schon beim S3 gut mit 1024 Pages = 512kb gefahren. Einige sagen, dass man dem fiops sogar 2048 Pages = 1024kb = 1MB geben soll. Es kann jeder mit diesen Werten experimentieren

hells

 

[Samstag494]

Hab jetzt mal mit trickster im simple governor den threshold wert von 5500 oder auf was der stand auf 2500 gesetzt. Jetzt geht meine gpu endlich mal unter 400mhz, ruckler konnte ich noch keine beobachten.

Gesendet von meinem Nexus 4

 

[bugz]

Also den Gefühl nach würde ich jetzt sagen row 128 besser als 1024 und fiops 2048. Cfq mit 128 fand ich auch schon smoother als fiops 2048.

 

[rauke]

Meine GPU läuft seit FAUX diese Option eingebaut hat auf 200MHz Max. Ich hatte nie irgendwelche Ruckler. Die GPU scheint kräftig genug zu sein für so bisschen Pixelschieben.

 

[hellsgod]

Wenn ich die GPU auf 200mhz beschränke, sehe ich deutliche Ruckler... Ich packs langsam nicht mehr

hells

 

[ocp11]

bei welchen apps siehst du den die ruckler?

 

[hellsgod]

Unter PA ruckeln die Fensteranimationen gaaanz leicht. Fällt kaum auf. Unter MIUI gibts beim öffnen von Ordnern manchmal Ruckler, welche bei Ondemand kaum bis gar nicht auftreten. Wirklich markant ist es beim öffnen von CPU Spy Plus, allerdings nur unter MIUI. Dort ruckelt es manchmal etwas und manchmal sehr stark bei der "Öffnungsanimation", das nur beim Simple. Ondemand ist flüssig. Am threshold vom Simple hab ich bereits rumgespielt, bringt nix. Die Wärme und der Verbrauch vom Ondemand sind aber zwei Argumente, die es mir sehr schwer machen...

hells

 

[rusak2]

Portierte MIUI Rom als Referenz für das Mehr oder Weniger an Ruckeln zu verwenden ist aber auch etwas unpassend meiner Meinung nach, oder? ))

 

[hellsgod]

Wieso? Mit ondemand als GPU Gov ruckelts ja nicht

Egal, ich hab mich entschieden, ab der nächsten Version ist der Simple wieder standard. Sorry für das Hin und Her ^^

hells

 

[Fabipro]

b26 hells: Hyper Governor (max.1240000), Scheduler row, GPU ondemand (max. 400)

Lief den ganzen Tag über unter 2/3G + WLAN reibunglos, flüssig, ohne Abstürze oder Signalverluste etc. pp.

Kann jetzt keinen Unterschied zu den Stock hells Versionen feststellen aber du wolltest eine Rückmeldung zu dem neuen CPU Gov

Also mach weiterhin gute Arbeit