Guide de conception
Ce guide de conception de la gestion thermique des PC fournit des informations sur la façon de déterminer les valeurs de température du PC qui sont « trop chaudes » et « trop froides ».
La réalisation de ces déterminations est une exigence clé pour une conception qui offre une bonne expérience utilisateur sur PC. De plus, ces seuils permettent de choisir la première action d’atténuation à entreprendre pour les composants de PC qui résident dans plusieurs zones thermiques.
Conception des seuils de température
Variables et hypothèses
Les facteurs suivants influencent le comportement thermique d’un PC :
Conception matérielle
L’importance d’une bonne conception matérielle ne peut pas être sur-soulignée. Pour plus d’informations, consultez Modélisation et évaluation thermiques matérielles.
Environment
Il s’agit de facteurs externes qui contribuent au comportement thermique du système. Le logiciel ne peut influencer l’environnement qu’en informant l’utilisateur que les contraintes thermiques sont un problème, par exemple en affichant le logo de défaillance thermique au démarrage. L’utilisateur doit passer à un autre environnement pour que ces facteurs changent :
Rayonnement solaire
L’intensité et l’angle de la lumière du soleil impactant l’écran ou n’importe quelle partie du système.
Température ambiante
Température de l’environnement.
Ventilation
Avec ou sans circulation d’air. Venteux ou dans un cas d’ordinateur.
Humidité
Sec ou humide.
Charge de travail et consommation électrique
L’hypothèse ici est que la charge de travail et la consommation d’énergie sont proportionnelles l’une à l’autre. En d’autres termes, plus un PC ou un composant fait de travail, plus il consomme d’énergie et plus il génère de la chaleur. Bien que cela ne soit pas vrai dans tous les cas, ce modèle simplifié est plus ou moins suffisant ici. C’est là qu’interviennent les atténuations logicielles. En réduisant la charge de travail, moins de chaleur est générée et le PC continue de fonctionner.
Lors de la conception et de la modélisation du matériel, prenez en compte les paramètres mentionnés dans la liste précédente. Utilisez les valeurs les plus défavorables pour l’environnement. Le seul paramètre qui peut être directement contrôlé par le logiciel est la charge de travail.
Notions de base thermiques
Considérez le comportement thermique d’un PC lorsqu’il exécute une charge de travail constante. Au démarrage de la charge de travail, les composants matériels du PC, tels que le processeur et le GPU, génèrent de la chaleur et augmentent la température. À mesure que la température augmente par rapport à la température ambiante, le PC commence à dissiper la chaleur plus rapidement jusqu’à ce que la production de chaleur soit finalement égale à la dissipation de la chaleur et que la température atteigne un état stable. Pour toute la durée de cette charge de travail constante, étant donné qu’aucune limitation n’est impliquée, les performances et le débit sont constants.
Le diagramme suivant montre la relation entre la génération de chaleur, la température et les performances quand aucune limitation n’est impliquée. Notez que la température du PC reste dans l’enveloppe thermique, telle qu’elle est limitée par la température ambiante et la température de limitation.
À présent, considérez le comportement thermique d’un PC lorsqu’il exécute une charge de travail différente qui est également constante, mais qui nécessite plus de ressources. À mesure que cette charge de travail s’exécute, la chaleur générée est beaucoup plus élevée que ce que le système est capable de se dissiper dans l’environnement ambiant, et par conséquent, la température augmente régulièrement. Sans refroidissement passif, la température continuera d’augmenter jusqu’à ce que le système devienne trop chaud et nuise au confort et à la sécurité de l’utilisateur final. Le matériel peut également être endommagé à des températures élevées. La limitation thermique permet de s’assurer que le PC n’atteint pas ces températures élevées. Lorsque la température augmente au-dessus d’un point d’écart de température de limitation prédéfini, le système commence à limiter les performances. Par conséquent, la production de chaleur est réduite et progressivement, une fois la production de chaleur et la dissipation égales, la température du système atteint l’état stable.
Le diagramme suivant montre la relation entre la production de chaleur, la température et les performances lorsque les performances sont limitées pour réduire la production de chaleur.
Dans les deux cas indiqués dans les diagrammes précédents, les charges de travail doivent fonctionner dans une enveloppe thermique pour s’assurer que la température du système ne dépasse pas les limites de sécurité. L’enveloppe commence par la température ambiante et se termine par la température de limitation. Aussi dans les deux cas, la production de chaleur et la dissipation finissent par atteindre un état équilibré, et la température du système est stabilisée.
Définition d’une enveloppe thermique
Un PC bien conçu doit avoir une enveloppe thermique aussi grande que possible, offrant aux utilisateurs une expérience durable et sans atténuation. Comme indiqué dans les diagrammes précédents, l’enveloppe thermique a une limite inférieure déterminée par la température ambiante. Elle est limitée au-dessus par la température de limitation. Bien que la température ambiante ne soit pas une variable que les concepteurs système peuvent contrôler, la limite supérieure peut être poussée plus haut par une bonne conception matérielle. Pour plus d’informations, consultez Modélisation et évaluation thermiques matérielles. Mais même en supposant que le matériel n’est pas la principale limitation, d’autres facteurs importants doivent être pris en compte lors de la définition de l’enveloppe thermique.
La plage de fonctionnement souhaitée doit être aussi grande que possible sans empiéter sur ces facteurs limitatifs :
Safety
La température du système doit d’abord s’assurer que les utilisateurs ne souffrent pas de blessures dues à l’utilisation du système. Cette exigence s’applique principalement au capteur de température de la peau.
Protection du matériel
La température doit empêcher les composants du système de « fondre » ou de causer des dommages dus à la chaleur. Cette exigence s’applique principalement aux capteurs de température des composants, par exemple un capteur qui se trouve sur le processeur.
Réglementation gouvernementale
Tous les systèmes doivent respecter les normes de l’industrie applicables (par exemple, IEC 62368) pour la sécurité de l’électronique grand public.
Modélisation et évaluation thermiques matérielles
Logiciel en complément de la conception matérielle
Lors de la conception de matériel, il est essentiel de garder à l’esprit la gestion thermique. La sélection de pièces à faible puissance, le placement de composants chauds loin les uns des autres et l’incorporation d’une isolation thermique ne sont que quelques exemples de la façon dont le matériel peut améliorer considérablement l’expérience thermique. Ces méthodes ne peuvent pas être remplacées dans les logiciels. Par conséquent, la solution logicielle ne sert que de complément à la conception matérielle dans l’expérience thermique globale.
Objectif matériel
Les charges de travail classiques ne doivent avoir besoin d’aucune forme d’atténuation thermique logicielle pour s’exécuter. La conception thermique du matériel doit être en mesure de disperser la chaleur pour ces charges de travail par elle-même.
Modélisation
La modélisation est un processus itératif permettant d’atteindre l’objectif matériel décrit précédemment. Dans ce processus, ne tenez pas compte des atténuations logicielles. S’appuyer uniquement sur les fonctionnalités matérielles et les ajuster en fonction des besoins.
Définissez une charge de travail standard. Selon la plateforme du système, du téléphone au serveur, chaque système doit avoir un ensemble standard de charges de travail standard. Il ne s’agit pas de charges de travail intenses telles que la vidéoconférence HD, mais plutôt d’une charge de travail plus moyenne comme la navigation sur le web ou l’écoute de musique.
Modélisez la consommation d’énergie du système et des composants individuels sur les charges de travail classiques, car la chaleur ne sera pas répartie uniformément sur le châssis. Portez une attention particulière aux composants qui consomment le plus d’énergie, comme le processeur.
En fonction de l’estimation de la consommation d’énergie de la charge de travail, modélisez l’augmentation de la température des composants et de la peau au fil du temps.
Ajustez la conception mécanique du système pour vous assurer que la température du composant est dans la limite de sécurité matérielle et de confort de l’utilisateur sur toutes les températures ambiantes. Voici quelques méthodes permettant de résoudre les problèmes de conception mécanique :
- Améliorer la capacité de dissipation thermique en ajoutant de meilleurs matériaux conducteurs de chaleur.
- Augmentez la température delta entre la peau et la température interne en ajoutant des couches d’isolation.
Répétez les étapes 1 à 4 jusqu’à ce que l’opération soit satisfaite.
Générez le matériel et évaluez.
Evaluation
Pour chaque révision matérielle, une mesure de température et de puissance par rapport à des charges de travail représentatives doit être effectuée pour évaluer le comportement thermique, et la conception mécanique doit être modifiée en fonction des besoins.
Les étapes suivantes sont recommandées pour effectuer une telle évaluation thermique :
Définissez une matrice de test de mesure thermique :
- La matrice doit couvrir la température ambiante normale et maximale.
- La matrice doit inclure toutes les charges de travail classiques identifiées dans le cadre de la modélisation thermique, et pour chaque charge de travail, les données doivent être capturées pendant au moins une heure.
- La matrice doit être exécutée plusieurs fois sur plusieurs PC pour générer des résultats cohérents.
Pour chaque charge de travail définie dans la matrice de test, capturez les données suivantes :
- Données de consommation d’énergie du système et des composants.
- Données de température ambiante, interne et de température d’apparence.
- Traces logicielles pour détecter la limitation thermique, les métriques de performances et l’utilisation du processeur.
Les données de température de l’apparence et des composants indiquent directement la température maximale d’peau que le système peut atteindre et si cette température est acceptable. Réfléchissez à la quantité de marge thermique que le système peut avoir avant l’arrêt critique. Les données des métriques de performances aideront à déterminer si le système fournit les performances requises. Les données de trace enregistrées par le logiciel de limitation thermique indiquent le pourcentage de limitation thermique. Les données de consommation d’énergie et les données d’utilisation du processeur peuvent aider à déterminer les facteurs qui influencent les changements de température.
Le tableau suivant fournit un exemple de collecte de données de ce type pour un PC avec la configuration suivante :
Configuration
- Nom de la machine : Thermal-Test-1
- Température ambiante moyenne : 23oC
- Point d’excursion de zone thermique (_PSV) : 80oC
Category | Sous-catégorie | Téléchargement vidéo | Jeux occasionnels | Fishbowl | Jeux 3D | TDP |
---|---|---|---|---|---|---|
Configuration de la charge de travail | Streaming vidéo H.264 720p en plein écran via Wi-Fi | Nom du jeu Utilisation du processeur |
Internet Explorer classique avec 100 poissons | Nom du jeu Utilisation du processeur |
PROCESSEUR et GPU 100 % | |
Consommation énergétique | Alimentation du système | |||||
Alimentation du SoC | ||||||
Afficher l’alimentation | ||||||
Rétroéclairage | ||||||
Température | Température maximale du SoC | |||||
Température maximale de la peau | ||||||
Mesures de performances | Fréquence d’images moyenne | Fréquence d’images moyenne | Fréquence d’images moyenne | Fréquence d’images moyenne |
Infrastructure de gestion thermique Windows
L’infrastructure de gestion thermique Windows fournit une solution complète pour la gestion thermique logicielle. Les exemples suivants montrent comment implémenter la gestion thermique. Avec une modélisation thermique, une validation et une conception mécanique thermique efficace, tous les systèmes doivent être en mesure d’offrir une expérience utilisateur fluide sur la plupart des charges de travail sur les températures ambiantes les plus ciblées. Lorsque l’atténuation thermique est nécessaire, Windows fournit une architecture de gestion thermique efficace et extensible.
La gestion thermique Windows prend en charge le refroidissement actif et passif. Avec le refroidissement actif, les ventilateurs s’allument pour faire circuler l’air et aider à refroidir le système. Avec le refroidissement passif, les appareils réduisent les performances des appareils en réponse à des conditions thermiques excessives. La réduction des performances réduit la consommation d’énergie et génère donc moins de chaleur.
L’infrastructure de gestion thermique Windows s’appuie sur les stratégies spécifiées par les concepteurs de système pour appliquer la gestion thermique sur le système. À un niveau élevé, les concepteurs doivent spécifier la façon dont la lecture obtenue à partir de chaque capteur thermique est affectée par chaque composant. Sans ces spécifications, Windows ne peut pas gérer thermiquement le système. Il est donc de la responsabilité de chaque concepteur de système de caractériser son système thermiquement afin d’obtenir une bonne conception thermique.
Bien que les systèmes ne soient pas obligés d’utiliser l’infrastructure de gestion thermique Windows, il s’agit de la solution recommandée en raison de son intégration étroite au système d’exploitation. Toutefois, quelle que soit la solution de gestion thermique utilisée, tous les PC de secours modernes doivent respecter les exigences HCK à des fins de diagnostic.
Architecture de gestion thermique
L’architecture de gestion thermique Windows est basée sur le concept ACPI de zones thermiques. Le modèle de zone thermique ACPI nécessite une coopération entre le microprogramme, le système d’exploitation et les pilotes. Ce modèle extrait les capteurs et les dispositifs de refroidissement du composant central de gestion thermique via des interfaces bien définies. Les améliorations apportées à la gestion thermique sont basées sur le chapitre 11 de la spécification ACPI 5.0. L’infrastructure de gestion thermique Windows implémente un sous-ensemble des fonctionnalités décrites dans ce chapitre.
Les composants essentiels du modèle sont les suivants :
- Définitions de zone thermique de plateforme décrites pour Windows via le microprogramme. Une zone thermique est une entité abstraite qui a une valeur de température associée. Le système d’exploitation surveille cette température afin qu’il puisse appliquer une atténuation thermique aux appareils de la zone. La zone contient un ensemble d’appareils fonctionnels qui génèrent de la chaleur et un sous-ensemble d’appareils dont la production de chaleur peut être contrôlée en ajustant les performances.
- Capteur de température qui représente la température de la région. Le capteur doit implémenter l’interface Read Temperature pour récupérer la température d’une zone à partir d’un microprogramme ou d’un pilote de température Windows.
- Interface de refroidissement thermique permettant aux pilotes d’appareils situés dans des zones thermiques d’implémenter des actions de refroidissement passif. Chaque pilote managé doit disposer de l’interface de refroidissement pour participer à l’infrastructure thermique Windows.
- Gestionnaire thermique centralisé qui orchestre le refroidissement en interprétant les définitions de zone thermique et en appelant les interfaces aux heures requises. Le gestionnaire thermique est implémenté dans le noyau Windows et ne nécessite aucun travail de la part des concepteurs système.
Le diagramme de blocs suivant présente une vue d’ensemble de l’architecture de gestion thermique Windows. Les composants main sont le gestionnaire thermique, la zone thermique, les pilotes gérés et le capteur de température. La zone thermique dicte le comportement de limitation de ses appareils managés en fonction des contraintes fournies par le gestionnaire thermique. L’algorithme utilisé par le gestionnaire thermique utilise la lecture de température du capteur pour la zone thermique comme paramètre d’entrée.
Les zones thermiques du système doivent être décrites dans le microprogramme ACPI et exposées au gestionnaire thermique via ACPI. Avec les informations de configuration, le gestionnaire thermique sait combien de zones thermiques doivent être gérées, quand commencer à limiter chaque zone thermique et quels appareils font partie de la zone. Pour surveiller la température, le concepteur de système prend en charge les notifications thermiques dans le microprogramme ACPI.
Lorsque le gestionnaire thermique est informé d’un événement thermique dans une zone énumérée, il commence à évaluer périodiquement la température de la zone et à déterminer le pourcentage de performance de limitation thermique à appliquer aux appareils de la zone thermique. Cette évaluation est effectuée par l’algorithme de limitation thermique décrit dans la spécification ACPI. Ensuite, le gestionnaire thermique avertit tous les appareils de la zone de limiter les performances d’un pourcentage spécifique et les pilotes de périphérique traduisent le pourcentage de limitation en une action spécifique à la classe d’appareil pour réduire les performances. L’évaluation et la limitation périodiques s’arrêtent lorsque la température de la zone thermique tombe en dessous du seuil de limitation et qu’aucune autre limitation n’est nécessaire.
Boucle de commentaires
Une autre façon de penser à l’architecture de gestion thermique est en termes d’entrées, de directeur de stratégie et d’appareils managés. Dans le diagramme de blocs suivant, les entrées de la boucle de rétroaction sont la température et le courant électrique. Ces entrées sont utilisées pour déterminer la stratégie thermique à implémenter. Le gestionnaire thermique s’appuie exclusivement sur l’entrée de température, et le pilote de stratégie peut utiliser l’entrée souhaitée. La zone thermique applique ensuite cette stratégie à ses pilotes managés. Une fois la stratégie appliquée, les capteurs mettent à jour leurs valeurs et ferment la boucle.
Le diagramme de blocs suivant montre les trois étapes du modèle de réponse thermique. Les entrées des capteurs de température et de courant électrique fournissent des informations pour déterminer la stratégie thermique à appliquer. Cette stratégie est appliquée aux pilotes managés, ce qui affecte ensuite les lectures sur les capteurs. Le processus se répète dans une boucle de commentaires.
Responsabilités des implémenteurs système
Comme mentionné ci-dessus, un certain nombre de composants sont nécessaires pour disposer d’une solution thermique Windows complète. L’architecture de l’infrastructure thermique est spécifiquement conçue pour que les responsabilités du fournisseur de matériel et de l’intégrateur de système puissent être séparées.
Les composants requis pour les partenaires à implémenter sont les suivants :
Détecteurs
Les pilotes de capteur de température doivent être fournis par le fournisseur de matériel. Étant donné que les capteurs de température n’ont pas besoin de connaître les zones thermiques qui s’en appuient, leurs fonctionnalités doivent être standard pour différentes conceptions de plateforme. Les capteurs personnalisés pour les pilotes de stratégie, tels que les capteurs actuels, sont également de la responsabilité du fournisseur de matériel.
Zones thermiques
Les zones thermiques peuvent être définies par le fournisseur de matériel et/ou l’intégrateur système. Tous les systèmes doivent avoir au moins une zone thermique qui implémente une température d’arrêt critique (et une température de mise en veille prolongée, si prise en charge), ce qui peut être effectué par le fournisseur de matériel ou l’intégrateur système. Toutefois, pour d’autres zones thermiques qui surveillent des appareils spécifiques ou la température de la peau à des fins d’atténuation, il est courant que l’intégrateur de système ait une connaissance plus spécifique du comportement thermique du système. Ainsi, ces zones thermiques sont généralement implémentées par l’intégrateur système.
Interface de refroidissement thermique pour les pilotes de périphérique
Le développeur qui écrit le pilote pour l’appareil qui doit être géré thermiquement doit également être celui qui implémente l’interface de refroidissement. Le pilote de périphérique utilise cette interface pour choisir l’infrastructure de gestion thermique. Les pilotes de périphérique ont une connaissance spécifique des fonctionnalités de leurs appareils. Ces mêmes pilotes doivent implémenter l’interface de refroidissement thermique afin qu’elle puisse interpréter correctement les actions demandées par la zone thermique.
Capteurs
Les capteurs fournissent des entrées pour déterminer quelle doit être la stratégie thermique. Windows prend uniquement en charge les capteurs de température comme entrées dans le gestionnaire thermique. Toutefois, un pilote de stratégie peut également prendre des entrées de pilotes personnalisés, tels qu’un pilote de capteur actuel.
Capteur de température
Le capteur de température fournit les modes de fonctionnalité suivants :
- Surveille en permanence les changements de température sans intervention du gestionnaire thermique ou de la zone thermique.
- Avertit le gestionnaire thermique lorsque la température dépasse le seuil défini par _PSV, _HOT ou _CRT.
- Répond aux requêtes de température et retourne la valeur de température actuelle.
Le diagramme suivant montre comment la surveillance de la température fonctionne pendant la limitation. Le microprogramme ACPI ou le pilote du capteur de température doit informer le gestionnaire thermique lorsque la température atteint un seuil prédéfini, tel que _PSV, _HOT ou _CRT, puis répondre aux requêtes périodiques du gestionnaire thermique pour la température actuelle. La période de la requête de température est définie par _TSP.
Pour vous assurer que le gestionnaire thermique sera toujours averti lorsque la température dépasse le seuil, l’interruption du capteur de température doit toujours être en éveil (même lorsque le système est en veille moderne et que le SoC est dans un état de faible puissance). Si l’interruption du capteur de température n’est pas toujours compatible avec le réveil, au moins l’interruption doit être configurée comme déclenchée au niveau pour éviter les pertes d’interruption potentielles.
Un capteur thermique peut être utilisé par plusieurs zones thermiques, bien qu’il ne puisse pas y avoir plus d’un capteur thermique dans une zone thermique.
Nous recommandons que le matériel du capteur soit précis à +/- 2oC.
La température signalée par _TMP ou un pilote de capteur de température peut être la valeur réelle d’un capteur ou une valeur extrapolée basée sur plusieurs capteurs.
Cela est généralement fourni par le fournisseur de matériel. Windows prend en charge deux implémentations pour la surveillance de la température :
- Pilote de capteur de température
- Basé sur l’ACPI
Implémentation 1 : pilote de capteur de température
Le pilote du capteur de température signale simplement la température du capteur. Le pilote ACPI émettra un IOCTL en suspens avec le conducteur du capteur pour détecter un croisement de l’un des points de trajet. En outre, l’ACPI peut émettre un IOCTL sans délai de lecture de la température actuelle. Le pilote de capteur doit gérer l’annulation de la lecture IOCTL, si elle est annulée en attendant l’expiration du délai d’expiration. Le capteur de température doit implémenter l’interface suivante :
typedef struct _THERMAL_WAIT_READ {
ULONG Timeout;
ULONG LowTemperature;
ULONG HighTemperature;
} THERMAL_WAIT_READ, *PTHERMAL_WAIT_READ;
#define IOCTL_THERMAL_READ_TEMPERATURE\
CTL_CODE(FILE_DEVICE_BATTERY, 0x24, METHOD_BUFFERED, FILE_READ_ACCESS)
Le tableau suivant décrit les paramètres d’entrée et de sortie pour l’interface de lecture de température.
Paramètre | Description |
---|---|
Délai d'expiration | Délai d’attente avant de retourner les données de température, en millisecondes. 0 indique que la température doit être lue immédiatement, sans attendre. -1 indique que la lecture ne doit pas expirer. |
LowTemperature | Seuil inférieur pour retourner la nouvelle température. Dès que la température descend en dessous du seuil de basse température, le pilote doit terminer l’IOCTL. Si la température est déjà inférieure à la basse température, l’IOCTL doit être effectué immédiatement. |
HighTemperature | Seuil supérieur de retour de la nouvelle température. Dès que la température dépasse le seuil de température haute, le pilote doit terminer l’IOCTL. Si la température est déjà supérieure à la température élevée, l'IOCTL doit être complété immédiatement. |
Valeur de retour IOCTL | Mémoire tampon de sortie de taille ULONG qui retourne la température actuelle, en dixièmes de degré Kelvin. |
Un capteur de température peut être utilisé par une zone thermique ou plusieurs zones thermiques. Pour spécifier le capteur de température à utiliser pour une zone thermique, le _DSM thermique doit être spécifié sur la zone thermique et doit implémenter la fonction 2. (Pour une compatibilité descendante, le pilote du capteur de température peut être chargé au-dessus de la pile de zones thermiques. Toutefois, l’implémentation recommandée consiste à séparer le pilote de capteur de la pile de zones thermiques.) Cette _DSM est définie comme suit :
ArgumentsArg0 : UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1 : Révision = 0 Arg2 : Fonction = 2 Arg3 : Un package vide Retourne une seule référence à l’appareil qui retournera la température de la zone thermique.
La zone thermique doit également spécifier une dépendance sur le capteur de température avec _DEP. Voici un exemple simple pour _DSM implémentation d’un appareil de capteur.
Device(\_SB.TSEN) {
Name(_HID, "FBKM0001") // temperature sensor device
}
ThermalZone(\_TZ.TZ01) {
Method(_DSM, 0x4, NotSerialized){
Switch (ToBuffer(Arg0)) {
Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
Switch (ToInteger(Arg2)) {
Case(0) {
// _DSM functions 0 and 2 (bits 0 and 2) are supported
Return (Buffer() {0x5})
}
Case (2) {
Return ("\_SB.TSEN")
}
}
}
}
}
Method(_DEP) {
Return (Package() {\_SB.TSEN})
}
// Other thermal methods: _PSV, etc.
}
Pour plus d’informations, consultez Méthode spécifique à l’appareil pour les extensions thermiques Microsoft.
Implémentation 2 : basée sur ACPI
Le microprogramme ACPI doit prendre en charge _TMP et notifier 0x80, comme défini dans la spécification ACPI. L’avantage de cette approche est qu’elle ne nécessite pas l’installation de pilotes supplémentaires sur le système. Toutefois, cette approche se limite à l’interaction avec les ressources accessibles via les régions d’opération ACPI.
Contrôle de la stratégie thermique
Zone thermique
Une zone thermique est une entité de limitation thermique individuelle. Il a ses propres caractéristiques de limitation thermique, telles que les points de trajet, le taux d’échantillonnage de limitation et les constantes d’équation de limitation. Une zone thermique peut inclure plusieurs dispositifs de limitation thermique, chacun d’entre eux pouvant contribuer à l’augmentation de la température dans la zone thermique. Tous les appareils de la même zone thermique doivent respecter les mêmes contraintes appliquées à la zone thermique.
Pour s’assurer que les zones thermiques et leurs paramètres sont définis avec précision, les concepteurs de système doivent :
- Identifiez les points chauds dans le châssis du système et déterminez comment ces points chauds dissipent la chaleur vers les capteurs de température. (Dans l’idéal, les capteurs thermiques se trouvent aux points chauds du système, à l’exception des capteurs de température de la peau.)
- Caractérisez la relation de température du système. Mapper les lectures du capteur de température à la température du composant et à la température de l’apparence.
Seuil de dépassement
À partir de Windows 10, une nouvelle fonctionnalité appelée état de zone thermique a été introduite dans la gestion thermique de Windows, avec un état : overthrottled. Lorsqu’une zone thermique dépasse le niveau de limitation conçu par l’appareil, le gestionnaire thermique informe les composants du système d’exploitation que le système est dépassé. Cette notification permet au système de réduire la charge de travail pour améliorer l’état thermique.
Le gestionnaire thermique conserve un compte global du nombre de zones thermiques qui sont à l’état surtrotté. Lorsque le nombre augmente au-dessus de zéro (0), le gestionnaire thermique envoie une notification WNF (Windows Notification Facility) au système, indiquant qu’il est surtrotté. Lorsque le nombre de zones surthrottées revient à zéro (0), le gestionnaire thermique envoie une autre notification WNF au système, indiquant qu’il n’y a pas de zones surtrottées.
Pour spécifier le seuil de dépassement d’une zone thermique, le _DSM thermique doit être spécifié sur la zone thermique, avec la fonction 3 implémentée. Cette _DSM est définie comme suit :
ArgumentsArg0 : UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1 : Révision = 0 Arg2 : Fonction = 3 Arg3 : Un package vide Retourne une valeur Integer avec le seuil de dépassement actuel, exprimé en pourcentage.
Voici un exemple _DSM qui indique que la zone est surtrottée, à des niveaux de limitation de 0 % à 49 %.
ThermalZone (TZ4) {
Name (_HID, "QCOM24AE")
Name (_UID, 0)
Name(_TZD, Package (){\_SB.CPU4, \_SB.CPU5, \_SB.CPU6, \_SB.CPU7})
Method(_PSV) { Return (3530) }
Name(_TC1, 1)
Name(_TC2, 1)
Name(_TSP, 1)
Name(_TZP, 0)
// _DSM - Device Specific Method
// Arg0: UUID Unique function identifier
// Arg1: Integer Revision Level
// Arg2: Integer Function Index (0 = Return Supported Functions)
// Arg3: Package Parameters
Method(_DSM, 0x4, NotSerialized) {
Switch (ToBuffer(Arg0)) {
Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
Switch (ToInteger(Arg2)) {
Case(0) {
// _DSM functions 0 and 3 (bits 0 and 3) are supported
Return (Buffer() {0x9})
}
Case (3) {
Return (50) // overthrottled below 50%
}
}
}
}
}
} // end of TZ4
Le seuil de dépassement est réexétré lors de la réception d’une notification(0x81) en référence à la zone thermique.
Implémentation d’objets ACPI
Le tableau suivant répertorie tous les objets ACPI qui doivent être implémentés dans le microprogramme ACPI pour définir une zone thermique.
Category | Méthode de contrôle |
---|---|
Identifier les appareils contenus dans la zone |
|
Spécifier les seuils thermiques auxquels les actions doivent être effectuées |
|
Décrire le comportement de refroidissement passif |
|
Décrire le comportement de refroidissement actif |
|
Définir une stratégie de refroidissement actif/passif |
|
Limite de limitation minimale |
|
Température du rapport |
|
Notifier le gestionnaire thermique |
|
Spécifier l’appareil de capteur de température |
|
Limite de limitation minimale
La limite de limitation minimale est une méthode d’extension thermique Microsoft _DSM qui crée une limite inférieure pour _PSV demandé d’un appareil limité. En d’autres termes, il détermine dans quelle mesure une zone thermique limite les performances des appareils qu’elle contrôle. S’il est présent, la limitation minimale _DSM sera lue au démarrage et chaque fois que la zone thermique reçoit ACPI Notify (0x81). À chaque itération de l’algorithme de refroidissement passif, les éléments suivants sont utilisés pour calculer la modification de la limite de performances (DP) que le gestionnaire thermique applique aux appareils de la zone :
DP [%] = _TC1 × (Tn – Tn₋₁) + _TC2 × (Tn – Tt) Nous utilisons ensuite ce qui suit pour calculer la limite de performances réelle :
Pn = Pn₋₁ – DP Avec la limite de limitation minimale (MTL) implémentée, cette deuxième équation devient :
Pn = max(Pn₋₁ – DP, MTL) Pour spécifier la limite de limitation minimale pour une zone thermique, le _DSM thermique doit être spécifié sur la zone thermique, avec la fonction 1 implémentée. Cette _DSM est définie comme suit :
ArgumentsArg0 : UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1 : Révision = 0 Arg2 : Fonction = 1 Arg3 : Un package vide Retourne une valeur integer avec la limite de limitation minimale actuelle, exprimée en pourcentage.
Voici un exemple simple pour _DSM limiter la limitation de 50 %.
ThermalZone(\_TZ.TZ01) {
Method(_DSM, 0x4, NotSerialized) {
Switch (ToBuffer(Arg0)) {
Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
Switch (ToInteger(Arg2)) {
Case(0) {
// _DSM functions 0 and 1 (bits 0 and 1) are supported
Return (Buffer() {0x3})
}
Case (1) {
Return (50)
}
}
}
}
}
Gestionnaire thermique dans le noyau
Le gestionnaire thermique Windows est implémenté dans le cadre du noyau Windows. Il surveille la température de toutes les zones thermiques et applique la limitation thermique le cas échéant.
Chaque fois que le gestionnaire thermique interroge le pilote ACPI pour la température actuelle, il effectue un calcul sur le pourcentage de performances de limitation thermique qu’il doit appliquer à tous les dispositifs de limitation thermique dans la zone thermique. La limite thermique est évaluée et appliquée lorsque le seuil de refroidissement passif (_PSV) est dépassé et à chaque intervalle d’échantillonnage de température (_TSP) jusqu’à ce que la température soit refroidie en dessous et que la limite thermique revienne à 100 %. Le matériel doit détecter quand le _PSV a été dépassé et doit le signaler via une notification d’événement ACPI matérielle.
Algorithme de limitation thermique
L’algorithme de limitation thermique utilise l’équation suivante, qui est définie dans la spécification ACPI :
DP [%] = _TC1 × ( Tn – Tn₋₁ ) + _TC2 × (Tn – Tt) où
Tn = lecture de la température actuelle du capteur de température dans la zone thermique en dixièmes de degré Kelvin. Tn₋₁ = température de la lecture précédente. Tt = température cible en dixièmes de degré Kelvin (_PSV). DP = modification des performances requise. Il s’agit d’une valeur linéaire comprise entre 0 (entièrement limité) et 100 % (non dérottée), qui doit être appliquée à chaque appareil de refroidissement dans la zone. Cette équation décrit la boucle de rétroaction entre les changements de température et les performances de limitation. Dans chaque itération de la boucle, le delta de température entre les lectures de température actuelles et précédentes exige que les performances P diminuent de pourcentage dp. La valeur DP est la quantité de limitation thermique à appliquer. De nombreux appareils de refroidissement n’ont pas de réponse thermique linéaire aux atténuations du refroidissement. Dans ces appareils, la limite thermique indique à l’appareil la quantité de refroidissement nécessaire. Chaque appareil de refroidissement aura son propre mappage de cette valeur linéaire aux atténuations thermiques spécifiques à l’appareil. La limitation des performances des appareils réduit la consommation d’énergie et la production de chaleur, ce qui entraîne une baisse de la température.
Les deux constantes, _TC1 et _TC2, contrôlent la façon dont la limitation thermique est appliquée de manière agressive dans cette boucle de rétroaction. Plus la _TC1 est grande, plus la limitation thermique est agressive pour maintenir une température stable. Le plus grand _TC2 est, plus la limitation thermique est agressive est utilisée pour pousser la température près du point de trajet.
Le tableau suivant fournit un exemple de la façon dont le gestionnaire thermique calcule et applique le dp. Cet exemple utilise les valeurs de paramètre suivantes :
Configuration
- _PSV = 325oK
- _TC1 = 2
- _TC2 = 3
- _TSP = 5 000 millisecondes
- Supposons que la température augmente continuellement de 1 degré toutes les 5 secondes.
La colonne la plus à droite du tableau suivant (intitulée P) indique le niveau de performance limité résultant de l’application des contraintes spécifiées par ces paramètres.
Itération | Temps | Amt | DP | P |
---|---|---|---|---|
1 | 0 seconde | 326oK | = 2 × 1 + 3 × 1 = 5 % | 95 % |
2 | 5 secondes | 327oK | = 2 × 1 + 3 × 2 = 8 % | 87 % |
3 | 10 secondes | 328oK | = 2 × 1 + 3 × 3 = 11 % | 76 % |
4 | 15 secondes | 320oK | = 2 × 1 + 3 × 4 = 14 % | 62 % |
5 | 20 secondes. | 330oK | = 2 × 1 + 3 × 5 = 17 % | 45 % |
... |
Pilote de stratégie
Par défaut, l’algorithme utilisé pour déterminer le pourcentage de limitation dicté par les spécifications ACPI est utilisé pour toutes les zones thermiques. Comme décrit précédemment, cet algorithme est basé uniquement sur le capteur de température attaché à la zone thermique, ce qui peut être limitatif.
Si un autre algorithme est préféré, le concepteur de système peut implémenter un pilote de stratégie pour incarner l’algorithme préféré. Un pilote de stratégie se trouve au-dessus de la pile de zones thermiques pour la zone qu’il contrôle. Pour cette zone, l’algorithme du pilote de stratégie peut être utilisé à la place de l’algorithme ACPI dans le gestionnaire thermique. L’algorithme du pilote de stratégie a la capacité de prendre en compte toutes les informations à laquelle il peut accéder en tant qu’entrée. Les décisions stratégiques prises par le conducteur sont transmises au gestionnaire thermique, qui consigne les informations et les transmet à la zone thermique pour effectuer.
L’utilisation d’un pilote de stratégie pour une zone thermique signifie que le pilote de stratégie (et non ACPI et non le système d’exploitation) est seul responsable du moment où limiter une zone et de la quantité.
Si un pilote de stratégie est présent, tous les points de trajet, toutes les constantes thermiques, la limite de limitation minimale, etc. sont complètement ignorés. Le système d’exploitation n’a aucune idée de la raison pour laquelle la zone thermique est définie à son niveau de limitation actuel. L’utilisation d’un pilote de stratégie au lieu d’une solution appropriée présente certains avantages. Un pilote de stratégie tire parti du processus intégré de limitation des périphériques. Tout ce qu’une zone thermique peut faire pour fournir une atténuation thermique peut être effectué par un pilote de stratégie. En outre, diagnostics pour la gestion thermique Windows sont automatiquement héritées.
L’interface de stratégie thermique a été mise à jour pour inclure un nouveau paramètre pour indiquer si la zone est surthrottée ou non. Ce paramètre est initialisé sur FALSE. Les anciens pilotes de stratégie ne sont pas conscients du nouveau paramètre, et les nouveaux pilotes savent que le nouveau paramètre est pris en charge lorsqu’ils détectent une version de stratégie de « 2 ».
#define TZ_ACTIVATION_REASON_THERMAL 0x00000001
#define TZ_ACTIVATION_REASON_CURRENT 0x00000002
#define THERMAL_POLICY_VERSION_1 1
#define THERMAL_POLICY_VERSION_2 2
typedef struct _THERMAL_POLICY {
ULONG Version;
BOOLEAN WaitForUpdate;
BOOLEAN Hibernate;
BOOLEAN Critical;
ULONG ActivationReasons;
ULONG PassiveLimit;
ULONG ActiveLevel;
BOOLEAN OverThrottled;
} THERMAL_POLICY, *PTHERMAL_POLICY;
Le pilote de stratégie peut indiquer que la zone thermique est surthrottée, en terminant la stratégie IOCTL avec le paramètre OverThrottled défini sur TRUE. Lorsque les conditions thermiques s’améliorent, le pilote de la stratégie thermique peut ensuite terminer l’IOCTL avec OverThrottled réinitialisé sur FALSE, pour indiquer que la zone thermique a récupéré. Windows n’exige pas que le pilote de stratégie soit limité lorsque l’indicateur overthrottle est défini.
Appareils gérés thermiquement
Les zones thermiques contrôlent le comportement thermique des appareils gérés via leurs pilotes en mode noyau. Un dispositif de limitation thermique peut résider dans plusieurs zones thermiques. Lorsque plusieurs zones thermiques demandent différents pourcentages de performances de limitation thermique, le gestionnaire thermique choisit le pourcentage de performances de limitation thermique minimal à appliquer au dispositif de limitation thermique.
De nombreux dispositifs de refroidissement n’ont pas de réponse thermique linéaire aux atténuations de refroidissement. Dans ce cas, la limite thermique indique à l’appareil le degré de refroidissement requis. Chaque appareil de refroidissement aura son propre mappage de cette valeur linéaire à ses atténuations thermiques spécifiques.
À mesure que chaque pilote de périphérique est chargé, ACPI interroge l’interface de refroidissement thermique et enregistre chaque appareil répondant en tant que périphérique de refroidissement. Plus tard, lorsque le refroidissement passif est en cours et que la limite thermique d’une zone a changé, ACPI appellera cette interface sur chaque appareil de refroidissement de la zone. Le dispositif de refroidissement mappe ensuite la limite thermique fournie à ses caractéristiques de refroidissement spécifiques et met en œuvre les mesures d’atténuation de refroidissement appropriées. Notez que si le dispositif de refroidissement apparaît dans plusieurs zones thermiques, la limite thermique qui limite le plus l’appareil (c’est-à-dire le pourcentage le plus faible) est passée à l’appareil.
Note Windows fournit des implémentations intégrées de la limitation thermique pour les processeurs, le rétro-éclairage et la batterie de la méthode de contrôle ACPI.
Interface de refroidissement thermique
Windows fournit les points d’extension permettant aux pilotes de périphérique de s’inscrire en tant que périphériques de limitation thermique et de recevoir la demande de pourcentage de limitation thermique. L’appareil est ensuite chargé de traduire ce pourcentage en une action logique pour lui-même.
Les appareils qui souhaitent être ajoutés en tant que dispositif de limitation thermique doivent d’abord ajouter les _HIDs dans la liste des appareils thermiques de zone thermique, puis implémenter l’ensemble d’interfaces suivant. À mesure que chaque pilote de périphérique est chargé, ACPI interroge cette interface et inscrit chaque appareil répondant en tant que périphérique de refroidissement. Plus tard, lorsque le refroidissement passif est en cours et que la limite thermique d’une zone a changé, ACPI appellera cette interface sur chaque appareil de refroidissement de la zone. Le dispositif de refroidissement mappe ensuite la limite thermique fournie à ses caractéristiques de refroidissement spécifiques et met en œuvre les mesures d’atténuation de refroidissement appropriées. Notez que si le dispositif de refroidissement apparaît dans plusieurs zones thermiques, la limite thermique qui limite le plus l’appareil (c’est-à-dire le pourcentage le plus faible) est passée à l’appareil.
//
// Thermal client interface (devices implementing
// GUID_THERMAL_COOLING_INTERFACE)
//
typedef
_Function_class_(DEVICE_ACTIVE_COOLING)
VOID
DEVICE_ACTIVE_COOLING (
_Inout_opt_ PVOID Context,
_In_ BOOLEAN Engaged
);
typedef DEVICE_ACTIVE_COOLING *PDEVICE_ACTIVE_COOLING;
typedef
_Function_class_(DEVICE_PASSIVE_COOLING)
VOID
DEVICE_PASSIVE_COOLING (
_Inout_opt_ PVOID Context,
_In_ ULONG Percentage
);
typedef DEVICE_PASSIVE_COOLING *PDEVICE_PASSIVE_COOLING;
typedef struct _THERMAL_COOLING_INTERFACE {
//
// generic interface header
//
USHORT Size;
USHORT Version;
PVOID Context;
PINTERFACE_REFERENCE InterfaceReference;
PINTERFACE_DEREFERENCE InterfaceDereference;
//
// Thermal cooling interface
//
ULONG Flags;
PDEVICE_ACTIVE_COOLING ActiveCooling;
PDEVICE_PASSIVE_COOLING PassiveCooling;
} THERMAL_COOLING_INTERFACE, *PTHERMAL_COOLING_INTERFACE;
#define THERMAL_COOLING_INTERFACE_VERSION 1
Processeur
Pour un processeur, le gestionnaire thermique communique le pourcentage de limitation thermique au gestionnaire d’alimentation du processeur (PPM). La limitation thermique des processeurs est une fonctionnalité intégrée de Windows.
Agrégateur de processeurs
L’appareil d’agrégateur de processeur permet le stationnement du cœur comme atténuation thermique. Les zones peuvent spécifier le stationnement principal en tant qu’atténuation thermique si l’appareil d’agrégateur de processeur est membre d’une zone thermique. Il n’est pas nécessaire de limiter les processeurs pour que le stationnement du cœur se produise. Cette implémentation fonctionne en parallèle avec l’idling du processeur logique (LPI). Notez que cela est toujours soumis aux avertissements du stationnement principal. En particulier, tout travail affiniténé avec un cœur parqué entraîne l’exécution du cœur.
Device(\_SB.PAGR) {
Name(_HID, "ACPI000C")
}
ThermalZone(\_TZ.TZ01) {
Name(_TZD, Package() {"\_SB.PAGR"})
// Other thermal methods: _PSV, etc.
}
Graphismes
Pour qu’un pilote de miniport graphique tiers soit géré thermiquement, il doit interagir avec le pilote de port graphique Windows, Dxgkrnl.sys. Dxgkrnl.sys a l’interface de refroidissement thermique et transmet toutes les demandes de limitation dans la pile au pilote miniport. Il incombe au pilote du miniport de traduire la demande en une action spécifique à son appareil.
Le diagramme de blocs suivant montre l’architecture de la zone thermique qui contrôle le GPU.
Rétroéclairage
La réduction du rétro-éclairage peut améliorer considérablement les conditions thermiques sur une plateforme mobile. Windows recommande que pendant le fonctionnement, la luminosité d’affichage du système n’est jamais limitée thermiquement à moins de 100 nits.
Pour le contrôle du rétro-éclairage, le gestionnaire thermique communique le pourcentage de limitation thermique au pilote du moniteur, Monitor.sys. Monitor.sys décidera du paramètre de niveau de rétro-éclairage réel en fonction de cette entrée thermique et d’autres entrées dans Windows. Ensuite, Monitor.sys appliquez le paramètre de niveau de rétro-éclairage via ACPI ou le pilote d’affichage.
Notez que si la température de la zone thermique qui inclut le rétro-éclairage continue d’augmenter, le pourcentage de limitation thermique demandé peut finalement tomber à zéro pour cent. L’implémentation du niveau de rétro-éclairage dans ACPI ou le pilote d’affichage doit garantir que le niveau de luminosité minimal disponible pour les contrôles de performances est toujours visible pour les utilisateurs finaux.
Note Pendant son fonctionnement, la luminosité de l’affichage du système n’est jamais limitée thermiquement à moins de 100 nits.
Batterie
Un autre main source de chaleur dans le système est le chargement de la batterie. Du point de vue de l’utilisateur, la charge doit être réduite et même complètement arrêtée dans des conditions thermiques contraintes. Toutefois, la charge de la batterie ne doit pas être entravée dans les cas d’usage normaux.
Note Nous vous recommandons de ne pas limiter le chargement de la batterie pendant que le système est (1) inactif et dans la plage de température ambiante inférieure à 35oC, ou (2) dans toutes les conditions lorsque la température ambiante est inférieure à 25oC.
Le pilote miniclasse de la batterie de la méthode de contrôle Windows, Cmbatt.sys, utilise directement l’interface de refroidissement thermique, comme décrit ci-dessus. Le microprogramme est chargé de prendre en compte la limite thermique actuelle lors de l’utilisation de la charge. Une nouvelle méthode de contrôle ACPI est nécessaire pour définir la limite thermique pour la recharge. Cette méthode est implémentée en tant que méthode spécifique à l’appareil (_DSM), comme défini dans la spécification ACPI 5.0, section 9.14.1.
Pour appliquer le pourcentage de limitation thermique, Cmbatt.sys évaluez la méthode de contrôle Méthode spécifique de l’appareil (_DSM) pour demander au microprogramme ACPI de définir la limite thermique de charge. Dans la méthode de contrôle _DSM, un GUID est défini pour indiquer la limite thermique.
Arg # | Valeur | Description |
---|---|---|
Arg0 | 4c2067e3-887d-475c-9720-4af1d3ed602e | UUID |
Arg1 | 0 | Révision |
Arg2 | 1 | Fonction |
Arg3 | Valeur entière comprise entre 0 et 100 | Limite thermique pour le chargement de la batterie. Équivaut à un pourcentage calculé de limitation passive. |
Valeur retournée | N/A | Aucune valeur de retour |
Refroidissement actif
Du point de vue du système d’exploitation, une plateforme a deux stratégies qu’elle peut utiliser pour implémenter le contrôle du ventilateur :
Implémentez une ou plusieurs zones thermiques ACPI avec des points de déplacement actifs pour engager/désengager le ventilateur.
L’infrastructure thermique Windows prend en charge les appareils de refroidissement actifs à un niveau très simple. Le seul appareil pris en charge dans la boîte de réception est un ventilateur ACPI, et il ne peut être contrôlé qu’avec un signal activé/désactivé.
Implémentez une solution propriétaire pour contrôler le ventilateur (via des pilotes, un contrôleur incorporé, etc.).
Bien que Windows ne contrôle pas le comportement des solutions propriétaires pour les ventilateurs, Windows prend en charge les notifications de ventilateur à Thermal Manager pour toutes les implémentations, y compris les contrôleurs incorporés, afin que les informations de diagnostic et les données de télémétrie puissent être collectées. Ainsi, l’exposition du ventilateur au système d’exploitation est requise pour tous les PC de secours modernes et fortement recommandée pour tous les autres.
Notez que l’implémentation du refroidissement actif est complètement distincte des mesures d’atténuation du refroidissement passif décrites précédemment.
Contrôle du ventilateur par zone thermique ACPI
Windows prend en charge la définition de ventilateur basée sur l’état D ACPI 1.0. (Pour plus d’informations, consultez la spécification ACPI.) Ainsi, le contrôle est limité au ventilateur activé et désactivé. Le pilote du ventilateur est fourni dans le pilote WINDOWS ACPI, Acpi.sys.
- Le capteur de température lit que la température a traversé un point de trajet et émet Notify(0x80) sur la zone thermique associée.
- La zone thermique lit la température avec la méthode de contrôle _TMP et compare la température aux points d’arrêt actifs (_ACx) pour déterminer si le ventilateur doit être allumé ou désactivé.
- Le système d’exploitation place le ventilateur dans D0 ou D3, ce qui provoque l’activation ou la désactivation du ventilateur.
Le diagramme de blocs suivant montre le flux de contrôle d’un ventilateur contrôlé par une zone thermique ACPI.
Scope(\_SB) {
Device(FAN) {
Name(_HID, EISAID("PNP0C0B"))
// additional methods to turn the fan on/off (_PR0, etc.)
}
ThermalZone(TZ0) {
Method(_TMP) {...}
Name(_AC0, 3200)
Name(_AL0, Package() {\_SB.FAN})
}
}
Ventilateur à plusieurs vitesses dans ACPI
Pour obtenir plusieurs vitesses pour un ventilateur à l’aide d’ACPI 1.0, il existe deux options :
- La zone thermique peut contenir plusieurs « ventilateurs », lorsqu’il n’existe qu’un seul ventilateur physique. Avoir plus de « ventilateurs » sur à la fois se traduit par une vitesse de ventilateur plus rapide. Pour plus d’informations, consultez l’exemple de cette option dans la section 11.7.2 de la spécification ACPI 5.0.
- Lorsque le ventilateur est allumé, il peut décider lui-même à quelle vitesse tourner. Les systèmes avec des contrôleurs incorporés, par exemple, peuvent choisir cette option.
Solution propriétaire pour les ventilateurs
Windows doit être en mesure de détecter l’activité du ventilateur avec l’une ou l’autre implémentation. Lorsqu’une plateforme utilise le modèle thermique ACPI, Windows est responsable de l’activation et de la désactivation du ventilateur et sait donc déjà quand il est actif. Lorsqu’une solution propriétaire est utilisée pour contrôler le ventilateur, Windows doit être notifié que le ventilateur est en cours d’exécution. Pour ce faire, Windows prend en charge un sous-ensemble partiel des extensions de ventilateur ACPI 4.0, qui sont répertoriées dans le tableau suivant.
Fonctionnalité | Description | Prise en charge |
---|---|---|
_FST | Retourne la status du ventilateur. | Oui |
Notify(0x80) | Indique que le status du ventilateur a changé. | Oui |
_FIF | Retourne des informations sur l’appareil de ventilateur. | non |
_FPS | Retourne une liste des états de performances du ventilateur. | non |
_FSL | Définit l’état des performances du ventilateur (vitesse). | non |
Windows utilise l’objet _FST pour déterminer si le ventilateur est en cours d’exécution (champ de contrôle différent de zéro) ou désactivé (champ contrôle est égal à zéro). Windows prend également en charge Notify(0x80) sur l’appareil de ventilateur, ce qui indique que _FST a changé et doit être réévalué.
Un ventilateur qui implémente l’objet _FST n’a pas besoin de figurer dans la liste des appareils _ALx d’une zone thermique, mais il peut, en option, figurer dans cette liste. Cette option active une solution hybride dans laquelle un ventilateur est généralement contrôlé par un pilote tiers, mais peut être contrôlé par la zone thermique du système d’exploitation si le pilote tiers n’est pas installé. Si un ventilateur se trouve dans une liste d’appareils _ALx et est engagé par la zone thermique (placée dans D0), l’objet _FST est requis pour indiquer une valeur Control différente de zéro.
Pour tous les ventilateurs, Windows utilise l’algorithme suivant pour déterminer l’état du ventilateur :
- Si un ventilateur est en D0 (en raison d’un _ACx point de déplacement d’une zone thermique traversé), il est engagé.
- Si un ventilateur est en D3 et ne prend pas en charge les extensions ACPI 4.0, il est désengagé.
- Si un ventilateur est en D3 et prend en charge les extensions ACPI 4.0, le système d’exploitation case activée _FST champ Control pour une valeur différente de zéro pour voir si le ventilateur est engagé.
Exemple 1 : Contrôle du ventilateur matériel
Dans cet exemple, un ventilateur est contrôlé par un contrôleur incorporé.
- Le contrôleur incorporé décide de démarrer ou d’arrêter le ventilateur en fonction de son propre algorithme interne.
- Après avoir démarré ou arrêté le ventilateur, le contrôleur incorporé émet une notification (0x80) sur l’appareil du ventilateur.
- Le système d’exploitation évalue _FST et lit le nouvel état du ventilateur.
Le diagramme de blocs suivant montre le flux de contrôle d’un ventilateur contrôlé par un contrôleur incorporé.
L’exemple ASL suivant définit un appareil « FAN » qui peut notifier le système d’exploitation des modifications apportées à l’état du ventilateur :
Scope(\_SB) {
Device(FAN) {
Name(_HID, EISAID("PNP0C0B"))
Name(_FST, Package() {0, 0, 0xffffffff})
// \_SB.FAN.SFST called by EC event handler upon fan status change
Method(SFST, 1) {
// Arg0 contains the new fan status
Store(Arg0, Index(_FST, 1))
Notify(\_SB.FAN, 0x80)
}
}
// Omitted: EC event handler
}
Exemple 2 : Contrôle du ventilateur du pilote
Dans cet exemple, un pilote tiers contrôle le ventilateur.
- Le pilote décide de démarrer ou d’arrêter le ventilateur en fonction de son propre algorithme interne.
- Le pilote modifie l’état du ventilateur et évalue une méthode de contrôle personnalisée (SFST) sur son appareil thermique.
- La méthode de contrôle de l’appareil thermique met à jour le contenu _FST de l’appareil de ventilateur et les problèmes Notify(0x80) sur le ventilateur.
- Le système d’exploitation évalue _FST et lit le nouvel état du ventilateur.
Le diagramme de blocs suivant montre le flux de contrôle d’un ventilateur contrôlé par un pilote tiers.
Scope(\_SB) {
Device(FAN) {
Name(_HID, EISAID("PNP0C0B"))
Name(_FST, Package() {0, 0, 0xffffffff})
}
Device(THML) {
Name(_HID, "FBKM0001")
Method(SFST, 1) {
// Arg0 contains the new fan status
Store(Arg0, Index(\_SB.FAN._FST, 1))
Notify(\_SB.FAN, 0x80)
}
}
}
Présence du ventilateur
Une plateforme indique qu’il existe un ventilateur sur le système en incluant un appareil de ventilateur (ID PnP PNP0C0B) dans l’espace de noms ACPI. Windows prend la présence de cet appareil comme une indication que le système dispose d’un ventilateur et l’absence de cet appareil comme une indication que le système n’a pas de ventilateur.
Conseils spécifiques à la veille moderne
L’infrastructure de gestion thermique Windows fait partie du noyau et est fournie avec tous les systèmes Windows. Par conséquent, le matériau ci-dessus s’applique à toutes les machines. Toutefois, différents types de machines nécessitent des conseils supplémentaires plus spécifiques à la veille moderne.
La veille moderne apporte le modèle d’alimentation du téléphone intelligent au PC. Il offre une expérience utilisateur instantanée et désactivée que les utilisateurs attendent sur leur téléphone. Et tout comme sur le téléphone, modern standby permet au système de rester frais, à jour et accessible chaque fois qu’un réseau approprié est disponible. Windows 10 prend en charge la veille moderne sur les plateformes à faible consommation d’énergie qui répondent à des exigences de certification Windows spécifiques.
Les PC de secours modernes sont des appareils très mobiles dans un facteur de forme mince et léger. En outre, les PC de secours modernes sont toujours activés et à l’état ACPI S0. Pour offrir une expérience client robuste et fiable, l’ensemble du système, de la conception mécanique à l’implémentation de microprogrammes et de logiciels, doit être conçu avec une attention critique aux caractéristiques thermiques. Ainsi, tous les PC de secours modernes doivent respecter les exigences thermiques.
Exigences de secours modernes
Tous les PC de secours modernes doivent réussir les tests HCK suivants :
- Tous les PC de secours modernes doivent avoir au moins une zone thermique pour laquelle une température d’arrêt critique (_CRT) est définie. Pour les systèmes x86, nous vous recommandons de définir une température de mise en veille prolongée critique (_HOT) pour déclencher l’enregistrement des données utilisateur. _HOT doit être inférieur à _CRT, et _CRT doit être inférieur au point de déclenchement thermique du microprogramme.
- Chaque zone thermique doit signaler la température réelle sur le capteur (_TMP). Le test exécute une charge de travail variable sur le PC, et la température devrait changer.
En outre, nous recommandons que chaque PC inclut au moins un capteur de température pour le SoC.
Exigences en matière de refroidissement actif
Les PC de secours modernes qui utilisent des ventilateurs doivent respecter les exigences supplémentaires suivantes, qui sont testées dans HCK :
- Le ventilateur doit être exposé au système d’exploitation. Pour plus d’informations, consultez Présence du ventilateur.
- Le système d’exploitation doit savoir à tout moment si le ventilateur est allumé ou désactivé. Même en cas de résilience au ralenti dans la veille moderne, toute modification de l’activité du ventilateur doit réveiller le SoC pour mettre à jour le status. Pour plus d’informations sur l’implémentation des notifications de ventilateur, consultez Contrôle du ventilateur par zone thermique ACPI.
- Le ventilateur ne doit pas s’allumer lorsque le PC est en veille moderne. Avec une charge de travail réaliste pendant la veille moderne, c’est-à-dire chaque fois que l’écran est éteint, le ventilateur ne doit pas s’allumer.
Du point de vue de l’utilisateur, le PC semble être désactivé lorsqu’il est en veille moderne. Les utilisateurs s’attendent à ce qu’un PC en veille moderne se comporte comme s’il était à l’état « veille » du système. Ainsi, les utilisateurs s’attendent à ce que le ventilateur ne s’allume jamais, comme dans les PC traditionnels pendant la veille. Si le ventilateur s’allume, les utilisateurs peuvent l’entendre et/ou sentir l’air chaud circuler et penser que l’ordinateur ne fonctionne pas correctement. Par conséquent, le ventilateur ne doit pas s’allumer en veille moderne. Pour plus d’informations sur le comportement requis, consultez Exigences de test HCK pour les PC de secours modernes.
Ces exigences impliquent que la stratégie de refroidissement lorsque l’écran est activé doit être différente de lorsque l’écran est désactivé. Le PC peut utiliser le refroidissement actif lorsque l’écran est allumé, mais il doit s’appuyer uniquement sur le refroidissement passif lorsque l’écran est éteint. Le point de déplacement actif du ventilateur peut être beaucoup plus bas lorsque l’écran est allumé que lorsqu’il est éteint. Pour l’implémentation d’ACPI, _ACx devrez être mis à jour lors de l’entrée en veille moderne. Pour les solutions propriétaires, veillez à mettre à jour la stratégie dans le contrôleur incorporé.
Limitation du processeur
Le PPM communique les niveaux de performances maximums, souhaités et minimaux au PEP. Dans des conditions de limitation thermique, le niveau de performance maximal doit être égal aux performances de limitation demandées par le gestionnaire thermique. Le PEP définit ensuite la tension physique et la fréquence du processeur en fonction des exigences de niveau de performances du PPM.
Signal de bruit du ventilateur
À partir de Windows 11, les appareils peuvent envoyer un signal de bruit du ventilateur au système d’exploitation pour une utilisation dans les décisions de gestion des ressources, dans le but de fournir aux utilisateurs une expérience cool et silencieuse. Cette interface d’adhésion permet au microprogramme d’envoyer des informations rpm de ventilateur au système d’exploitation sous la forme d’une valeur comprise entre 0 (ventilateur désactivé) et Max RPM, que le système d’exploitation peut utiliser dans les décisions de gestion des ressources pour refroidir l’appareil en fonction des besoins. Cela contribue à deux avantages majeurs :
- Expérience utilisateur silencieuse : Le bruit du ventilateur et le soufflage d’air chaud sont une source importante d’insatisfaction des clients. Cela est particulièrement vrai lorsque l’utilisateur ne s’attend pas à une forte activité du ventilateur, par exemple lorsque l’appareil exécute une faible quantité de travail ou qu’il n’y a pas de travail au premier plan.
- Amélioration de l’autonomie de la batterie : Les vitesses de ventilateur plus élevées entraînent une utilisation plus importante de l’alimentation, ce qui entraîne une décharge plus rapide de la batterie sur dc et une charge plus lente sur le secteur.
Actuellement, ce signal peut être utilisé pour gérer les tâches de l’indexeur de recherche, et il est prévu d’autoriser d’autres tâches en arrière-plan à consommer également ce signal.
Le diagramme suivant résume la façon dont le signal de bruit du ventilateur est envoyé dans les couches du microprogramme au logiciel.
Fonctionnement du signal de bruit du ventilateur
Détails de l’interface ACPI
Voici les quatre fonctions de méthode spécifique à l’appareil (_DSM, UUID : A7611840-99FE-41ae-A488-35C75926C8EB) utilisées pour prendre en charge cette fonctionnalité. Vous trouverez des informations sur _FST (état du ventilateur) dans la section 11.3.1.4 de la spécification ACPI et dans l’exemple 1 : Contrôle du ventilateur matériel des appareils gérés thermiquement
Le diagramme suivant résume le flux d’utilisation de ces fonctions.
Le diagramme de blocs suivant montre le flux de contrôle d’un ventilateur contrôlé par un contrôleur incorporé, y compris la méthode de contrôle Notify(0x80).
Notes
Le signal de bruit du ventilateur ne contrôle pas le rpm du ventilateur, mais avertit le système d’exploitation d’un bruit du ventilateur qui nécessite le déplacement de la ressource du processeur à partir des tâches en arrière-plan pour effectuer le travail prioritaire.
Énumérer les fonctions (fonction 0)
Pour que le système d’exploitation interagit avec la plateforme, un appareil ACPI doit être exposé via l’espace de noms. Cet appareil doit inclure un objet _CID contenant EISAID(« PNP0C0B »). L’étendue de cet appareil doit contenir la définition _DSM suivante indiquant les _DSMs pris en charge par l’appareil.
UUID | Révision | Fonction | Description |
---|---|---|---|
A7611840-99FE-41ae-A488-35C75926C8EB |
0 |
0 |
Énumérer les fonctions |
Retour: Pour indiquer la prise en charge des fonctions 0 à 3 répertoriées ci-dessus, la fonction Enumerate Functions (fonction 0) doit retourner 0xF. Pour plus d’informations, reportez-vous à la section 9.1.1 de la spécification ACPI.
Obtenir la fonction de prise en charge du point de déplacement du ventilateur (fonction 1)
Le matériel indique au système d’exploitation ce qui est pris en charge en termes de rpMs.
UUID | Révision | Fonction | Description |
---|---|---|---|
A7611840-99FE-41ae-A488-35C75926C8EB |
0 |
1 |
Obtenir la prise en charge des points de déplacement du ventilateur |
Arguments
Arg0 : UUID : A7611840-99FE-41ae-A488- 35C75926C8EB
Arg1 : Révision : 0
Arg2 : Fonction : 1
Arg3 : Un package vide
Retour: Valeur entière contenant la granularité prise en charge pour les points de déplacement du ventilateur, dans les rpm. S’il n’est pas égal à zéro, le système d’exploitation peut sélectionner des points de parcours qui sont un multiple de la granularité de notification. Par exemple, avec une granularité de 200, OSPM est autorisé à sélectionner des points de trajet à 0, 200, 400, 600, etc. Rpm. La valeur 0 indique que les points de trajet ne sont pas pris en charge.
Définir la fonction de points de déplacement du ventilateur (fonction 2)
Le système d’exploitation communique au matériel quel est le prochain point de parcours de notification ; le matériel avertit le système d’exploitation lorsque cela se produit.
UUID | Révision | Fonction | Description |
---|---|---|---|
A7611840-99FE-41ae-A488-35C75926C8EB |
0 |
2 |
Obtenir les points de déplacement des ventilateurs |
Arguments
Arg0 : UUID : A7611840-99FE-41ae-A488-35C75926C8EB
Arg1 : Révision : 0
Arg2 : Fonction : 2
Arg3 : Package contenant les points de trajet inférieur et supérieur. (2 élément int. Inférieur à l’index 0, supérieur à l’index 1)
OSPM sélectionne uniquement les points de trajet qui sont un multiple de la granularité de point de trajet spécifiée dans la fonction 1. Lorsque la vitesse réelle du ventilateur passe au-dessus ou en dessous des points de trajet supérieurs/inférieurs, la plateforme doit émettre Notify(0x80) sur l’appareil du ventilateur. OSPM évalue ensuite _FST (fan status) pour déterminer la vitesse actuelle du ventilateur. Si la vitesse du ventilateur est déjà en dehors des points de trajet spécifiés lorsque les points de trajet sont définis, la plateforme doit immédiatement émettre Notify(0x80).
Le point de déplacement supérieur est un multiple de granularité. Le point d’aller-retour inférieur est (multiple de granularité) + 1 (point d’aller-retour supérieur inférieur < ). Lorsque rpm est 0, le système d’exploitation définit le point de trajet inférieur sur 0 et le point de trajet supérieur sur 1.
Retour: Aucun.
Get Fan Operating Ranges Function (Function 3)
Mappage entre RPM –> Impact. Notez qu’un seul ventilateur (le plus proche du SoC) peut implémenter cette interface. Il doit implémenter les 3 fonctions plus la fonction 0 de la section 9.1.1 de la spécification ACPI.
UUID | Révision | Fonction | Description |
---|---|---|---|
A7611840-99FE-41ae-A488-35C75926C8EB |
0 |
3 |
Obtenir les plages de fonctionnement du ventilateur |
Arguments
Arg0 : UUID : A7611840-99FE-41ae-A488-35C75926C8EB
Arg1 : Révision : 0
Arg2 : Fonction : 3
Arg3 : Package vide.
Retour: Package contenant le format suivant :
Package () {
Impact1MaxRPM, // Integer (DWORD)
Impact2MaxRPM, // Integer (DWORD)
Impact3MaxRPM, // Integer (DWORD)
MaxRPM // Integer (DWORD)
}
Champ | Format | Description |
---|---|---|
Impact1MaxRPM |
Integer (DWORD) |
Nombre maximal de rpms pour la plage d’impact du ventilateur 1. |
Impact2MaxRPM |
Integer (DWORD) |
Nombre maximal de rpms pour la plage d’impact du ventilateur 2. Doit être >= Impact1MaxRPM. |
Impact3MaxRPM |
Integer (DWORD) |
Nombre maximal de rpms pour la plage d’impact du ventilateur 3. Doit être >= Impact2MaxRPM. |
MaxRPM |
Integer (DWORD) |
Nombre maximal de machines virtuelles que le ventilateur peut utiliser. Doit être >= Impact3MaxRPM. |
Cette table est utilisée pour dériver la plage RPM pour chacun des niveaux d’impact du ventilateur :
Score d’impact | Valeur RPM inférieure | Valeur RPM supérieure |
---|---|---|
1 |
1 |
Impact1MaxRPM |
2 |
Impact1MaxRPM + 1 |
Impact2MaxRPM. |
3 |
Impact2MaxRPM + 1 |
Impact3MaxRPM |
4 |
Impact3MaxRPM + 1 |
MaxRPM |
Si une plage d’impact n’est pas utilisée par une plateforme (par exemple, si le ventilateur passe directement de la plage d’impact 2 à la plage d’impact 4), cela peut indiquer cela en définissant le RPM maximal pour la plage d’impact inutilisée égale au RPM maximal pour la plage d’impact inférieure.
Exemple de mappage
Valeur envoyée au système d’exploitation | Rpm du ventilateur | Expérience de l'utilisateur | Plafond RPM |
---|---|---|---|
0 – Faible |
1 à 4 000 tr/min (<=25 dBA) |
Ventilateur non activé ou activé avec un faible ennui |
Impact1MaxRPM = 4000 |
1 – Moyen |
4001-5000 RPM (25-30 dBA) |
Ventilateur activé avec un agacement moyen |
Impact2MaxRPM = 5000 |
2 – Medium-High |
5001-6000 rpm (30-36 dBA) |
Ventilateur sur avec un agacement moyen-élevé |
Impact3MaxRPM = 6000 |
3 – Élevé |
6001+ RPM (36+ dBA) |
Ventilateur sur avec un agacement élevé |
MaxRPM = 9000 |
Exemple de code ASL
...
// _DSM - Device Specific Method
// Arg0: UUID Unique function identifier
// Arg1: Integer Revision Level
// Arg2: Integer Function Index (0 = Return Supported Functions)
// Arg3: Package Parameters
Method(_DSM, 0x4, NotSerialized) {
If(LEqual(Arg0, ToUUID("A7611840-99FE-41ae-A488-35C75926C8EB"))) {
Switch (ToInteger(Arg2)) {
Case(0) {
// _DSM functions 0 through 3 are supported
Return (Buffer() {0xf})
}
Case(1) {
// Report 200 RPM granularity for trip points
Return (\_SB.FAN0.GRAN)
}
Case(2) {
// Save lower RPM trip point
Store(DeRefOf(Index(Arg3, 0)), \_SB.FAN0.LRPM)
// Save upper RPM trip point
Store(DeRefOf(Index(Arg3, 1)), \_SB.FAN0.URPM)
// Configure hardware for the trip points, Tell EC to set fan speed trip point.
\_SB.FAN0.CRNF()
Return (0)
}
Case(3) {
Return (Package(4) {
4000, // 1-4000 RPM is impact score 1
5000, // 4001-5000 RPM is impact score 2
6000, // 5001-6000 RPM is impact score 3
9000})// 6001-9000 RPM is impact score 4
}
Default {
Return(Buffer(One) { 0x00 }) // Guid mismatch
}
}
}
Else {
Return(Buffer(One) { 0x00 }) // Guid mismatch
}
}
} // end of FAN0
}
Test et suivi
Reportez-vous aux étapes suivantes pour collecter le journal et l’affichage dans Windows Analyseur de performances (WPA) :
- Paramètres -> Recherche dans Windows -> Paramètres de l’indexeur de recherche avancée -> Avancé -> Supprimer et reconstruire l’index (Reconstruire)
- wpr -boottrace -addboot AcpiFanNoiseImpact.wprp –filemode
- Redémarrer le système
- Vérifiez index status des paramètres -> Recherche dans Windows (assurez-vous que l’appareil se connecte à la source d’alimentation CA).)
- Une fois l’index terminé, arrêtez la trace : wpr -boottrace -stopboot AcpiFanNoiseImpact.etl (Annuler la trace sans enregistrer : wpr -boottrace -cancel)
- Ouvrez AcpiFanNoiseImpact.etl via Windows Analyseur de performances (WPA).
Téléchargez le fichier à l'AcpiFanNoiseImpact.zip Or, copiez ce qui suit et enregistrez-le en tant que AcpiFanNoiseImpact.wprp
<?xml version="1.0" encoding="utf-8"?>
<WindowsPerformanceRecorder Version="1.0" Comments="Test" Company="Microsoft Corporation" Copyright="Microsoft Corporation">
<Profiles>
<!-- BufferSizes are in KB in WPRP -->
<!-- System Collectors -->
<SystemCollector Id="MySystemCollector" Name="NT Kernel Logger">
<BufferSize Value="1024" />
<Buffers Value="100" />
<StackCaching BucketCount="2048" CacheSize="20480" />
<FlushThreshold Value="70" />
</SystemCollector>
<!-- Event Collectors -->
<EventCollector Id="MyEventCollector" Name="User Session Logger">
<BufferSize Value="1024" />
<Buffers Value="100" />
<StackCaching BucketCount="2048" CacheSize="20480" />
<FlushThreshold Value="70" />
</EventCollector>
<!-- System Providers for collecting kernel events. -->
<SystemProvider Id="SP_AcpiFanNoiseImpactTrace">
<Keywords Operation="Add">
<Keyword Value="Loader" />
<Keyword Value="Power" />
<Keyword Value="ProcessThread" />
</Keywords>
</SystemProvider>
<!-- System Providers for collecting kernel events. -->
<!---->
<EventProvider Id="EP_Microsoft-Windows-Kernel-Power" Name="Microsoft-Windows-Kernel-Power" Level="5" NonPagedMemory="true">
<Keywords>
<Keyword Value="0x2" />
</Keywords>
<CaptureStateOnStart>
<Keyword Value="0x0" />
</CaptureStateOnStart>
<CaptureStateOnSave>
<Keyword Value="0x0" />
</CaptureStateOnSave>
</EventProvider>
<EventProvider Id="EP_Microsoft-Windows-Kernel-Acpi" Name="Microsoft-Windows-Kernel-Acpi" Level="5">
<Keywords>
<Keyword Value="0xffffffff" />
</Keywords>
<CaptureStateOnSave>
<Keyword Value="0xffffffff" />
</CaptureStateOnSave>
</EventProvider>
<EventProvider Id="CustomEventProvider_Microsoft.Windows.SRUM.Telemetry_TraceLogging" Name="7073707A-0587-4E03-B31F-6443EB1ACBCD" Level="5" />
<EventProvider Id="CustomEventProvider_Microsoft.Windows.Kernel.Acpi_TraceLogging" Name="C42BBFDB-4140-4ada-81DF-2B9A18AC6A7B" Level="5" />
<EventProvider Id="CustomEventProvider_Microsoft.Windows.Kernel.Power_TraceLogging" Name="63bca7a1-77ec-4ea7-95d0-98d3f0c0ebf7" Level="5" />
<EventProvider Id="CustomEventProvider_AcpiTraceGuid_WPP" Name="03906A40-CCE8-447F-83F4-E2346215DB84" Level="7" />
<EventProvider Id="CustomEventProvider_Microsoft.Windows.CentralResourceManager_TraceLogging" Name="8215e965-d26e-548e-af0e-940c1f06f250" Level="5" NonPagedMemory="true">
<CaptureStateOnSave>
<Keyword Value="0xFFFFFFFFFFFFFFFF" />
</CaptureStateOnSave>
</EventProvider>
<Profile Id="PowerTrace.Verbose.File" LoggingMode="File" Name="PowerTrace" DetailLevel="Verbose" Description="Power trace logging">
<Collectors>
<SystemCollectorId Value="MySystemCollector">
<SystemProviderId Value="SP_AcpiFanNoiseImpactTrace" />
</SystemCollectorId>
<EventCollectorId Value="MyEventCollector">
<EventProviders>
<EventProviderId Value="EP_Microsoft-Windows-Kernel-Power" />
<EventProviderId Value="EP_Microsoft-Windows-Kernel-Acpi" />
<EventProviderId Value="CustomEventProvider_Microsoft.Windows.Kernel.Acpi_TraceLogging" />
<EventProviderId Value="CustomEventProvider_AcpiTraceGuid_WPP" />
<EventProviderId Value="CustomEventProvider_Microsoft.Windows.Kernel.Power_TraceLogging" />
<EventProviderId Value="CustomEventProvider_Microsoft.Windows.SRUM.Telemetry_TraceLogging" />
<EventProviderId Value="CustomEventProvider_Microsoft.Windows.CentralResourceManager_TraceLogging" />
</EventProviders>
</EventCollectorId>
</Collectors>
</Profile>
</Profiles>
<TraceMergeProperties>
<TraceMergeProperty Id="TraceMerge_Default" Name="TraceMerge_Default" Base="">
<DeletePreMergedTraceFiles Value="true" />
<FileCompression Value="true" />
<CustomEvents>
<CustomEvent Value="ImageId" />
<CustomEvent Value="BuildInfo" />
<CustomEvent Value="VolumeMapping" />
<CustomEvent Value="EventMetadata" />
<CustomEvent Value="PerfTrackMetadata" />
<CustomEvent Value="WinSAT" />
<CustomEvent Value="NetworkInterface" />
</CustomEvents>
</TraceMergeProperty>
</TraceMergeProperties>
</WindowsPerformanceRecorder>
L’image ci-dessous est un exemple de graphique WPA montrant l’arrêt du travail de l’indexeur de recherche lorsque le ventilateur est fort.
Il existe un niveau du ventilateur qui ferait en sorte que l’index de recherche soit entièrement désactivé (le plus élevé, qui devrait être le score d’impact 4), mais tous les autres niveaux du ventilateur doivent être réduits en activité et non pas en suspension. Par exemple, si ACPI a déclaré Impact3MaxRPM = 4 000 RPM dans la fonction 3 (obtenir la fonction Obtenir les plages de fonctionnement du ventilateur), lorsque Fan RPM > 4000 (4100RPM, 4500RPM), nous voyons SearchIndexer.exe et SearchProtocalHost.exe utilisation du processeur serait suspendue.
Notes
Pour afficher l’utilisation du processeur, vous pouvez utiliser wpr -start power -filemode pour collecter l’utilisation du runtime. Utilisez wpr -stop fan_noise.etl pour arrêter la collecte du journal.
L’image ci-dessous montre un exemple de graphique WPA montrant la suspension de SearchIndexer.exe et SearchProtocolHost