AutoUCUV - (Forçage CPU - et OC-UV-GPU)

[Xkz]

Cela dépent de ta wifi sleep policy. Tu le règles dans Paramètres wifi > touche MENU > Paramètres avancés.

[rsuinux]

Ah ben tient, j'en aurais encore apris aujourd'hui !!! :)

Merci

[rsuinux]

.../...

Sinon, voici le script que j'utilise et qui fonctionne sans problème, il permet la modif' de base : UV//OC/UC//GOV, avec le forçage CPU. Il est principalement basé sur le premier que tu avais posté, j'y ai ajouté quelques plus, il reste très simple comme tu pourras le constater. ^^

http://db.tt/XKk0oKnM

dans ton script, ou as tu trouvé les valeurs dans :

UV_S="0 25 50 50 100 125 125 "

?

[Xkz]

J'ai fait des tests avant pour savoir quelles étaient les valeurs stables. Les valeurs stables seront différentes pour chaque téléphone. Je peux faire fonctionner des kernels ayant un très gros o/c CPU (1.6GHz), par contre un u/v un peu fort et c'est le soft brick assuré. Un ami n'arrive pas à boot à des kernels > à 1.45GHz mais à un u/v énorme (25 75 150 150 225 300 375).

Les différentes valeurs sont en mV et sont liés respectivement à l'ordre décroissant des différents pas de fréquence.

[rsuinux]

d'accord, mais ce que je ne comprend pas, c'est que naïvement, je mettais en rapport la frequence avec le (micro)voltage. La, ce n'est pas le cas, donc.

Mais si je suis bien, un proc sous-volté, avec une fréquence élevée, et il n'y aura pas assez d'énergie pour faire face aux ressources demandées, non?

Et comment c'est-t-y qu'on fait quand on a mis des mauvaises valeurs, et que le prcesseur peut plus fonctionner?

[Xkz]

Ce sont bien je crois des mV et non des μV, enfin si c'est le contraire, excuse-moi.

Sinon à mort les idées reçus ! Un u/v ne réduit pas les performances mais réduit seulement le voltage donc l'échauffement et la consommation de la batterie.

Un u/v tout comme un o/v important sont mauvais pour le fonctionnement général du CPU bien évidemment. Lorsque des valeurs de voltage ne sont pas stables, l'écran se fige. Il ne reste qu'à attendre d'avoir un fast reboot (assez rare) ou d'enlever la batterie. L'avantage avec le script actuel que l'on lance avec Root Explorer par rapport à SetCPU/System tuner est que les u/v, u/c et autres ne sont pas lancé au démarrage et qu'il n'y a pas de contrôle permanent de certaines valeurs comme la fréquence actuelle. Ce qui permet ainsi d'avoir un gain de batterie.

[Yamuto]

Néanmoins, le moyen le plus simple est de le lancer directement avec root explorer qui se chargera de tout.

C'est cette méthode que j'emploi avec CM7, et cela fonctionne trés bien.

(Mettre toutefois les droits "rwxrwxrwx" sur le script, avec proprietaire et groupe "root")

Attention :

Ce script doit être modifié pour l'adapter en fonction de ces propres valeurs d'OC et/ou d'UV

## Modifier/Activer pour les UV Custom

#FREQ_V="25 25 25 75 125 200 275"

On peux également modifier la partie correspondante au forçage du démarrage du second CPU

### CPU Online (Actif - Desactivé)

###

CPU_A="1"

CPU_D="0"

Personnellement, je force le démarrage systématiquement afin d'améliorer le fonctionnement du mode "suspens" (écran éteind), et la chauffe en pleine charge. C'est également plus réactif, quand le deuxième CPU n'a pas à passer en "iddle"

Si le script est modifié directement dans /system/etc/init.d/99autoucuv (après installation du CWM), il suffit simplement de rebooter le téléphone, et de couper l'écran 4 fois.

Si j'ai bien compris, vu que j'ai la Neutrino de base CM7. Le moyen le plus simple serait de modifier les valeurs de 2 lignes du script puis de placer le script sur le tel et de le lancer via script manager en mot SU ( root ).

Et si j’éteins et allume 4 fois l'écran, je pourrais arrêter le script. Il me faudra ensuite le désinstaller via le recovery en format /system.

Aussi, j'ai lu qu'il fallait faire des testes pour connaître ses valeurs u/v. Comment peut-on faire les testes ?

[Delewer]

Houla !

Je vais tenter de remettre de l'ordre ^_^

Pour CM7, et dans l'attente de le rendre pleinement exécutable au boot, il faut :

- Placer le script "à la main" sur le téléphone.(FTP, par le cable sur le PC, etc...)

- Ensuite, tu dois placer les droits Root et "eXecution" sur le script (par root explorer, ou par ligne de commande).

- Puis, il suffit de le lancer par root explorer en cliquant dessus.

Sinon, si tu n'y arrive pas de cette manière, tu peux passer par "Script Manager" qui s'occupe de tout.

Une fois lancé, le script te rend la main, comme si rien ne se passait.

Pour vérifer que tout soit OK, vérifier le contenu du fichier "AutoUCUV/AutoUCUV.log" sur la sdcard

Normalement, tu vas voir évoluer l'execution du script.

Il y a un compteur qui decomptera le nombre d'allumage de l'écran.

C'est une sécurité. Si tu a mis des valeurs d'UnderVolting (UV), il y a risque de Freeze du tel si les valeurs sont trop agressives.

Donc, (dans le cas où on a installé au boot), cela laisse 4 allumages d'écran avant la vrai activation de l'UV, donc largement le temps pour desintaller manuellement.

Il faut donc que tu allume 4 fois l'écran pour le script s'active réellement.

Pour les valeurs d'UV, et donc bien avant d'utiliser le script, il faut que tu les détermine par l'expérimentation.

Pour cela, il est impératif que tu utilise SetCPU afin de faciliter tout le process.

Pour cela, tu trouvera une plétore de tuto à travers le net ou sur Xda... C'est assez simple, mais il y a des regles à suivre.

Chaque valeur d'UV est trés personnellement associé à son propre téléphone, et on doit tester chaque valeur sur chaque fréquence de fonctionnement... mais également par rapport au kernel que l'on a installé (1Ghz, 1,45Ghz, 1,3Ghz, 1,6Ghz...)

Modifié 7 mars 2012 par Delewer

[Xkz]

Comme promis, le script pour l'i/o scheduler et la taille du cache ! Le script est à placer dans /system/etc/init.d puis il faut changer l'appartenance en root.root et mettre les permissions rwxrwxrwx. Vous faites soit cela à partir de root explorer, soit à partir du terminal :

su
busybox mount -o remount,rw /system
cd /system/etc/init.d
chown 0.0 98iosdtweaks
chmod 777 98iosdtweaks
busybox mount -o remount,ro /system
exit

Donc il se lance au boot, vous n'avez rien à faire à part changer jusqu'à 3 lettres :

SCH_A="anticipatory"

SCH_B="bfq"

SCH_C="cfq"

SCH_D="deadline"

SCH_N="noop"

CA_ES="256"

CA_S="512"

CA_N="1024"

CA_L="2048"

CA_EL="4096"

SCHEDULER=$SCH_D

CACHESIZE=$CA_N

Seulement les lettres colorées sur les deux dernières lignes sont à modifier par un groupe de lettres ayant la même couleur.

J'ai fait une bonne vingtaine de tests, tout devrait être bon. Cela évite désormais de passer par une application pour ces modifications.

Téléchargement : http://db.tt/glLRlNkH

Modifié 7 mars 2012 par Xkz

[Delewer]

On fait un concours ?

Voici un script qui permet de récuperer sur CM7 l'indicateur "charge pleine" quand on atteind 100% de charge.

Pour ceux qui ont des ROM à base de CM7, cela peux être agreable de récupérer cette fonctionnalité.

#!/system/bin/sh
#
# Permet d'allumer la LED une fois la charge pleine
#green blue red white
COLOR_LED=green
SLEEP_INI=60
SLEEP_CHARGE=5
SLEEP=$SLEEP_INI
Etat=0
(while [ 1 ]
 do
 LEVEL=$(cat /sys/class/power_supply/battery/capacity)
 STATUS=$(cat /sys/class/power_supply/battery/status)
 VOLTAGE=$(cat /sys/class/power_supply/battery/voltage_now)
 COUNTER=$(cat /sys/class/power_supply/battery/charge_counter)
 if [ "$COUNTER" != "100" -o "$STATUS" != "Full" ] && [ "$Etat" = "0"] ; then
echo 0 > /sys/class/leds/$COLOR_LED/brightness
Etat=1
SLEEP=$SLEEP_INI
 fi
 if [ "$COUNTER" = "100" ] && [ "$STATUS" = "Full" ] ; then
echo 1 > /sys/class/leds/$COLOR_LED/brightness
Etat=0
SLEEP=$SLEEP_CHARGE
 fi
 sleep $SLEEP
done &)

Voici le script tout fait => FixLedBatCM7.zip

Attention, ce n'est pas un cwm, il faut l'installer à la main.

Modifié 10 mars 2012 par Delewer

[Xkz]

Bien pensé, je vais l'essayer.

[Yamuto]

J'ai donc testé les valeurs une par une et je me suis retrouvée avec ces valeurs: 0 25 25 50 75 100 125

A vrai dire j'avais peur de descendre plus bas car j'ai eu aucun freeze meme en lancant les jeux et internet.

Puis dans mon fichier .log j'ai:

lancement......

PID en cours 16136

PID precedent ( killed ):

Compteur de réveil: 4 avant activation UV / UC

Les logs ne bougent pas alors que j'ai éteins et allumé 4 fois l'écran. j'ai meme fait un redémarrage.

[Xkz]

Tu as mis la bonne appartenance et les bonnes permissions ?

[Yamuto]

Je l'ai faite ce la manière bête en lançant le script via script manager. Je le ferai ce soir d'une autre manière.

Sinon c'est possible de descendre a 50mv pour 1000mhz sans freeze ? Alors que de base c'est 1v !

[Xkz]

À toi de tester, dis toi que ton UV ne se lance pas au démarrage, donc aucun risque.

edit : ... Aucun risque à part des ANR, bien évidemment.

Modifié 8 mars 2012 par Xkz

[Yamuto]

Anr = arrêt non ... ? ^^ oui je vais tester de nouveau mais quand tu test pour chaque valeurs. Tu lance des applis pour voir si il suit et tu t'arrete a la valeur avant le freeze ou le reboot ?

[Xkz]

Un ANR, c'est lorsque le système ne repond plus.

Sinon pour les valeurs d'UV, tu commences pour les plus grosses fréquences.

Exemple : Tu mets -25mV à 1.3GHz, aucun anr ou reboot pendant X heures.

Tu mets -50mV à 1.3GHz, tu as un anr au bout de 2 heures.

-> Ton u/v max stable pour 1.3GHz est -25.

Puis tu fais pour les autres valeurs en n'oubliant pas que la règle du -100mV.

[Yamuto]

Ah quand même ! Tu test une seule valeur pendant des heures ! imagine que je commence à 1000mv pour finir a 100mv. J'ai pas fini ^^

J'ai encore deux petites questions, après ça devrait être bon !

Je ne dois pas oublier la règle du -100mv, quelle est cette règle ?

Et par exemple tu testes le 1000 mhz. Tu mets ton SetCpu a mini 1000 et max 1000 pour tester que cette valeur pendant des heures ? ou Tu laisse des vas et vient de fréquences pour tester les 8 fréquences d'un coup ?

[Xkz]

La règle du -100mV est de ne jamais avoir un u/v ≥ -100mV par rapport au pas du dessus et d'en dessous.

Exemple : -25mV pour X MHz et -125mV pour Y MHz ne sera pas possible si Y est un pas qui précède ou suis X.

Sinon pour tester c'est vraiment simple, les différents kernels pour l'atrix ont 7 pas de fréquences.

On commence par faire un u/v de -25 sur le pas ayant la fréquence la plus élevé. Il faut faire cela pas par pas, -25 par -25, en n'oubliant pas la règle expliquée juste au dessous.

edit : Non on ne touche pas à la freq max et freq min lors de tests d'u/v.

Modifié 8 mars 2012 par Xkz

[Yamuto]

Ok merci. Donc je commence le teste par le pas de fréquence le plus élevé puis je mets une différence de pas >= a 100 pour la valeur suivante et ainsi de suite.

Par exemple pour ma fréquence max a 1000mhz, je trouve que 500mV est le top. Alors je diminuerais de 0mV à 100mV la valeur suivantes en fonction des testes et ainsi de suite.

Se que je comprends pas alors, c'est que dans le script de Delewer il ne respecte pas la règle des -100mV entre le pas de fréquence 6 et 7.

## Modifier/Activer pour les UV Custom

#FREQ_V="25 25 25 75 125 200 275"

[Delewer]

Ah les joies du SSD... 1 restauration par ... jour... Et il n'a pas encore deux semaines de vie...

Donc, pour répondre Yamuto : Si, je respecte la regle des 100mv :

1000000 1000 -> 975 (-25 mv)

912000 950 -> 925 (-25 mv)

750000 900 -> 875 (-25 mv)

608000 850 -> 775 (-75 mv)

456000 800 -> 675 (-125 mv)

312000 775 -> 575 (-200 mv)

216000 750 -> 475 (-275 mv)

975 à 925 (<100)

925 à 875 (<100)

875 à 775 (=100)

775 à 675 (=100)

675 à 575 (=100)

575 à 475 (=100)

Je n'ai donc jamais dépassé les 100mv entre les tensions résultantes de l'UV

Modifié 8 mars 2012 par Delewer

[Xkz]

Merci de la précision, on m'avait persuadé que c'était en fonction de l'u/v et non du voltage final.

[Delewer]

De rien

Par ailleur, avec un UV aussi agressif et mon script (j'ai desinstallé setcpu et tout les autres apps inutiles de controle du cpu), je navigue à 5ma de conso écran éteind

Cela me fait une consommation de 10% par 24h de batterie.

Je vais ajouter une partie dans le script qui calculera la consommation réelle en %, avec sortie dans la log, à chaque reveil de l'écran + dans un petit fichier, à consulter à volonté

Egalement, si la SDcard est absente, la sortie se fera dans /system/usr/AutoUCUV Comme ç, pas de probleme de plantage du script.

C'est actuellement se qui arrive si on branche le cable sur le PC (la sdcard se deconnecte... et pouf, le script plante)

[Yamuto]

Ah les joies du SSD... 1 restauration par ... jour... Et il n'a pas encore deux semaines de vie...

Donc, pour répondre Yamuto : Si, je respecte la regle des 100mv :

1000000 1000 -> 975 (-25 mv)

912000 950 -> 925 (-25 mv)

750000 900 -> 875 (-25 mv)

608000 850 -> 775 (-75 mv)

456000 800 -> 675 (-125 mv)

312000 775 -> 575 (-200 mv)

216000 750 -> 475 (-275 mv)

975 à 925 (<100)

925 à 875 (<100)

875 à 775 (=100)

775 à 675 (=100)

675 à 575 (=100)

575 à 475 (=100)

Je n'ai donc jamais dépassé les 100mv entre les tensions résultantes de l'UV

Ah je me trompais complètement alors ! Je pensais que l'on inscrivait les valeurs eu après testes et non le nombre de mV que l'on retire ! En plus j'aurai cru que de gauche à droite était du palier le plus bas au plus haut !

Merci pour ses rectifications qui vont me permettre de faire de bons testes.

Et 10% de perdu sur 24h, c'est vraiment un gros gain de batterie !

Effectivement, la carte se connecte et déconnecte dès lors qu'on le branche à un PC. Encore j'avais peur que ça venait de mon câble pourri.. Cela entraîne un plantage du script pendant le connexion mais après il se remet normalement ?

Modifié 9 mars 2012 par Yamuto

[Xkz]

Étant donné qu'avec le kernel@1.6GHz de Clemsyn, les pas ont pour diff 100mA, je ne peux qu'avoir un u/v de -50mA à chaque pas.

Mais consommation d'environ 0.5 à 1%/h en veille, tout dépent des heures où se lance les sync.