Mon Spica lagg!!!

[taz067]

tu ne peut pas, c'est le devloppeur qui l'a programmé comme ça, et que si tu te mets a les killé a tous bout de champ ton vas ralentir puisqu'il devrais les relancer a chaque fois qu'il en aura besoin

Modifié 25 novembre 2010 par taz067

[Poireau93]

C'est noté merci Taz

[jujudu64]

Ce qu'il entend par ROM officielle c'est surement la ROM opérateur,non ?

ui en effet... je me suis mal exprimé, encore un noob en android ^^

[pixiebob]

je vous propose un autre script tweak pour la CM(cyanogen mod).je me suis inspiré ici et la

j'ai activé oom_kill_allocating_task qui permet lors d'une OOM(out of memory) de tuer la tache responsable de l'oom.quand cette option est desactive lors d'une oom c'est une tache au hasard selon son niveau de priorite qui est tue.

j'ai changé pas mal de parametre selon les recommandations cite dans les liens et suis plutot content de ce script.

Modifié 27 novembre 2010 par pixiebob

[Syyv]

Je l'installe et je vois ce qui ce passe aujourd’hui. Mes retours retours vers 19:40H ~ 20H.

Retour : très bon tweak de la part de Pixiebob, déjà incroyablement plus rapide que le v2.1 avec toutes les applications, sortie de veille presque instantané seul bémol remarqué jusqu'à lors du téléchargement d'une appli ou maj à partir du Market alors là on se croirais revenus en 2.1 opérateur :P (j'exagére peut être un peu :P ) sa se met a ramer ouahh ^^

Modifié 26 novembre 2010 par D E K A

[barome]

Tres bonne idee pour l oom

[Kyojin]

Mais si par exemple l'out of memory est causé par le navigateur Internet qu'on est entrain d'utiliser tranquillement, là c'est.. paf! killé sauvagement :P Je prends et j'installe tout de même :)

[pixiebob]

en utilisant opera mini je n'ai pour l'instant jamais été killé.je verifie souvent ma memoire et elle stagne tjrs aux environ de 26M.

un autre bon point du script c'est que le systeme est bien reactif des que l'on sort de l'etat de veille et aussi qu'en multitache il n'y a pas ou peu par moment des latences comme j'en avais avec le script precedent.

[franzyroy]

c'est cool mais pense tu en faire pour ceux qui ont comme moi tweak_xda_rfs_v2?

[Kyojin]

Pour l'instant aussi sous xScope pas été killé, çà s'annonce bien çà! :)

@franzyroy: Pourquoi ne pas passer sous ext? :/

Modifié 26 novembre 2010 par Kyojin

[pixiebob]

sinon le choix d'activer oom_kill_allocating_task peut etre discuter,mais disons que normalement il ne doit jamais y avoir de depassement de memoire et que quand cela se produit c'est que l'app bug,il me parait judicieux donc que ce soit l'app en question responsable de l'instabilité du systeme qui soit tué.

[pixiebob]

c'est cool mais pense tu en faire pour ceux qui ont comme moi tweak_xda_rfs_v2?

franzy je vais t'en faire un.je vais supprimer la partie du script qui fait le montage des partitions avec noatime vu que ca sert a rien avec le rfs.

et pour l'option vfs_cache_pressure je le laisse a 100 car j'ai lu partout que c'est la valeur recommandé,contrairement a ch33kybutt qui lui met a 1000(pour rfs).

tu me diras ce que tu en penses.

Modifié 26 novembre 2010 par pixiebob

[franzyroy]

franzy je vais t'en faire un.je vais supprimer la partie du script qui fait le montage des partitions avec noatime vu que ca sert a rien avec le rfs.

et pour l'option vfs_cache_pressure je le laisse a 100 car j'ai lu partout que c'est la valeur recommandé,contrairement a ch33but qui lui met a 1000(pour rfs).

tu me diras ce que tu en penses.

t'es super rapide! je t'en remercie, j'essaie et te dirai les retours... ;)

edit:

en tous cas, je peux déjà dire une chose, je pense que cela vienne de ton fichier, c'est la première fois que je vois un démarrage aussi instantané... :/

edit N°2:

- pour le market, c'est pas plus rapide sauf peut être le téléchargement, à voir avec d'autres mises à jour si c'est pareil

- question fluidité, c'est pas mal, mais à voir aussi car quand je redémarre, mon phone est toujours plus fluide

- toujours question fluidité, à la sortie du Lock, c'est aussi instantané

- les applis sont aussi plus fluides

- le suivi conso bouygues telecom est fluide lui aussi à rapport à avant( même eu le temps de voir la flèche qui tourne)

edit N°3:

depuis près de 12h, il est toujours aussi fluide, l'autonomie batterie, non mais c'était ma deuxième batterie, celle qui ne dure pas longtemps, ce n'est pas la première fois qu'elle ne dure pas longtemps, donc j'attends de voir avec l'autre...

- CMupdater pareil, il se lance à vitesse grand V et en plus réponse rapide au niveau Update

- Le navigateur, impeccable

- lancement plus rapide du player vidéo yxplayer, même la vidéo d'ailleurs est plus fluide.

Modifié 27 novembre 2010 par franzyroy

[pixiebob]

je viens d'installer le kernel Xmister std build(c'est le plus performant des trois qu'il propose).avec mon script ca depote fini les lags :) .

quadrant:620

[pixiebob]

franzyroy:c'est vrai que en choissisant "ondemand" c'est un peu moins autonome que si c'etait "conservative" mais pas bcp plus puisque que quand le cpu n'est pas sollicité il revient a 66 mhz.avec un spica qui n'a pas de grosse perf a la base on est obligé de faire un petit compromis sur la batterie.

edit: quand le cpu depasse les 30%de sa capacité il atteint direct les 800mhz.

en dessous des 30%de sa capacité il revient a 66mhz.

c'est cette option(ondemand et 30%) qui fait que le spica sort plus rapidement de l'etat de veille

Modifié 27 novembre 2010 par pixiebob

[Chtarlight]

Bon je teste ton script depuis 24h maintenant Pixiebob et ben... ouah !! :)

-Plus de freezes avec CM updater

-Le clavier s'affiche instantanément dans hancent alors qu'avec le script v2 de ch33kybutt il y avait un petits temps de latence

-Switcher entre les applis est plus rapide qu'avant

.....

Pour ma culture perso : a quoi correspond "vfs_cache_pressure" (et les valeurs qu'on lui associe ?)?

[franzyroy]

franzyroy:c'est vrai que en choissisant "ondemand" c'est un peu moins autonome que si c'etait "performance" mais pas bcp plus puisque que quand le cpu n'est pas sollicité il revient a 66 mhz.avec un spica qui n'a pas de grosse perf a la base on est obligé de faire un petit compromis sur la batterie.

edit: quand le cpu depasse les 30%de sa capacité il atteint direct les 800mhz.

en dessous des 30%de sa capacité il revient a 66mhz.

c'est cette option(ondemand et 30%) qui fait que le spica sort plus rapidement de l'etat de veille

moi perso, je n'utilise plus SETCPU depuis que j'ai eu des emmerdes avec... je veux bien ressayer mais avec quels paramètres car j'ai vu je ne sais plus ou qu'il était différent de ceux mis à la base par barome, je crois...

Modifié 27 novembre 2010 par franzyroy

[pixiebob]

Chtarlight:en gros c'est un parametre de gestion de la memoire.plus la valeur est basse et plus la memoire conserve les dentry et inode.plus la valeur est haute et moins les dentry et inode sont conservé dans la memoire.

inodes:sont

les objets qui représentent les fichiers sous-jacents (et également des repertoires)

dentry:est un objet avec un nom de chaîne (d_name), un pointeur vers un inode

(D_inode), et un pointeur vers la dentry parent (d_parent).

desolé traduction google.

franzyroy: plutot que d'utiliser setcpu je suis en train de chercher les parametres a mettre dans le script pour que lorsque l'ecran est eteinds le cpu soit bloqué a 66 mhz afin d'economise la batterie

Modifié 27 novembre 2010 par pixiebob

[oxysteph72]

Installé ext2 v2, pffff c'est de la bâlle, plus de lags, réveil instantané du spica, m'a servi, merci

[franzyroy]

franzyroy: plutot que d'utiliser setcpu je suis en train de chercher les parametres a mettre dans le script pour que lorsque l'ecran est eteinds le cpu soit bloqué a 66 mhz afin d'economise la batterie

cool car setcpu, j'avais pas spécialement envi...

[Chtarlight]

Merci j'ai compris l'idée, donc en gros la valeur de 1000 que Ch33kybutt avait mise dans son script pouvait paraitre un peu stricte ? D'où l'intérêt de la conserver a 100 pour ne pas gêner le multitasking, non ?

[pixiebob]

Chtarlight :en gros oui c'est tout a fait ca.

[pixiebob]

voila la 3eme version.

nouveauté: lorsque que l'ecran est allume parametre habituel governor sur "ondemand"

lorsque l'ecran est eteinds governor sur "powersave" qui bloque la frequence a 66 mhz.

pour verifier la frequence avec adb faite:

adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

vous pouvez verifiez le changement de governor avec adb logcat

[barome]

yeah c bon pour la batterie ca ;)

[franzyroy]

voila la 3eme version.

nouveauté: lorsque que l'ecran est allume parametre habituel governor sur "ondemand"

lorsque l'ecran est eteinds governor sur "powersave" qui bloque la frequence a 66 mhz.

pour verifier la frequence avec adb faite:

adb shell cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

vous pouvez verifiez le changement de governor avec adb logcat

je test dès que je peux surtout que toujours aussi satisfait de tweak v2 rfs... ;) pour l'autonomie, je confirme ce que je disais affiché ci-dessous, c'est bien ma deuxième batterie qui a un souci, celle que j'ai là tient bien...

l'autonomie batterie, non mais c'était ma deuxième batterie, celle qui ne dure pas longtemps, ce n'est pas la première fois qu'elle ne dure pas longtemps, donc j'attends de voir avec l'autre...

Modifié 27 novembre 2010 par franzyroy