Vous l’avez peut-être remarqué, les dernières versions de macOS Sierra n’affichent plus l’estimation du temps de fonctionnement sur la batterie. Mais saviez-vous que l’estimation en question avait quelques biais ?
Une estimation souvent fausse
Ce post (en anglais) donne pas mal d’informations sur l’efficacité énergétique des derniers MacBook Pro et explique aussi que l’estimation… reste une estimation. La solution d’Apple – dont les sources sont disponibles – fonctionnait de façon assez simple en mesurant la consommation à un instant t et en extrapolant sur la capacité restante. Ce n’est pas efficace pour deux raisons : premièrement, ça nécessite des mesures très fines de la consommation. Deuxièmement, les puces actuelles changent très rapidement de fréquence et la consommation peut donc varier énormément en quelques millisecondes. Typiquement, si le logiciel mesure au moment ou le processeur fonctionne au maximum, avec Turbo activé, l’autonomie estimée va être très basse, même si le CPU basse au minimum 0,1 seconde plus tard. Comme la mesure n’est pas permanente, l’autonomie faussée va être affichée pendant un certain temps (par exemple 1 minute) avant de passer (ou pas) sur une valeur plus proche de la vérité.
Le second problème de l’autonomie vient des biais des utilisateurs. Il en existe au moins deux. Le premier, c’est que macOS ment sur le pourcentage de la batterie. La différence est faible, mais induit un biais : le système peut estimer une autonomie variable alors que la jauge reste à 100 %. Le second, beaucoup plus pernicieux, vient de l’idée que nous nous faisons de la consommation d’une machine. Si vous prenez un utilisateur au hasard, il va sûrement répondre que la bureautique/surf consomme peu et que la vidéo ou les jeux vidéo consomment beaucoup, spécialement un jeu en 3D. Dans la pratique, c’est une erreur : lire une vidéo sur Netflix ou via QuickTime consomme généralement moins que surfer. Globalement, sur une machine récente, le décodage vidéo du H.264 (le codec le plus courant) est pris intégralement en charge par un composant dédié et optimisé, qui consomme très peu. Donc avec un logiciel qui utilise les composants (pas Flash ou, dans une moindre mesure, VLC), la consommation est très faible. A contrario, une vidéo en Flash, un site rempli de JavaScript qui fait énormément d’accès au réseau (au hasard, Facebook) ou un « petit » jeu en HTML5 consommeront énormément d’énergie (parfois au moins autant qu’un jeu en 3D). De même, le choix du navigateur a un impact certain sur la consommation (Safari garde l’avantage, malgré des lacunes ergonomiques).
La limite artificielle des 10 ou 20 heures
Le truc amusant vu dans l’article vient de l’estimation qui, selon le code source, ne peut pas dépasser 10 heures. Alors, il se trompe : le code actuel limite à 20 heures, la valeur de la variable a été modifiée. Mais le commentaire d’origine, qui indique 10 heures, est resté sans modifications.
// Cap all times remaining to 10 hours. We don't ship any
// 44 hour batteries just yet.
En vérifiant dans le code de Mac OS X, la limitation date de Leopard (elle n’existe pas sous cette forme sous Tiger) et est passée à 20 heures à partir de Snow Leopard, dans une mise à jour (10.6.3). Le passage coïncide avec l’arrivée des premiers Mac donnés avec 10 heures d’autonomie (MacBook et MacBook Pro 13 pouces en 2010).
Et sous Sierra ?
Petite astuce sous Sierra : l’estimation reste visible dans le Moniteur d’activité, onglet Energie. Avec les biais classiques.
Sous Sierra
