Chrome : Google se penche sur le bug entraînant le vidage des batterie

Le par  |  4 commentaire(s) Source : Forbes
Chrome_logo.GNT

Cela fait des années qu'un bug opère sous silence dans chrome, le navigateur de Google sans que la firme ne prenne le temps de s'en occuper. Ce sera pourtant prochainement le cas, et les utilisateurs de PC portables devraient s'en réjouir.

Cela fait des années que Chrome est touché par un bug qui provoque une surconsommation d'électricité sur les PC Windows sur lesquels il est installé. Le problème a été repéré il y a peu par Ian Morris qui a constaté que Chrome utilisait de façon inappropriée le mécanisme d'attribution des ressources sous Windows, comparé aux autres OS.

Chrome-ancien-logoEn théorie, Windows fait appel à une minuterie pour programmer des tâches, en veille ( quand une application opère en tâche de fond), cette dernière est limitée à 15 ms. Si aucune tâche n'est à lancer, Windows se place en veille et ne relance une vérification qu'au bout de 15 ms. Les navigateurs comme Firefox ou Internet Explorer exploitent cette minuterie et sont capables de modifier le délai d'intervention...

Chrome a également accès à ce mécanisme, mais change automatiquement la minuterie à 1ms sans la réinitialiser, ce qui entraine une activité importante du processus, et un drain plus important de la batterie, notamment sur les dispositifs portables.

" Dans mon test, en veille, mon ordinateur utilise entre 15 et 20 watts avec Chrome en marche. Si je ferme Chrome, j'obtiens une consommation d'énergie qui varie entre 12 et 15 watts ! " indique celui qui a découvert le problème.

Attiré sur le sujet, Google a indiqué reconnaitre le problème et se mettre à la tâche pour le résoudre rapidement au travers d'une mise à jour. En réalité, il apparait que le bug avait été repéré depuis septembre 2012, et signalé par des utilisateurs. Il aura fallu que Ian Morris, contributeur de Forbes rende l'affaire publique et use du poids de son groupe de presse pour que Google se décide finalement à agir.

Google avait alors indiqué qu'il ne s'agissait pas d'un bug, mais d'un choix afin de rendre Chrome plus performant ( plus réactif en réalité). D'ailleurs ce choix est partagé par quelques plug-ins ainsi que Flash, du moins, par le passé.

Dans l'attente du correctif, si vous utilisez Chrome depuis un portable, vous devriez veiller à bien l'éteindre afin d'économiser votre batterie.

Complément d'information

Vos commentaires

Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Le #1800682
Et si on met le timer à 0, ça plante en saturant ou en jouant la belle aux bois dormant ? J'adore l'architecture de Windows et cette manière d'attribuer les fautes a ceux qui s'en servent.
Le #1800772
Dans le cas présent, c'est bien Google qui a voulu augmenter la réactivité de son navigateur, pas MS.

Je suis pas spécialement un défenseur de MS , .... mais bon, faut pas pousser quand même ...

Même sous linux, si tu es en root, tu peux modifier suffisamment le système .... pour qu'il ne redémarre pas !!! Donc, ...
Le #1801592
frèzetagada a écrit :

Dans le cas présent, c'est bien Google qui a voulu augmenter la réactivité de son navigateur, pas MS.

Je suis pas spécialement un défenseur de MS , .... mais bon, faut pas pousser quand même ...

Même sous linux, si tu es en root, tu peux modifier suffisamment le système .... pour qu'il ne redémarre pas !!! Donc, ...


Il y a peut être une légère différence entre un hacker qui bidouille un OS en root et Mme Michu qui installe un navigateur sur son PC, sans trop savoir ce quelle fait. Sans présumer de la perversion de Mme Michu, évidement.
Le #1803427
Ce timer de 15ms est préhistorique, il existait déjà au tempe de MSDOS; et même avant Microsoft avec IBM PCDOS. A cette époque pourtant les proceseurs allaient 1000 fois mois moins vite (horloges qu'une poignée de mégahertz et non poignée de gigahertz), et la moins instruction sur le processeur nécessait plusieurs cycles d'horloge (au lieu d'1 seul la plupart du temps dans les processeurs modernes à pipelines multiples, et des dizaines en plus pour accéder à la RAM quand il n'y avait pas encore de cache interne dan les SPU) et ils n'avaient qu'un seul coeur.
Bref toutes les 15ms on ne pouvait pas faire grand chose le code devait être ultrasimplifié pour détecter s'il y a quelque chose à faire et sinon retourner très vite à l'application pour la laisser poursuivre son activité.
Aujourd'hui passer de 15ms à 1ms ce timer n'est pas un problème, mais ce qui a changé c'est la complexité du code exécuté toute les 15 ms qui peut gérer de nombreuses files d'attente d'événements.
De tout temps ce timer a servi à synchroniser le multimédia (par exemple préparer un bloc de données audio; ou contrôler la vitesse de lecture d'une vidéo ou animation, ou historquement aussi dans les premiers OS "multitâches" pour permettre de prendre la main sur un processus ou un thread et basculer au processus et thread suivant afin qu'ils aient chacun du temps CPU pour tourner, ou pour faire du "polling" afin de voir si une I/O est terminée et réveiller un processus en sommeil).
Passer à 1ms devrait être la valeur par défaut sous Windows. Mais ici le problème est que Google a mis trop de code dans son gestionaiire d'interruption et qu'il n'est pas optimal pour gérer ses propres files d'attente. Et bien souvent ce code n'est même pas nécessaire car il existe des méthodes plus précises pour contrpoler les délais jusqu'à la milliseconde ou même la nanoseconde, ne nécessitant pas qu'un code de polling à intervalle régulier soit en place: le code sera réveillé juste au bon moment par une gestion plus fine des sources d'interruption (qui sont bien plus nombreuses sur les CPU actuels que les 15 interruptions historiques, dont les 4 interruptions PCI et la préhistorique interruption du clavier ou des ports COM; les périphériques PCI notamment ont un accès direct pour controler les bus et coordonner leurs demandes et s'activer les uns les autres sans nécessiter le moindre code.

Bref le diagnostic n'est pas le bon: l'abaissement de l'interruption de 15ms à 1ms n'est pas gênant, c'est juste que par paresse das Chrome, Google n'a pas voulu utiliser les timer multimédia de Windows et qu'il utilise encore la méthode paresseuse du polling. Que ce timer soit à 15ms ou 1mx ne change pas le fait que c'est une faon paresseuse de faire.

Chrome a envie de réactivité de son interface pour deux types de choses:
- les événements de l'utilsateur frappe clavier, déplacement souris, lire les données des ports USB des périphériques de saisie
- le controle de l'animation et du rafraichissment des tampons audio

Dans les deux cas il n'a pas besoin d'utiliser cette horloge de polling régulier. Et Il n'en a certainement pas besoin non lus pour réagir aux événements du réseau comme l'arrivée d'une trame ou la complétion d'un envoi de données.
Il semble que Chrome utilise ça dans son noyau Javascript qui ne sait pas utiliser des événements programmés, et des I/O asynchrones pourtant présentes deupis longtemps dan Windows.

Windows a pourtant une API bien fichue pour les I/O asynchrones, dont WaitForMultipleEvents(). Reste à Chrome de l'utiliser en utilisant les handles d'événements, et ne plus faire de pollign du tout!


Suivre les commentaires
Poster un commentaire
Anonyme
:) ;) :D ^^ 8) :| :lol: :p :-/ :o :w00t: :roll: :( :cry: :facepalm:
:andy: :annoyed: :bandit: :alien: :ninja: :agent: :doh: :@ :sick: :kiss: :love: :sleep: :whistle: =]