Bug d'autonomie des Core duo, le point, Réactions à la news du 14-02-2006

[Lionel]

A plusieurs reprises nous vous avons relaté les soucis d'autonomie des portables à base de Core Duo (ici et là). En résumé, le simple fait de brancher un périphérique USB sur ces machine, leur ferait perdre environ 30% de la durée de fonctionnement sur batteries.
AnandTech revient sur le sujet et apporte de nouvelles informations.
-Tout d'abord, ce bug n'est pas propre aux machines à base de Yonah, mais globalement à tous les portables à base de Pentium M.
- Ce bug se manifeste dès que l'on branche un périphérique USB, même si ce dernier n'est pas en fonctionnement. Concrètement, il bloque le fonctionnement des systèmes d'économie d'énergie à la consommation la plus élevée, et ce, inutilement.
- Microsoft a publié pour Windows XP un patch qui résout partiellement le problème en attendant une solution plus définitive. S'il permet de récupérer l'autonomie perdue, il n'est pas parfait. Certains ordinateurs n'y sont pas sensibles, et une mise en veille de la machine le désactive. Il faut lors redémarrer pour en retrouver l'effet.

C'est malgré tout une bonne nouvelle, puisqu'il semble possible de contourner ce soucis matériel par voie logicielle. On peut-être certain qu'Apple s'y applique et que bientôt nous pourrons connaître l'autonomie théorique des MacBook Pro.

[dulrich]

Ce n'est pas qu'un problème de driver... C'est un problème qui vient du couple driver-chipset. Les portables PC ont depuis plusieurs années de l'USB2, mais le problème n'est présent que depuis peu... c'est pas pour rien ! Windows supporte depuis longtemps l'USB2 également.

Je ne serais pas étonné de savoir qu'Apple a exactement le même problème avec ses drivers... qui doivent très probablement faire exactement les mêmes choses que celui de Windows...

[Ghoun aux os sec...]

Ce n'est pas qu'un problème de driver... C'est un problème qui vient du couple driver-chipset. Les portables PC ont depuis plusieurs années de l'USB2, mais le problème n'est présent que depuis peu... c'est pas pour rien ! Windows supporte depuis longtemps l'USB2 également.

Je ne serais pas étonné de savoir qu'Apple a exactement le même problème avec ses drivers... qui doivent très probablement faire exactement les mêmes choses que celui de Windows...

C'est un problème de driver... apparament codé avec les pieds
Un driver USB maitre est quelque chose d'assez compliqué (voir même carrément ignoble).
Mes connaissaces en USB (1, pas 2) sont assez vielles, mais il y a en gros un tas de machines d'états dont le but est de gérer le réseau, l'ajout / retrait de nouveaus composants devices, etc...

Lorsque la machine fonctionne et communique sur l'USB, ce driverérifier est largement occupé. Lorsque la machine est en veille, normalement, plus rien ne passe par l'USB, donc ce driver devrait être au repos.

Pour communiquer avec un périphérique, le logiciel a 2 solutions (je simplifie) :
- La gestion par interruptions : le chip de gestion USB informe le processeur via une ligne physique que des données sont prêtes à être traitées. Si le proc est en mode veuille, il repart et lance le bout de code associé. Avantage : c'est très propre, rapide, et consomme peut de ressources. Inconvénient : C'est parfois galère à coder, surtout avec windows et sa gestion déplorable du matèriel.

- Le polling : en gros on a une boucle soft qui tourne dans le vide et va lire des registres régulièrement, pour voir si par hasard on aurai pas besoin de lui : Avantage : C'est facile à coder. inconvénient : Ca consomme des ressources inutilement (mais bon, c'est windows...) et manque de bol, pour un portable, l'execution continue de code l'empeche de se mettre en veille.

C'est probablement ce qui se passe avec leur driver. En gros en mode veille, le processeur passe son temps à faire la séquence suivante :

"J'ai quelque chose à faire ?"
"A bin non, je reviendrais dans 10 ms"
"Toujours rien à faire ?"
"A bin non, je reviendrais dans 10 ms"

Du coup, pas de mode veille.

A moins que les ingés qui ont conçus le chipset USB2.0 soient vraiments des glands, le mode polling n'est absolument pas nécessaire. De plus, les ressources hardwares sont en général beaucoup mieux gérés sous un Unix que sous windows.

Il n'y a donc pas de raison pour que ce bug sous reproduise chez Apple, ou alors c'est qu'ils sont masochistes .

[dulrich]

Lorsque la machine fonctionne et communique sur l'USB, ce driverérifier est largement occupé. Lorsque la machine est en veille, normalement, plus rien ne passe par l'USB, donc ce driver devrait être au repos.

Pour être plus précis, l'USB ne supporte pas les interruptions... donc le polling (via l'hôte) est obligatoire. Quand un périphérique USB demande une interruption, il devra attendre que l'hôte l'interroge. Normalement ce polling devrait se faire au niveau du chipset et non au niveau software (est-ce ici le problème?).

Maintenant je sais aussi qu'il y a au moins deux modes de transmission de paquets, l'asynchrones et l'isochrone. Ce dernier permet de gérer les périphériques "temps réel" en effectuant des transactions régulières. Le premier est plus commun (clavier, souris) et ne nécessite qu'un polling "irrégulier".

De plus, les ressources hardwares sont en général beaucoup mieux gérés sous un Unix que sous windows.

Désolé, mais j'ai jamais vu les sources de Windows

Ce message a été modifié par dulrich - 14 Feb 2006, 18:56.

[Ghoun aux os sec...]

Lorsque la machine fonctionne et communique sur l'USB, ce driverérifier est largement occupé. Lorsque la machine est en veille, normalement, plus rien ne passe par l'USB, donc ce driver devrait être au repos.

Pour être plus précis, l'USB ne supporte pas les interruptions... donc le polling (via l'hôte) est obligatoire. Quand un périphérique USB demande une interruption, il devra attendre que l'hôte l'interroge. Normalement ce polling devrait se faire au niveau du chipset et non au niveau software (est-ce ici le problème?).

Maintenant je sais aussi qu'il y a au moins deux modes de transmission de paquets, l'asynchrones et l'isochrone. Ce dernier permet de gérer les périphériques "temps réel" en effectuant des transactions régulières. Le premier est plus commun (clavier, souris) et ne nécessite qu'un polling "irrégulier".

De plus, les ressources hardwares sont en général beaucoup mieux gérés sous un Unix que sous windows.

Désolé, mais j'ai jamais vu les sources de Windows

Désolé, je n'rrive pas à quoter par partie

Pour les interruptions : Les ITs générés pour la gestion d'une ressource matèrielle n'ont pas grand chose à voir avec la ressource en question, mais avec :
- Le chipset qui gère ce bus (en général tous sont très bien faits)
- Le logiciel.

Pour mémoire, j'ai vu des interfaces Ethernet (un peu exotiques, certes) tourner... en polling, parce que le gars qui avait routé la carte vait oublié le fil qui allait bien Je vous laisse deviner les performances hallucinates que ça donne.


Pour les drivers : Il suffit de voir le bordel que c'est pour en coder un sous windows et la simplicité sous Linux. J'ai jeté vaguement un oeuil pour Darwin, ça a l'air assez structuré.