
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 !

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.

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.

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 !

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.