Nouvelle approche pour lutter contre le problème de latence, no ext.SD

[curio]

Hello !

J'ai reçu hier le Galaxy S et démarré les tests.

Effectivement, après avoir installé un petit paquet d'apps, en quelques heures d'utilisation les désagréables pauses aléatoires en passant d'une app à l'autre n'ont pas tardé à se manifester.

Firmware d'origine : I9000XXJF3

J'ai donc essayé la nouvelle approche d'il y a quelques jours : https://forum.frandroid.com/forum/viewtopic.php?pid=278230#p278230

Et vous allez voir les résultats sont très intéressants !

Description d'une autre approche :

Le problème de latence, lag/stalling est maintenant identifié.

Sa source est le système de fichier Samsung RFS, qui semble nettement moins performant que ce que Samsung en dit.

L'astuce est donc de ne pas écrire directement les fichiers sur un montage RFS.

Pour éviter les complications de re-partitionnement et/ou re-formatage, on peut utiliser un fichier contenant le système de fichier désiré (c'est à dire... tout sauf RFS)

Linux possède la capacité de monter un fichier comme si c'était un disque. C'est pratique, on va utiliser ça ^^

/!\ Pour faire les manips décrites, j'ai du rooter mon Galaxy S. Par contre, pour faire simple j'ai pas changé de noyau.

Les étapes (sous Linux):

1 / Créez un fichier vide de 1200Mo

dd if=/dev/zero of=data_ext3.img bs=1M count=1200

2/ Formatez ce fichier en ext3

mkfs.ext3 -F data_ext3.img
tune2fs -c 0 -i 0 -m 0 data_ext3.img

Pourquoi ext3 et pas ext4 ?

Parce que le noyau officiel supporte ext3 !

3/ Copiez le fichier data_ext3.img sur la carte SD interne du téléphone, préalablement montée sur votre ordinateur.

4/ Une fois la copie terminée, rendre au téléphone la main sur la SD interne.

5/ Se connecter au téléphone par adb, puis acquérir les droits root :

adb shell
su

6/ killez si possible toutes les apps en cours de fonctionnement sur le téléphone

7/ lancez les commandes suivantes sur le téléphone (déplacer le fichier image, montage, faire une sauvegarde, utiliser un lien symbolique)

busybox mv /sdcard/data_ext3.img /data/
mkdir /data/loop-mount-point
mount -t ext3 -o loop /data/data_ext3.img /data/loop-mount-point
busybox cp -a /data/data/* /data/loop-mount-point
busybox mv /data/data /data/data-backup
ln -s /data/loop-mount-point /data/data

8/ re-killez vos apps.

On veut être sûr que si certaines se sont re-lancées entre temps, elles écrivent bien sur notre nouveau système de fichier et non dans la sauvegarde.

9/ Ça y est ! lancez Quadrant pour voir ^^

Pour vous donner une idée, voilà ce que ça donne sur mon tel :

Et Voilà !

Tout ça sans flasher de firmware/noyau et sans avoir besoin de carte SD additionnelle :)

Cool non ?

Je vous montre ça juste pour que vous appréciez le concept :D

Pour l'instant, si on reboot le téléphone, plus aucune app ne fonctionne car elle n'a plus accès à ses données.

Ce qu'il reste à faire :

• Modif du script init.rc ? pour monter/démonter la loop automatiquement.
  
• Choix de la taille idéale pour l'image disque data_ext3.img
  
• Quelques validation sur la robustesse du système de fichier en cas de crash ou arrêt inopiné du téléphone, en ajoutant peut être quelques options au mount de data_ext3.img.
  
• Valider que ça règle réellement le problème de latence, et ne change pas seulement le résultat du benchmark
  

Bonus : ci-joint un zip contenant un data_ext3.img de 1200Mo prêt à être utilisé.

Modifié 21 juillet 2010 par curio

[FromtonRouge]

Punaise mais c'est génial ça! J'ai pas le temps de tester ça ce soir je suis en vacances mais si ça marche faut que t'en parles sur le forum xda :) (je mettrai mon tuto à jour aussi)

[curio]

'Lo FromtonRouge :)

Ok je posterai en anglais dès qu'on aura pu vérifier si ça marche réellement.

Si ça affole juste Quadrant, c'est pas vraiment la peine :D

Sinon, si vous voulez essayer puis défaire les manips c'est très simple :

1/ Connectez vous au téléphone et passez root

adb shell
su 

2/ Killez toutes vos applis pour qu'elles sauvegardent leur état et ferment les fichiers ouverts.

3/ On défait !

busybox rm -rf /data/data-backup/*
busybox cp -a /data/data/* /data/data-backup/
busybox rm -f /data/data
busybox mv /data/data-backup /data/data
umount  /data/loop-mount-point 
busybox losetup -d /dev/block/loop0
rm /data/data_ext3.img

4/ re-Killez toutes les apps à nouveau.

Maintenant vous pouvez redémarrer (ou pas) sans souci ^^

Modifié 21 juillet 2010 par curio

[FromtonRouge]

Bon j'ai pas pu resister..... j'ai fait ça au boulot et pour l'instant ça a l'air de super bien marcher. J'ai lancé une 20 aines d'applications, aucun problème pour l'instant.

Bon y a plus qu'à mettre le montage dans l'init.rc et je reboot pour voir :)

[curio]

Cool merci, plus il y a de testeurs mieux c'est :)

N'hésitez pas à donner vos impressions ici !

Comme autres avantages de cette approche on peut ajouter :

- Certitude de ne pas fatiguer la carte SD externe ou interne, car les données sont toujours écrites en passant par le système Samsung, qui j'espère au moins gère le wear leveling correctement :D

Une approche encore alternative serai de formater tout /data en ext3, mais comme le format RFS est obscur et propriétaire, il est difficile de garantir de manière absolue que ça ne ne fatiguerai pas prématurément la mémoire interne du téléphone.

- Bien sûr, pouvoir enlever la carte SD... si on en a une !

- L'augmentation de performance dépendait de la vitesse de la carte SD externe.

Pas là, la SD interne se débrouille assez bien.

- Plutôt que d'installer un Firmware leaké qui pourrai corriger le problème, on reste sur celui d'origine, en préservant un Market qui montre toutes les apps, etc.

Toutefois ces modifs doivent marcher avec tous les firmwares, y compris modifiés par les opérteurs, présent et futurs.

Donc oui reste à faire l'init.

/!\ Si vous voulez changer de firmware en gardant vos données utilisateurs, vous devez passer par l'étape défaire :cool:

Modifié 21 juillet 2010 par curio

[quitos]

trop fort !!!

vous n'avez plus qu'à nous finaliser tous ça les gars .... ;)

purée , j'ai trop envie de faire une pre annonce sur xda

faut que je me retienne .... , c'est pas à moi de le faire ...

Modifié 21 juillet 2010 par quitos

[firebird2]

il faut absolument avoir linux pour faire cette manip ?

[gontran]

Salut Curio,

je veux bien tester ta manip mais avant est-ce que tu pourrais m'indiquer comment défaire la manip concernant la carte externe? (histoire de ne pas perdre mes données)

De plus, si j'ai bien compris, si à chaque reboot (tant que init.c n'est pas modifié) les applis ne se lancent pas, j'imagine qu'il suffit juste de refaire le "ln -s /data/loop-mount-point /data/data" pour que tout refonctionne, non?

Si c'est le cas, ça ne me dérange pas d'avoir une ligne de code à taper à chaque reboot.

En tout cas bravo pour ce bon boulot.

[curio]

il faut absolument avoir linux pour faire cette manip ?

Non, par contre il faut le kit de dev android, et également activer le mode de debug USB sur le téléphone.

Le kit de dev android est dispo pour win/mac/linux

Salut Curio,

je veux bien tester ta manip mais avant est-ce que tu pourrais m'indiquer comment défaire la manip concernant la carte externe? (histoire de ne pas perdre mes données)

Les manips pour défaire la modif sont indiquées dans le post n°3

Avec cette approche, on touche pas à la carte externe.

Ta question, c'est si on a déjà fait l'autre fix, comment l'enlever pour essayer celui-ci ?

De plus, si j'ai bien compris, si à chaque reboot (tant que init.c n'est pas modifié) les applis ne se lancent pas, j'imagine qu'il suffit juste de refaire le "ln -s /data/loop-mount-point /data/data" pour que tout refonctionne, non?

Si c'est le cas, ça ne me dérange pas d'avoir une ligne de code à taper à chaque reboot.

En tout cas bravo pour ce bon boulot.

Merci :)

Alors à chaque boot en fait il suffit de taper une commande en root :

mount -t ext3 -o loop /data/data_ext3.img /data/loop-mount-point

Concernant le lien symbolique, il n'aura pas bougé et fera son office comme avant ^^

Notes que pour arrêter le téléphone correctement, il faudrai au préalable killer toutes les applis puis lancer en root sur le téléphone :

umount /data/data

Si c'est refusé, c'est que des apps tournent encore

PS :

j'ai pas essayé de rebooter, c'est donc de pures suppositions ^^

A priori, je suppose que la majorité/totalité des apps qui se lancent vont crasher si elles n'ont pas accès à leur données enregistrées dans /data/data sur le téléphone

Toute aide sur l'init.rc est bienvenue !

Je commence tout juste à lire http://www.androidenea.com/2009/08/init-process-and-initrc.html

Modifié 21 juillet 2010 par curio

[gontran]

Ta question, c'est si on a déjà fait l'autre fix, comment l'enlever pour essayer celui-ci ?

oui tout à fait, j'avais bien lu tes différents posts (le 3 inclus) ;)

merci de tes précisions.

Modifié 21 juillet 2010 par gontran

[FromtonRouge]

Zut l'init.rc semble être réécrit à chaque boot, et y a pas de fstab sur android non plus... c'est quoi les différentes étapes d'init sur Android?

[th00ber]

Bien joué !

Grrrr trop lent ... j'étais justement en train de creuser cette idée pour le GS. Je me basais sur un vieux script que j'utilisais pour monter des fichiers iso manuellement sur mon Linux et je cherchais à adapter ça.

Super boulot, le tuto est bien fait :P !

Pour lancer le script de montage en auto:

le placer dans /system/etc/init.d/ et l'enregistrer avec update-rc.d pour qu'il se lance au demarrage du système. Ca pourrais être une piste ?

Modifié 21 juillet 2010 par th00ber

[curio]

Zut l'init.rc semble être réécrit à chaque boot, et y a pas de fstab sur android non plus... c'est quoi les différentes étapes d'init sur Android?

Je cherche en ce moment..

Tu es sûr que l'init.rc est ré-écrit à chaque fois ?

Si c'est le cas, je n'ai pas encore trouvé à partir de quoi il est re-géneré.

j'dois m'absenter un moment, à plus tard les mecs, cherchez bien :D

Modifié 21 juillet 2010 par curio

[curio]

Bien joué !

Grrrr trop lent ... j'étais justement en train de creuser cette idée pour le GS. Je me basais sur un vieux script que j'utilisais pour monter des fichiers iso manuellement sur mon Linux et je cherchais à adapter ça.

Oui, c'est du linux traditionnel, rien d'incroyable dans tout ça :D

Bien joué !

Pour lancer le script de montage en auto:

le placer dans /system/etc/init.d/ et l'enregistrer avec update-rc.d pour qu'il se lance au demarrage du système. Ca pourrais être une piste ?

Eh non dommage, ce serai pratique.

Android n'est pas une distribution Linux comme on a l'habitude.

[FromtonRouge]

Je cherche en ce moment..

Tu es sûr que l'init.rc est ré-écrit à chaque fois ?

Si c'est le cas, je n'ai pas encore trouvé à partir de quoi il est re-géneré.

j'dois m'absenter un moment, à plus tard les mecs, cherchez bien :D

J'en suis sur j'ai bien vérifié, y a une image boot qui est appliquée à chaque fois, y a plus d'infos ici : http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images

J'ai bon espoir, ta solution semble plus propre en tout cas (même si il faut tester plus longtemps mais en théorie je vois pas ce qui n'irai pas)

Faudrait peut être passer par la solution "update.zip"

Modifié 21 juillet 2010 par FromtonRouge

[th00ber]

Sur ce lien :

http://www.androidenea.com/2009/08/init-process-and-initrc.html

Le mec utilise le init.rc pour lancer ses services sur son Android

Ca parrait étrange que le init.rc soit écrasé à chaque boot.

Allez FromtonRouge, ca mérite une 2 ème tentative :D

PS : FromtonRouge, tu postes trop vite ^^ ... je laisse le post quand même si tu veux voir le lien

Modifié 21 juillet 2010 par th00ber

[FromtonRouge]

Sur ce lien :

http://www.androidenea.com/2009/08/init-process-and-initrc.html

Le mec utilise le init.rc pour lancer ses services sur son Android

Ca parrait étrange que le init.rc soit écrasé à chaque boot.

Allez FromtonRouge, ca mérite une 2 ème tentative :D

J'en ai fait 3 :D. Ce que j'ai fait :

1) adb pull de /init.rc

2) Edition de l'init.rc en ajoutant un commentaire à la fin (# Hello world)

3) adb push vers /sdcard/init.rc

4) adb shell etc... en root + copie de /sdcard/init.rc vers /init.rc

5) cat /init.rc => je vois bien mon commentaire à la fin # Hello world :)

6) Enfin reboot....

7) cat /init.rc => le commentaire a disparu :(

[th00ber]

Utiliser ce système pour détecter la fin de boot et lancer le mount ?

https://forum.frandroid.com/forum/viewtopic.php?id=8143

http://www.androidcompetencycenter.com/2009/06/start-service-at-boot/

A moins que attendre la fin du boot, ce soit déjà trop tard ? :(

[azriek]

génial que ça puisse fonctionner :)

il manque en effet plus que l'init.rc .

Sur d'autres tel android, il y'a bien un /system/etc/fstab, peut être qu'en en le créant il sera lu à un moment du boot ?

Az'

edit: fstab testé mais sans resultat

Modifié 21 juillet 2010 par azriek

[JimZ]

Bravo pour le 1er test !

C'est super concluant ^^

J'ai carrément envie de passer la rom interne en ext3 :o

Modifié 21 juillet 2010 par JimZ

[azriek]

J'obtiens un score de 1112, bizarre cette différence ?

[curio]

re tout le monde !

J'ai une bonne et une mauvaise nouvelle.

La bonne, c'est que Busybox intègre l'outil "patch", ce qui sera utile pour modifier des fichiers proprement.

La mauvaise, c'est qu'en l'utilisant tout à l'heure mon SGS s'est mis à lagguer sévèrement en passant d'une appli à l'autre :mad:

Suis-je le seul à avoir eu cette expérience ?

[curio]

J'obtiens un score de 1112, bizarre cette différence ?

Avec le même matos / même config, je ne saurai pas comment expliquer cette différence !

(d'autres apps en route ?)

[FromtonRouge]

re tout le monde !

J'ai une bonne et une mauvaise nouvelle.

La bonne, c'est que Busybox intègre l'outil "patch", ce qui sera utile pour modifier des fichiers proprement.

La mauvaise, c'est qu'en l'utilisant tout à l'heure mon SGS s'est mis à lagguer sévèrement en passant d'une appli à l'autre :mad:

Suis-je le seul à avoir eu cette expérience ?

Helas j'ai remis le fix carte SD externe après 2 heures de test, parce que je voulais avoir un tel stable pendant les vacances :). J'ai pas pu tester plus du coup.

J'ai oublié de le dire mais avant ton fix j'étais à 1120 sur Quadrant (en ext3 SD externe). Avec ton fix je suis passé à 1550 et j'ai bien vu la différence lors du test "Database write": d'habitude ça dure 10 minutes, là 4 secondes à tout casser....

[azriek]

1133, puis 1253, puis 1295 en relançant le bench à la suite, un task killer a été lancé avant les tests.

ça semble varier pas mal chez moi.

peut être faudrait il un script de test basé sur des écritures/lecture sqlite...