dahool
Erfahrenes Mitglied
- 170
!!Wichtig zum testen: Keinen Taskmanger (auch nicht den build in von Samsung) verwenden!!
Gestern hatte ich etwas mehr Zeit und konnte mit zwei SGS etwas wegen dem Lag Problem ausprobieren.
Wenn jemand Zeit hat und sich mit flashen GUT auskennt könnte hier kurz mal seine Erfahrungen posten.
Der I/O Bug ist zwar noch nicht ganz behoben aber aufgrund des SD Card Fix nicht mehr relevant für die Lags.
1. Teststellung (Galaxy mit JM5 nicht gerootet kein SD Card fix)
Die Lags sollten erst auftauchen wenn der RAM Speicher genau die Grenze von weniger als 70 MB RAM erreicht. Der RAM wird nach öffnen und schließen mehrerer Programme kaum oder nur schlecht wieder frei gegeben.
2. Teststellung (Galaxy JM5 gerootet mit SD Card fix)
Die Lags treten auf bei einer RAM Grenze von genau 70 MB (sind aber nicht so lange wie in der Teststellung 1). Wenn mehr RAM vorhanden ist, läuft das Galaxy S sehr flüssig. Geht der freie RAM unter 70MB treten auch hier immer wieder (leichtere) Lags auf.
3. Teststellung (Galaxy JM5 gerootet mit SD Card fix und Autokiller auf 40/50/60 )
Die RAM Grenze von weniger als 70 MB sollte nicht erreicht werden und das SGS immer flüssig laufen (auch wenn man mehrere Programme öffnet und nicht schließt, sondern über den Homebutton in den Hintergrund setzt). Ganz leichte "Ruckler" in den Programmen Telefon, Kontakte und Kalender können auftreten, dass ist aber ein Problem der Samsung Apps und nicht des Telefons oder Android.
Nur hier dein Gefühltes User Experince posten. Keine Quadrant Zahlen, da die den Lag Bug im Programm Management (außer der RAM ist schon unter 70MB) nicht berücksichtigen.
Es sollte mit der Teststellung 3 ein flüssiges Arbeiten DAUERHAFT vorhanden sein.
Wenn sich der Fehler so wirklich eingrenzen lässt, würde dieser durch eine Kernel Anpassung behoben werden können.
Möglicher Lösungsvorschlag wäre diff auf Kernel /Source linux-2.6.29/drivers/staging/android/lowmemorykiller.c
static size_t lowmem_minfree[6] = {
3*512, // 6MB
2*1024, // 8MB
4*1024, // 16MB
16*1024, // 64MB
P.S. Bitte momentan nicht das Facebook App zum testen verwenden, da hier ein Codeproblem im Memory Management vorhanden ist.
Gestern hatte ich etwas mehr Zeit und konnte mit zwei SGS etwas wegen dem Lag Problem ausprobieren.
Wenn jemand Zeit hat und sich mit flashen GUT auskennt könnte hier kurz mal seine Erfahrungen posten.
Der I/O Bug ist zwar noch nicht ganz behoben aber aufgrund des SD Card Fix nicht mehr relevant für die Lags.
1. Teststellung (Galaxy mit JM5 nicht gerootet kein SD Card fix)
Die Lags sollten erst auftauchen wenn der RAM Speicher genau die Grenze von weniger als 70 MB RAM erreicht. Der RAM wird nach öffnen und schließen mehrerer Programme kaum oder nur schlecht wieder frei gegeben.
2. Teststellung (Galaxy JM5 gerootet mit SD Card fix)
Die Lags treten auf bei einer RAM Grenze von genau 70 MB (sind aber nicht so lange wie in der Teststellung 1). Wenn mehr RAM vorhanden ist, läuft das Galaxy S sehr flüssig. Geht der freie RAM unter 70MB treten auch hier immer wieder (leichtere) Lags auf.
3. Teststellung (Galaxy JM5 gerootet mit SD Card fix und Autokiller auf 40/50/60 )
Die RAM Grenze von weniger als 70 MB sollte nicht erreicht werden und das SGS immer flüssig laufen (auch wenn man mehrere Programme öffnet und nicht schließt, sondern über den Homebutton in den Hintergrund setzt). Ganz leichte "Ruckler" in den Programmen Telefon, Kontakte und Kalender können auftreten, dass ist aber ein Problem der Samsung Apps und nicht des Telefons oder Android.
Nur hier dein Gefühltes User Experince posten. Keine Quadrant Zahlen, da die den Lag Bug im Programm Management (außer der RAM ist schon unter 70MB) nicht berücksichtigen.
Es sollte mit der Teststellung 3 ein flüssiges Arbeiten DAUERHAFT vorhanden sein.
Wenn sich der Fehler so wirklich eingrenzen lässt, würde dieser durch eine Kernel Anpassung behoben werden können.
Möglicher Lösungsvorschlag wäre diff auf Kernel /Source linux-2.6.29/drivers/staging/android/lowmemorykiller.c
static size_t lowmem_minfree[6] = {
3*512, // 6MB
2*1024, // 8MB
4*1024, // 16MB
16*1024, // 64MB
P.S. Bitte momentan nicht das Facebook App zum testen verwenden, da hier ein Codeproblem im Memory Management vorhanden ist.
Zuletzt bearbeitet:
