Alors que nous étions en pleines séances de test d'autonomie sur nos différentes machines, qui ont du coup pris un peu de retard, nous avons pu noter un comportement pour le moins étrange du fameux G73Jh d'Asus.Celui-ci exploite un Core i7 720QM, qui, comme l'indique ARK dispose d'une fréquence comprise entre 1.6 et 2.8 GHz. Sa fréquence au repos, ou LFM (Low Frequency Mode) est, elle, de 933 MHz comme l'indique ce document.
Asus G73Jh : sous les 25 % de batterie restante, le CPU passe à 532 MHz !
Une fréquence en dessous de laquelle le processeur ne devrait pas être capable de descendre. Mais d'après nos constatations (via CPU-Z), il lui arrive d'atteindre 532 MHz (4x 133 MHz). Ce changement d'état ne se fait que lorsque l'on est sur batterie et que la capacité restante de cette dernière est inférieure à... 25 % ! Cette procédure n'est pas vraiment nouvelle, puisque beaucoup de constructeurs l'emploient pour éviter une extinction trop rapide lorsque la batterie arrive à son terme. Par exemple, l'Acer 7751G, que nous avons utilisé lors de notre test express du Phenom II X4 N930 force sa fréquence à 800MHz lors des cinq derniers pourcents de batterie alors qu'il peut dévorer les cellules à fond de train sans problème le reste du temps.
Un BIOS 209 qui corrige les bugs... et un 211 qui améliore les choses ?
Là où nous avons été étonnés avec le G73Jh, c'est qu'il l'utilise si tôt. D'ailleurs, ceux qui emploient un BIOS inférieur à la version 209 auront la mauvaise surprise de voir le processeur bloqué à cette fréquence réduite, et ce, même après avoir remis le chargeur en place. Le seul moyen de retrouver un fonctionnement normal de leur machine consiste en un redémarrage complet.
INterrogé sur le sujet, Asus nous a confirmé ce comportement, nous précisant qu'il était habituel et volontaire. L'argument principal soulevé étant la volonté d'éviter une extinction trop brutale, comme nous le disions précédemment. Néanmoins, il nous a été indiqué que la zone des 25 % allait être réduite. Précisons tout de même que d'après nos tests, ce portable n'offre qu'une autonomie d'une heure environ, avec une batterie de 75 Wh, et ce, avec cette baisse drastique de la fréquence, qui rend la machine totalement inutilisable.
Afin de le vérifier, ils nous ont fourni un BIOS en version 211 bêta censé améliorer les choses, mais il semble qu'il ne soit pas très au point. En effet, dès que l'on atteint les 25 % de batterie restante, notre Core i7 720QM plonge toujours à une fréquence de 532 MHz et ce qui devait être son dernier quart d'heure d'autonomie se transforme rapidement en une bonne vingtaine de minutes, pendant lesquelles il nous sera impossible d'effectuer la moindre tâche.
Limiter la fréquence CPU en fin de parcours : Acer et Medion aussi
Sans vouloir dédouaner Asus, sachez que ce comportement n'est pas unique et touche d'autres machines exploitant ce même processeur.
L'Akoya X7811 de Medion utilise pour sa part une autre méthode. Lorsque nous retirons le chargeur, la fréquence se bloque à 933MHz et il nous est impossible d'aller au-delà. Afin de savoir s'il s'agissait d'une modification logicielle ou matérielle, nous avons installé Ubuntu 10.04 qui reproduisait le même comportement, quel que soit le mode de gestion de l'énergie sélectionné.
Nous nous sommes alors rendus dans le BIOS afin de vérifier si une fonctionnalité permettait de retrouver un comportement plus normal. Mais bien que nous l'ayons fouillé de fond en comble, rien. Nous avons bien la possibilité de désactiver Speedstep, en charge de la modification de la fréquence à la volée du processeur, mais cela désactive du même coup sa fonction Turbo. Celui-ci reste donc constamment figé à 1.6 GHz seulement.
Un comportement qui semble limité aux gros transportables... T@LC à venir !
Enfin, nous noterons que ce comportement, dont l'implémentation semble largement différer selon les constructeurs, ne semble toucher que les gros transportables. Nous avons reproduit nos tests sur des machines utilisant des Pentium U5400 (Sony Y21), Core i3 350M (Asus K52Jr) ou Core i5 430M (Toshiba E205), sans rencontrer cette baisse forcée de la fréquence en fin de parcours.Nous tenterons de voir avec d'autres machines si nous arrivons à reproduire d'autres comportements du genre et mettons en place un test spécifique pour les débusquer... ce qui fera l'objet d'un T@LC, qui sera publié sous peu.
