Guía de diseño

Esta guía de diseño de administración térmica del equipo proporciona información sobre cómo determinar los valores de temperatura del equipo que se consideran "demasiado calientes" y "demasiado fríos".

La realización de estas determinaciones es un requisito clave para un diseño que ofrece una buena experiencia de usuario de PC. Además, estos umbrales ayudan a elegir la primera acción de mitigación que se debe realizar para los componentes del equipo que residen en varias zonas térmicas.

Diseño de los umbrales de temperatura

Variables y suposiciones

Los siguientes factores influyen en el comportamiento térmico de un equipo:

• Diseño de hardware

  La importancia del buen diseño de hardware no puede ser demasiado estresada. Para obtener más información, consulte Modelado térmico y evaluación de hardware.

• Entorno

  Estos son factores externos que contribuyen al comportamiento térmico del sistema. El software solo puede influir en el entorno notificando al usuario que las restricciones térmicas son un problema, por ejemplo, mostrando el logotipo térmico de error al arranque. El usuario debe pasar a un entorno diferente para que estos factores cambien:

  • Radiación solar

    Intensidad y ángulo de la luz solar que afecta a la pantalla o a cualquier parte del sistema.

  • Temperatura ambiente

    Temperatura del entorno.

  • Flujo de aire

    Con o sin circulación de aire. Windy o en un caso informático.

  • Humedad

    Seco o húmedo.

• Carga de trabajo y consumo de energía

  La suposición aquí es que el consumo de carga de trabajo y energía son proporcionales entre sí. En otras palabras, cuanto más funcione un equipo o componente, más potencia consume y más calor genera. Aunque esto podría no ser cierto en todos los casos, este modelo simplificado es más o menos suficiente aquí. Aquí es donde entran las mitigaciones de software. Al reducir la carga de trabajo, se genera menos calor y el equipo sigue funcionando.

Al diseñar y modelar el hardware, tenga en cuenta los parámetros mencionados en la lista anterior. Use los valores de peor caso para el entorno. El único parámetro que el software puede controlar directamente es la carga de trabajo.

Aspectos básicos térmicos

Considere el comportamiento térmico de un equipo cuando se ejecuta una carga de trabajo constante. A medida que se inicia la carga de trabajo, los componentes de hardware del equipo, como la CPU y la GPU, generan calor y aumentan la temperatura. A medida que aumenta la temperatura en relación con la temperatura ambiente, el EQUIPO comienza a disipar el calor más rápido hasta que la generación de calor es igual a la disipación de calor, y la temperatura alcanza el estado estable. Durante toda la duración de esta carga de trabajo constante, ya que no hay ninguna limitación implicada, el rendimiento y el rendimiento son constantes.

En el diagrama siguiente se muestra la relación entre la generación de calor, la temperatura y el rendimiento cuando no hay ninguna limitación implicada. Observe que la temperatura del equipo permanece dentro del sobre térmico, tal y como está limitada por la temperatura ambiente y la temperatura de limitación.

Ahora considere el comportamiento térmico de un equipo cuando se ejecuta una carga de trabajo diferente que también es constante, pero que consume más recursos. A medida que se ejecuta esta carga de trabajo, el calor generado es mucho mayor que lo que el sistema es capaz de disipar en el entorno ambiente y, como resultado, la temperatura aumenta constantemente. Sin refrigeración pasiva, la temperatura continuará aumentando hasta que el sistema se vuelva demasiado caliente y afecte negativamente a la comodidad y seguridad del usuario final. El hardware también puede dañarse a altas temperaturas. La limitación térmica ayuda a garantizar que el equipo no alcance estas altas temperaturas. Cuando la temperatura aumenta sobre un punto de viaje de temperatura de limitación predefinido, el sistema inicia el rendimiento de la limitación. Como resultado, la generación de calor se reduce y gradualmente ,después de la generación de calor y la disipación iguala, la temperatura del sistema alcanza el estado estable.

En el diagrama siguiente se muestra la relación entre la generación de calor, la temperatura y el rendimiento cuando se limita el rendimiento para reducir la generación de calor.

En ambos casos mostrados en los diagramas anteriores, las cargas de trabajo deben funcionar dentro de un sobre térmico para garantizar que la temperatura del sistema no supere los límites seguros. El sobre comienza con la temperatura ambiente y termina con la temperatura de limitación. Además, en ambos casos, la generación de calor y la disipación finalmente alcanzan un estado equilibrado, y la temperatura del sistema se estabiliza.

Definición de un sobre térmico

Un equipo bien diseñado debe tener lo más grande posible un sobre térmico, proporcionando a los usuarios una experiencia libre de mitigación y de larga duración. Como se muestra en los diagramas anteriores, el sobre térmico tiene un límite inferior determinado por la temperatura ambiente. Está limitado por encima de la temperatura de limitación. Aunque la temperatura ambiente no es una variable que los diseñadores del sistema pueden controlar, el límite superior puede ser empujado más alto por un buen diseño de hardware. Para obtener más información, consulte Modelado térmico y evaluación de hardware. Pero incluso suponiendo que el hardware no es la limitación principal, se deben tener en cuenta otros factores importantes al definir el sobre térmico.

El intervalo operativo deseado debe ser lo más grande posible sin interrumpir estos factores de limitación:

• Seguridad

  La temperatura del sistema debe asegurarse primero de que los usuarios no sufren lesiones por el uso del sistema. Este requisito se aplica principalmente al sensor de temperatura de la piel.

• Protección de hardware

  La temperatura debe impedir que los componentes del sistema "se derriten" o causen daños debidos al calor. Este requisito se aplica principalmente a los sensores de temperatura de componentes, por ejemplo, un sensor que se encuentra sobre el procesador.

• Regulación gubernamental

  Todos los sistemas deben cumplir los estándares aplicables del sector (como IEC 62368) para la seguridad electrónica de consumo.

Modelado y evaluación térmicas de hardware

Software como complemento al diseño de hardware

Al diseñar hardware, es fundamental tener en cuenta la administración térmica. La selección de piezas de bajo consumo, la colocación de componentes calientes lejos entre sí y la incorporación de aislamiento térmico son solo algunos ejemplos de cómo el hardware puede mejorar considerablemente la experiencia térmica. Estos métodos no se pueden reemplazar en el software. Por lo tanto, la solución de software solo sirve como complemento para el diseño de hardware en la experiencia térmica general.

Objetivo de hardware

Las cargas de trabajo típicas no deben necesitar ninguna forma de mitigación térmica de software para ejecutarse. El diseño térmico de hardware debe ser capaz de dispersar calor para estas cargas de trabajo por sí mismo.

Modelado

El modelado es un proceso iterativo para lograr el objetivo de hardware descrito anteriormente. En este proceso, no tenga en cuenta ninguna mitigación de software. Confíe únicamente en las funcionalidades de hardware y ajuste según sea necesario.

1. Defina una carga de trabajo típica. Según la plataforma del sistema, desde el teléfono al servidor, cada sistema debe tener un conjunto estándar de cargas de trabajo típicas. Estas no deben ser cargas de trabajo intensas, como videoconferencia hd, sino una carga de trabajo más media, como explorar la web o escuchar música.

2. El sistema de modelos y el consumo de energía de componentes individuales en cargas de trabajo típicas, ya que el calor no se distribuirá uniformemente en el chasis. Preste especial atención a los componentes que consumen la mayor parte de la potencia, como el procesador.

3. En función de la estimación del consumo de energía de la carga de trabajo, modele el aumento de la temperatura del componente y la piel a lo largo del tiempo.

4. Ajuste el diseño mecánico del sistema para asegurarse de que la temperatura del componente está dentro del límite de seguridad del hardware y el límite de comodidad del usuario sobre todas las temperaturas ambientales. Algunos métodos para solucionar problemas de diseño mecánico son:

   1. Mejore la capacidad de disipación de calor agregando mejores materiales de conducta térmica.
   2. Aumente la temperatura diferencial entre la piel y la temperatura interna agregando capas de aislamiento.

5. Repita los pasos del 1 al 4 hasta que se cumpla.

6. Compile el hardware y evalúe.

Evaluación

Para cada revisión de hardware, se debe realizar una medición de temperatura y potencia con cargas de trabajo representativas para evaluar el comportamiento térmico y el diseño mecánico debe modificarse según sea necesario.

Se recomiendan los pasos siguientes para realizar esta evaluación térmica:

1. Defina una matriz de pruebas de medición térmica:

   1. La matriz debe cubrir la temperatura ambiente normal y máxima.
   2. La matriz debe incluir todas las cargas de trabajo típicas identificadas como parte del modelado térmico y, para cada carga de trabajo, los datos deben capturarse durante al menos una hora.
   3. La matriz debe ejecutarse en varios equipos varias veces para generar resultados coherentes.

2. Para cada carga de trabajo definida en la matriz de pruebas, capture los datos siguientes:

   1. Datos de consumo de energía de componentes y del sistema.
   2. Datos de temperatura ambiente, componente interno y piel.
   3. Seguimientos de software para detectar la limitación térmica, las métricas de rendimiento y el uso del procesador.

Los datos de temperatura de la piel y componentes indican directamente la temperatura máxima de la piel que el sistema podría alcanzar y si esta temperatura es aceptable. Tenga en cuenta cuánto espacio térmico podría tener el sistema antes del apagado crítico. Los datos de métricas de rendimiento ayudarán a determinar si el sistema ofrece el rendimiento necesario. Los datos de seguimiento registrados por el software de limitación térmica muestran el porcentaje de limitación térmica. Los datos de consumo de energía y los datos de uso de cpu pueden ayudar a determinar qué factores influyen en los cambios de temperatura.

En la tabla siguiente se proporciona un ejemplo de esta recopilación de datos para un equipo con la siguiente configuración:

Configuración

• Nombre de la máquina: Thermal-Test-1
• Temperatura ambiente media: 23^oC
• Punto de viaje de zona térmica (_PSV): 80^oC

Category	Subcategoría	Streaming de vídeo	Juegos casuales	Pecera	Juegos 3D	TDP
Configuración de la carga de trabajo		Streaming de vídeo de 720p H.264 de pantalla completa a través de Wi-Fi	Nombre del juego Uso de CPU	IE clásico con 100 peces	Nombre del juego Uso de CPU	CPU y GPU 100 %
Consumo de energía	Alimentación del sistema
	Alimentación de SoC
	Mostrar energía
	Alimentación contrailuminación
Temperatura	Temperatura máxima de SoC
	Temperatura máxima de la piel
Métricas de rendimiento		Velocidad media de fotogramas	Velocidad media de fotogramas	Velocidad media de fotogramas	Velocidad media de fotogramas

Marco de administración térmica de Windows

El marco de administración térmica de Windows proporciona una solución completa para la administración térmica de software. En los ejemplos siguientes se muestra cómo implementar la administración térmica. Con el modelado térmico adecuado, la validación y el diseño mecánico térmico eficaz, todos los sistemas deben poder ofrecer una experiencia de usuario fluida en la mayoría de las cargas de trabajo en la mayoría de las temperaturas ambientales específicas. Cuando se requiere mitigación térmica, Windows proporciona una arquitectura de administración térmica eficaz y extensible.

La administración térmica de Windows admite refrigeración activa y pasiva. Con refrigeración activa, los ventiladores activan para circular el aire y ayudan a refrescar el sistema. Con la refrigeración pasiva, los dispositivos reducen el rendimiento de los dispositivos en respuesta a condiciones térmicas excesivas. Reducir el rendimiento reduce el consumo de energía y, por tanto, genera menos calor.

El marco de administración térmica de Windows se basa en las directivas especificadas por los diseñadores del sistema para aplicar la administración térmica en el sistema. En un nivel alto, los diseñadores deben especificar cómo la lectura obtenida de cada sensor térmico se ve afectada por cada componente. Sin estas especificaciones, Windows no puede administrar térmicamente el sistema. Por lo tanto, es responsabilidad de cada diseñador del sistema caracterizar su sistema térmicamente con el fin de lograr un buen diseño térmico.

Aunque los sistemas no son necesarios para usar el marco de administración térmica de Windows, es la solución recomendada debido a su estrecha integración con el sistema operativo. Sin embargo, independientemente de la solución de administración térmica utilizada, todos los equipos modernos en espera deben cumplir los requisitos de HCK para fines de diagnóstico.

Arquitectura de administración térmica

La arquitectura de administración térmica de Windows se basa en el concepto ACPI de zonas térmicas. El modelo de zona térmica ACPI requiere la cooperación entre el firmware, el sistema operativo y los controladores. Este modelo abstrae los sensores y los dispositivos de refrigeración del componente central de administración térmica a través de interfaces bien definidas. Las mejoras de gestión térmica se basan en el capítulo 11 de la especificación ACPI 5.0. El marco de administración térmica de Windows implementa un subconjunto de las funcionalidades descritas en este capítulo.

Los componentes esenciales del modelo son:

• Definiciones de zona térmica de plataforma descritas en Windows a través del firmware. Una zona térmica es una entidad abstracta que tiene un valor de temperatura asociado. El sistema operativo supervisa esta temperatura para que pueda aplicar la mitigación térmica a los dispositivos dentro de la zona. La zona contiene un conjunto de dispositivos funcionales que generan calor y un subconjunto de dispositivos cuya generación de calor se puede controlar ajustando el rendimiento.
• Sensor de temperatura que representa la temperatura de la región. El sensor debe implementar la interfaz Read Temperature para recuperar la temperatura de una zona del firmware o un controlador de temperatura de Windows.
• Una interfaz de refrigeración térmica para permitir que los controladores de los dispositivos de las zonas térmicas implementen acciones de refrigeración pasiva. Cada controlador administrado debe tener la interfaz de refrigeración para participar en la infraestructura térmica de Windows.
• Un administrador térmico centralizado que organiza la refrigeración interpretando las definiciones de zona térmica e invocando las interfaces en los momentos necesarios. El administrador térmico se implementa en el kernel de Windows y no requiere ningún trabajo de los diseñadores del sistema.

El siguiente diagrama de bloques es una introducción a la arquitectura de administración térmica de Windows. Los componentes principales son el administrador térmico, la zona térmica, los controladores administrados y el sensor de temperatura. La zona térmica dicta el comportamiento de limitación de sus dispositivos administrados en función de las restricciones proporcionadas por el administrador térmico. El algoritmo utilizado por el administrador térmico usa la lectura de temperatura del sensor para la zona térmica como parámetro de entrada.

Las zonas térmicas del sistema deben describirse en firmware ACPI y exponerse al administrador térmico a través de ACPI. Con la información de configuración, el administrador térmico sabe cuántas zonas térmicas deben administrarse, cuándo iniciar la limitación de cada zona térmica y qué dispositivos forman parte de la zona. Para supervisar la temperatura, el diseñador del sistema proporciona compatibilidad con el firmware ACPI para las notificaciones térmicas.

Cuando se notifica al administrador térmico un evento térmico en una zona enumerada, comenzará a evaluar periódicamente la temperatura de la zona y determinará el porcentaje de rendimiento de limitación térmica que se aplicará a los dispositivos de la zona térmica. Esta evaluación se realiza mediante el algoritmo de limitación térmica que se describe en la especificación ACPI. A continuación, el administrador térmico notifica a todos los dispositivos de la zona para limitar el rendimiento por un porcentaje específico y los controladores de dispositivo traducen el porcentaje de limitación a una acción específica de clase de dispositivo para reducir el rendimiento. La evaluación periódica y la limitación se detendrán cuando la temperatura de la zona térmica caiga por debajo de la temperatura del umbral de limitación y no se requiera más limitación.

Bucle de comentarios

Otra manera de pensar en la arquitectura de administración térmica es en términos de entradas, director de directivas y dispositivos administrados. En el diagrama de bloques siguiente, las entradas para el bucle de comentarios son la temperatura y la corriente eléctrica. Estas entradas se usan para determinar la directiva térmica que se va a implementar. El administrador térmico se basa exclusivamente en la entrada de temperatura y el controlador de directivas puede usar cualquier entrada que desee. A continuación, la zona térmica aplica esa directiva a sus controladores administrados. Una vez aplicada la directiva, los sensores actualizarán sus valores y cerrarán el bucle.

En el diagrama de bloques siguiente se muestran las tres fases del modelo de respuesta térmica. Las entradas de los sensores de temperatura y corriente eléctrica proporcionan información para ayudar a determinar qué directiva térmica se va a aplicar. Esta directiva se aplica a los controladores administrados, lo que afecta a las lecturas de los sensores. El proceso se repite en un bucle de comentarios.

Responsabilidades de los implementadores del sistema

Como se mencionó anteriormente, se requiere una serie de componentes para tener una solución térmica completa de Windows. La arquitectura del marco térmico está diseñada específicamente para que las responsabilidades del proveedor de hardware y el integrador de sistemas se puedan separar.

Los componentes necesarios para que los asociados implementen son:

• Sensores

  El proveedor de hardware debe proporcionar los controladores del sensor de temperatura. Dado que los sensores de temperatura no necesitan conocimiento de las zonas térmicas que dependen de ellas, sus funcionalidades deben ser estándar en diferentes diseños de plataforma. Los sensores personalizados para los controladores de directivas, como los sensores actuales, también son responsabilidad del proveedor de hardware.

• Zonas térmicas

  Las zonas térmicas se pueden definir mediante el proveedor de hardware o el integrador de sistemas. Todos los sistemas deben tener al menos una zona térmica que implemente una temperatura crítica de apagado (y temperatura de hibernación, si se admite), que el proveedor de hardware o el integrador del sistema pueden realizar. Sin embargo, para otras zonas térmicas que supervisan dispositivos específicos o la temperatura de la piel para la mitigación, es habitual que el integrador del sistema tenga conocimientos más específicos sobre el comportamiento térmico del sistema. Por lo tanto, estas zonas térmicas suelen ser implementadas por el integrador del sistema.

• Interfaz de refrigeración térmica para controladores de dispositivos

  El desarrollador que escribe el controlador para el dispositivo que se va a administrar térmicamente también debe ser el que implemente la interfaz de refrigeración. El controlador de dispositivo usa esta interfaz para participar en el marco de administración térmica. Los controladores de dispositivos tienen conocimientos específicos de las funcionalidades de sus dispositivos. Estos mismos controladores deben implementar la interfaz de refrigeración térmica para que pueda interpretar correctamente las acciones solicitadas por la zona térmica.

Sensores

Los sensores proporcionan entradas para determinar cuál debe ser la directiva térmica. Windows solo admite sensores de temperatura como entradas para el administrador térmico. Sin embargo, un controlador de directiva también puede tomar entradas de controladores personalizados, como un controlador de sensor actual.

Sensor de temperatura

El sensor de temperatura proporciona los siguientes modos de funcionalidad:

• Supervisa continuamente los cambios de temperatura sin la participación del administrador térmico o la zona térmica.
• Notifica al administrador térmico cuando la temperatura cruza el umbral definido por _PSV, _HOT o _CRT.
• Responde a las consultas de temperatura y devuelve el valor de temperatura actual.

En el diagrama siguiente se muestra cómo funciona la supervisión de temperatura durante la limitación. El firmware ACPI o el controlador del sensor de temperatura deben notificar al administrador térmico cuando la temperatura alcanza un umbral predefinido, como _PSV, _HOT o _CRT, y luego responder a las consultas periódicas del administrador térmico para la temperatura actual. El período de la consulta de temperatura se define mediante _TSP.

Para asegurarse de que el administrador térmico siempre recibirá una notificación cuando la temperatura supere el umbral, la interrupción del sensor de temperatura siempre debe ser capaz de reactivarse (incluso cuando el sistema está en espera moderna y el SoC está en estado de baja potencia). Si la interrupción del sensor de temperatura no siempre es capaz de reactivarse, al menos la interrupción debe configurarse como desencadenada por el nivel para evitar posibles pérdidas de interrupción.

Un sensor térmico puede ser utilizado por varias zonas térmicas, aunque no puede haber más de un sensor térmico en una zona térmica.

Se recomienda que el hardware del sensor sea preciso para +/- 2^oC.

La temperatura notificada por _TMP o un controlador de sensor de temperatura puede ser el valor real de un sensor o un valor extrapolado basado en varios sensores.

Normalmente, el proveedor de hardware proporciona esto. Windows admite dos implementaciones para supervisar la temperatura:

• Controlador del sensor de temperatura
• Basado en ACPI

Implementación 1: controlador del sensor de temperatura

El controlador del sensor de temperatura simplemente informa de la temperatura del sensor. El controlador ACPI emitirá un IOCTL pendiente con el controlador del sensor para detectar un cruce de uno de los puntos de viaje. Además, ACPI puede emitir un IOCTL sin tiempo de espera para leer la temperatura actual. El controlador del sensor debe controlar la cancelación del IOCTL de lectura, si se cancela mientras espera a que expire el tiempo de espera. El sensor de temperatura debe implementar la siguiente interfaz:

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)

En la tabla siguiente se describen los parámetros de entrada y salida de la interfaz de lectura de temperatura.

Parámetro	Descripción
Tiempo de espera	Tiempo de espera antes de devolver datos de temperatura, en milisegundos. 0 indica que la temperatura debe leerse inmediatamente, sin esperar. -1 indica que la lectura no debe agotar el tiempo de espera.
LowTemperature	Umbral inferior para devolver la nueva temperatura. Tan pronto como la temperatura caiga por debajo del umbral de temperatura baja, el controlador debe completar el IOCTL. Si la temperatura ya está por debajo de la temperatura baja, el IOCTL debe completarse inmediatamente.
HighTemperature	Umbral superior para devolver la nueva temperatura. Tan pronto como la temperatura aumente por encima del umbral de temperatura alta, el controlador debe completar el IOCTL. Si la temperatura ya está por encima de la temperatura alta, el IOCTL debe completarse inmediatamente.
Valor devuelto de IOCTL	Un búfer de salida de tamaño ULONG que devolverá la temperatura actual, en décimas de un grado Kelvin.

Un sensor de temperatura puede ser utilizado por una zona térmica o varias zonas térmicas. Para especificar qué sensor de temperatura debe utilizarse para una zona térmica, se debe especificar el _DSM térmico en la zona térmica y debe implementar la función 2. (Por motivos de compatibilidad con versiones anteriores, el controlador del sensor de temperatura se puede cargar sobre la pila de zona térmica. Sin embargo, la implementación preferida es que el controlador del sensor sea independiente de la pila de zonas térmicas). Este _DSM se define de la siguiente manera:

ArgumentosArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 2 Arg3: Un paquete vacío Devuelve una sola referencia al dispositivo que devolverá la temperatura de la zona térmica.

La zona térmica también debe especificar una dependencia en el dispositivo sensor de temperatura con _DEP. Este es un ejemplo sencillo para _DSM implementación de un dispositivo sensor.

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.

}

Para obtener más información, consulte Método específico del dispositivo para extensiones térmicas de Microsoft.

Implementación 2: basado en ACPI

El firmware ACPI debe admitir _TMP y notificar 0x80, tal como se define en la especificación ACPI. La ventaja de este enfoque es que no requiere que se instalen controladores adicionales en el sistema. Sin embargo, este enfoque se limita a interactuar con los recursos a los que se puede acceder a través de regiones de operación ACPI.

Control de directivas térmicas

Zona térmica

Una zona térmica es una entidad de limitación térmica individual. Tiene sus propias características de limitación térmica, como puntos de viaje, frecuencia de muestreo de limitación y constantes de ecuación de limitación. Una zona térmica podría incluir varios dispositivos de limitación térmica, cada uno de los cuales puede contribuir a los aumentos de temperatura en la zona térmica. Todos los dispositivos de la misma zona térmica deben seguir las mismas restricciones aplicadas a la zona térmica.

Para asegurarse de que las zonas térmicas y sus parámetros se definen con precisión, los diseñadores del sistema deben:

• Identifique las zonas activas en el chasis del sistema y determine cómo estos puntos calientes disipan el calor a los sensores de temperatura. (Idealmente, los sensores térmicos están sentados en los puntos calientes del sistema, excepto los sensores de temperatura de la piel).
• Caracterizar la relación de temperatura del sistema. Asigne las lecturas del sensor de temperatura a la temperatura del componente y a la temperatura de la piel.

Umbral de saturación

A partir de Windows 10, una nueva característica denominada estado de zona térmica, se ha introducido en la administración térmica de Windows, junto con un estado: sobrecargado. Cuando una zona térmica supera el nivel de limitación diseñado del dispositivo, el administrador térmico notificará a los componentes del sistema operativo que el sistema está sobrecargado. Esta notificación permite al sistema reducir la carga de trabajo para mejorar el estado térmico.

El administrador térmico mantiene un recuento global del número de zonas térmicas que están en estado sobreatropeado. Cuando el recuento aumenta por encima de cero (0), el administrador térmico envía una notificación del Centro de notificaciones de Windows (WNF) al sistema, lo que indica que está sobrecargada. Cuando el número de zonas sobreasignadas vuelve a cero (0), el administrador térmico envía otra notificación WNF al sistema, lo que indica que no hay zonas sobrecargadas.

Para especificar el umbral de sobreestablecer para una zona térmica, se debe especificar el _DSM térmico en la zona térmica, con la función 3 implementada. Este _DSM se define de la siguiente manera:

ArgumentosArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 3 Arg3: Un paquete vacío Devuelve un valor integer con el umbral de overthrottle actual, expresado como un porcentaje.

Este es un ejemplo _DSM que indica que la zona está sobrecargada, en los niveles de limitación del 0 % al 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

El umbral de sobreajuste se volverá a leer cuando se reciba una notificación (0x81) en referencia a la zona térmica.

Implementación de objetos ACPI

En la tabla siguiente se enumeran todos los objetos ACPI que deben implementarse en el firmware ACPI para definir una zona térmica.

Categoría	Método de control
Identificación de los dispositivos contenidos en la zona	_TZD Enumera los dispositivos de la zona térmica. _PSL (Opcional) Enumera los procesadores de la zona térmica. Los procesadores se pueden incluir en _TZD en su lugar: Windows admite ambas implementaciones.
Especificar umbrales térmicos en los que se deben realizar acciones	_PSV Temperatura a la que se va a iniciar la limitación. Para obtener más información, consulte Definición de un sobre térmico. _CALIENTE (Opcional) Temperatura a la que el sistema operativo hiberna el sistema. En el caso de los sistemas que no admiten hibernación, el sistema operativo iniciará el apagado crítico. Esto es muy recomendable para al menos una zona térmica para todos los sistemas x86/x64 debido a la ventaja de hibernar para ahorrar datos de usuario. _CRT Temperatura a la que el sistema operativo inicia el apagado crítico. Ninguna notificación en modo de usuario. Al menos una zona térmica de un sistema debe tener _CRT especificado. Si no es así, el sistema no pasa por la ruta de apagado cuando el sistema alcanza la temperatura crítica. En su lugar, se alcanza el punto de viaje seguro para errores de firmware y es probable que la energía se extraiga del sistema operativo.
Descripción del comportamiento de refrigeración pasiva	_TC1 Controlar la agresividad del administrador térmico aplica el rendimiento de la limitación térmica frente al cambio de temperatura. _TC2 Controlar la agresividad del administrador térmico aplica el rendimiento de limitación térmica frente a la diferencia de temperatura entre la temperatura actual y la _PSV. _CUCHARADITA Intervalo de muestreo de temperatura adecuado para la zona en décimas de segundo. El administrador térmico utiliza este intervalo para determinar la frecuencia con la que debe evaluar el rendimiento de la limitación térmica. Debe ser mayor que cero. Para obtener más información, consulte Algoritmo de limitación térmica.
Describir el comportamiento de refrigeración activo	_Acx (Opcional) Temperatura a la que se va a encender el ventilador. Debe ser en orden de mayor a menor, con _AC0 ser mayor. _Alx Lista de dispositivos de refrigeración activos.
Establecimiento de la directiva de refrigeración activa/pasiva	_SCP (Opcional) Para establecer la directiva de refrigeración preferida del usuario, si una zona admite la refrigeración activa y pasiva.
Límite mínimo	_DSM Use UUID: 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 para establecer el límite mínimo. Tenga en cuenta que esto es personalizado para el marco térmico de Windows y no está definido en ACPI. Para obtener más información, consulte Límite mínimo.
Temperatura del informe	_TMP Lea la temperatura de la zona térmica. _ESCONDIÓ Identificador de hardware único del proveedor para cargar el controlador de temperatura de Windows. _DTI (Opcional) Para notificar al firmware de la plataforma que se ha superado uno de los umbrales térmicos de la zona. Este método permite que el firmware implemente hysteresis cambiando los umbrales de la zona. _NTT (Opcional) Para especificar cambios significativos en la temperatura, también se debe notificar al firmware de la plataforma a través de _DTI.
Notificar al administrador térmico	Notificar 0x80 Notifica al sistema operativo que se ha superado el umbral (_PSV). El administrador térmico de Windows iniciará el control térmico. Notificar 0x81 (Opcional) Notifica al sistema operativo que han cambiado los valores de umbral de la zona. El administrador térmico de Windows se actualizará a sí mismo para usar los nuevos valores. Este método se usa normalmente para implementar hissteresis.
Especificación del dispositivo sensor de temperatura	_DSM Use UUID: 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500. Para obtener más información, consulte Sensor de temperatura. _DEP Cargue un dispositivo al que hace referencia el sensor de temperatura.

Límite mínimo

El límite mínimo es un método de extensión térmica de Microsoft _DSM que crea un límite inferior para _PSV solicitado de un dispositivo limitado. En otras palabras, determina cuánto limita el rendimiento de los dispositivos que controla una zona térmica. Si está presente, el _DSM mínimo se leerá en el arranque y, en cualquier momento, la zona térmica recibe la notificación ACPI (0x81). En cada iteración del algoritmo de refrigeración pasiva, se usa lo siguiente para calcular el cambio en el límite de rendimiento (DP) que el administrador térmico aplica a los dispositivos de la zona:

DP [%] = _TC1 × (Tn – Tn₋₁) + _TC2 × (Tn – Tt) Usamos lo siguiente para calcular el límite de rendimiento real:

Pn = Pn₋₁ – DP Con el límite mínimo (MTL) implementado, esta segunda ecuación cambia a:

Pn = max(Pn₋₁ – DP, MTL) Para especificar el límite mínimo para una zona térmica, se debe especificar el _DSM térmico en la zona térmica, con la función 1 implementada. Este _DSM se define de la siguiente manera:

ArgumentosArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 1 Arg3: Un paquete vacío Devuelve un valor entero con el límite mínimo actual, expresado como un porcentaje.

Este es un ejemplo sencillo para _DSM limitación no inferior al 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)
                    }
                }
            }
        }
    }

Administrador térmico en kernel

El administrador térmico de Windows se implementa como parte del kernel de Windows. Supervisa la temperatura de todas las zonas térmicas y aplica la limitación térmica según corresponda.

Cada vez que el administrador térmico consulta al controlador ACPI para la temperatura actual, realizará un cálculo sobre la cantidad de porcentaje de rendimiento de limitación térmica que debe aplicar a todos los dispositivos de limitación térmica de la zona térmica. El límite térmico se evalúa y se aplica cuando se supera el umbral de refrigeración pasivo (_PSV), y en cada intervalo de muestreo de temperatura (_TSP) hasta que la temperatura se enfríe por debajo de ella y el límite térmico vuelve al 100 por ciento. El hardware debe detectar cuándo se ha superado el _PSV y debe indicar que a través de una notificación de eventos ACPI de hardware.

Algoritmo de limitación térmica

El algoritmo de limitación térmica usa la siguiente ecuación, que se define en la especificación ACPI:

DP [%] = _TC1 × ( Tn – Tn₋₁ ) + _TC2 × (Tn – Tt) donde

Tn = lectura de temperatura actual del sensor de temperatura en la zona térmica en décimos grados de Kelvin. Tn₋₁ = temperatura de la lectura anterior. Tt = temperatura objetivo en décimas de un grado Kelvin (_PSV). DP = cambio de rendimiento necesario. Se trata de un valor lineal entre 0 (totalmente limitado) y el 100 por ciento (sin limitar), que se aplicará a cada dispositivo de refrigeración de la zona. Esta ecuación describe el bucle de comentarios entre los cambios de temperatura y el rendimiento de la limitación. En cada iteración del bucle, la diferencia de temperatura entre las lecturas de temperatura actual y anterior requiere que el rendimiento P disminuya en porcentaje de DP. El valor dp es la cantidad de limitación térmica que se va a aplicar. Muchos dispositivos de refrigeración no tienen una respuesta térmica lineal a las mitigaciones de refrigeración. En estos dispositivos, el límite térmico es una sugerencia al dispositivo para indicar la cantidad de refrigeración necesaria. Cada dispositivo de refrigeración tendrá su propia asignación de este valor lineal a mitigaciones térmicas específicas del dispositivo. La limitación del rendimiento del dispositivo reduce el consumo de energía y la generación de calor, lo que hace que la temperatura disminuya.

Las dos constantes, _TC1 y _TC2, controlan cómo se aplica la limitación térmica agresiva en este bucle de comentarios. La mayor _TC1 es, la limitación térmica más agresiva se utiliza para mantener una temperatura estable. La mayor _TC2 es, la limitación térmica más agresiva se usa para empujar la temperatura cerca del punto de viaje.

En la tabla siguiente se proporciona un ejemplo de cómo calcula el administrador térmico y aplica el DP. En este ejemplo se usan los siguientes valores de parámetro:

Configuración

• _PSV = 325^oK
• _TC1 = 2
• _TC2 = 3
• _TSP = 5000 milisegundos
• Supongamos que la temperatura aumenta continuamente en 1 grado cada 5 segundos.

La columna situada más a la derecha en la tabla siguiente (etiqueta P) indica el nivel de rendimiento limitado que resulta de aplicar las restricciones especificadas por estos parámetros.

Iteración	Time	Tn	DP	P
1	0 segundos	326oK	= 2 × 1 + 3 × 1 = 5 %	95 %
2	5 segundos	327oK	= 2 × 1 + 3 × 2 = 8 %	87 %
3	10 segundos	328oK	= 2 × 1 + 3 × 3 = 11 %	76%
4	15 segundos	320oK	= 2 × 1 + 3 × 4 = 14 %	62%
5	20 segundos	330oK	= 2 × 1 + 3 × 5 = 17%	45 %
...

Controlador de directiva

De forma predeterminada, el algoritmo utilizado para determinar el porcentaje de limitación según lo dictado por las especificaciones ACPI se usa para todas las zonas térmicas. Como se ha descrito anteriormente, este algoritmo se basa únicamente en el sensor de temperatura conectado a la zona térmica, lo que puede limitarse.

Si se prefiere un algoritmo diferente, el diseñador del sistema puede implementar un controlador de directiva para incorporar el algoritmo preferido. Un controlador de directiva se encuentra sobre la pila de zona térmica para la zona que controla. Para esta zona, el algoritmo del controlador de directiva se puede usar en lugar del algoritmo ACPI en el administrador térmico. El algoritmo del controlador de directiva tiene la capacidad de considerar cualquier información a la que pueda acceder como entrada. Las decisiones de directiva tomadas por el conductor se pasan al administrador térmico, que registra la información y la pasa a la zona térmica para llevar a cabo.

El uso de un controlador de directiva para una zona térmica significa que el controlador de la directiva(no ACPI y no el sistema operativo) es el único responsable de decidir cuándo limitar una zona y por cuánto.

Si hay un controlador de directiva presente, todos los puntos de viaje, todas las constantes térmicas, el límite mínimo, etc., se omiten por completo. El sistema operativo no tiene información sobre por qué la zona térmica se establece en su nivel de limitación actual. Algunas ventajas vienen con el uso de un controlador de directiva en lugar de una solución de propiedad. Un controlador de directiva aprovecha el proceso integrado de dispositivos de limitación. Cualquier cosa que una zona térmica pueda hacer para proporcionar mitigación térmica puede realizarse mediante un controlador de directiva. Además, los diagnósticos para la administración térmica de Windows se heredan automáticamente.

La interfaz de directiva térmica se ha actualizado para incluir un nuevo parámetro para indicar si la zona está sobreapreciada o no. Este parámetro se inicializa en FALSE. Los controladores de directiva antiguos no conocerán el nuevo parámetro y los nuevos controladores sabrán que se admite el nuevo parámetro, cuando detecten una versión de directiva 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;

El controlador de directiva puede indicar que la zona térmica está sobreasignada, completando el IOCTL de directiva con el parámetro OverThrottled establecido en TRUE. Cuando se mejoran las condiciones térmicas, el controlador de la directiva térmica puede completar el IOCTL con restablecimiento overThrottled en FALSE, para indicar que la zona térmica se ha recuperado. Windows no requerirá que el controlador de directiva esté limitado cuando se establezca la marca de sobrethrottle.

Dispositivos administrados térmicamente

Las zonas térmicas controlan el comportamiento térmico de los dispositivos administrados a través de sus controladores de modo kernel. Un dispositivo de limitación térmica podría residir en varias zonas térmicas. Cuando varias zonas térmicas solicitan diferentes porcentajes de rendimiento de limitación térmica, el administrador térmico elige el porcentaje mínimo de rendimiento de limitación térmica que se aplicará al dispositivo de limitación térmica.

Muchos dispositivos de refrigeración no tienen respuesta térmica lineal a las mitigaciones de refrigeración. En estos casos, el límite térmico es una sugerencia para el dispositivo del grado de refrigeración requerido. Cada dispositivo de refrigeración tendrá su propia asignación de este valor lineal a sus mitigaciones térmicas específicas.

A medida que se carga cada controlador de dispositivo, ACPI consultará la interfaz de refrigeración térmica y registrará cada dispositivo de respuesta como un dispositivo de refrigeración. Más adelante, cuando la refrigeración pasiva está en proceso y el límite térmico de una zona ha cambiado, ACPI llamará a esta interfaz en cada dispositivo de refrigeración de la zona. A continuación, el dispositivo de refrigeración asignará el límite térmico proporcionado a sus características específicas de refrigeración e implementará las mitigaciones de refrigeración adecuadas. Tenga en cuenta que si el dispositivo de refrigeración aparece en varias zonas térmicas, el límite térmico que restringe el dispositivo más (es decir, el porcentaje más bajo) se pasa al dispositivo.

Nota Windows proporciona implementaciones integradas de limitación térmica para procesadores, retroiluminación y batería del método de control ACPI.

Interfaz de refrigeración térmica

Windows proporciona los puntos de extensión para que los controladores de dispositivos se registren como dispositivos de limitación térmica y para recibir la solicitud de porcentaje de limitación térmica. A continuación, el dispositivo es responsable de traducir ese porcentaje a una acción que tenga sentido para sí mismo.

Los dispositivos que quieran agregarse como dispositivo de limitación térmica deben agregar primero el _HIDs a la lista de dispositivos térmicos de zona térmica y, a continuación, implementar el siguiente conjunto de interfaces. A medida que se carga cada controlador de dispositivo, ACPI consultará esta interfaz y registrará cada dispositivo de respuesta como un dispositivo de refrigeración. Más adelante, cuando la refrigeración pasiva está en proceso y el límite térmico de una zona ha cambiado, ACPI llamará a esta interfaz en cada dispositivo de refrigeración de la zona. A continuación, el dispositivo de refrigeración asignará el límite térmico proporcionado a sus características específicas de refrigeración e implementará las mitigaciones de refrigeración adecuadas. Tenga en cuenta que si el dispositivo de refrigeración aparece en varias zonas térmicas, el límite térmico que restringe el dispositivo más (es decir, el porcentaje más bajo) se pasa al dispositivo.

//  
// 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

Procesador

Para un procesador, el administrador térmico comunica el porcentaje de limitación térmica al administrador de energía del procesador (PPM). La limitación térmica de los procesadores es una característica integrada de Windows.

Agregador del procesador

El dispositivo de agregador del procesador permite el estacionamiento principal como mitigación térmica. Las zonas pueden especificar el estacionamiento principal como mitigación térmica si el dispositivo agregador del procesador es miembro de una zona térmica. No es necesario limitar los procesadores para que se produzca el estacionamiento principal. Esta implementación funciona en paralelo con el identificador de procesador lógico (LPI). Tenga en cuenta que esto todavía está sujeto a las advertencias del estacionamiento principal. En concreto, cualquier afinidad de trabajo con un núcleo estacionado hará que se ejecute el núcleo.

Device(\_SB.PAGR) {
    Name(_HID, "ACPI000C")
}
ThermalZone(\_TZ.TZ01) {
    Name(_TZD, Package() {"\_SB.PAGR"})
    // Other thermal methods: _PSV, etc.
}

Elementos gráficos

Para que un controlador de miniporte gráficos de terceros se administre térmicamente, debe interactuar con el controlador de puerto gráficos de Windows, Dxgkrnl.sys. Dxgkrnl.sys tiene la interfaz de refrigeración térmica y pasa las solicitudes de limitación por la pila al controlador de minipuerto. Es responsabilidad del controlador de miniportar traducir la solicitud a una acción específica de su dispositivo.

En el diagrama de bloques siguiente se muestra la arquitectura de la zona térmica que controla la GPU.

Retroiluminación

Reducir la retroiluminación puede mejorar drásticamente las condiciones térmicas en una plataforma móvil. Windows recomienda que, mientras funciona, el brillo de la pantalla del sistema nunca se limita térmicamente a menos de 100 nits.

Para el control de retroiluminación, el administrador térmico comunica el porcentaje de limitación térmica al controlador del monitor, Monitor.sys. Monitor.sys decidirá la configuración real del nivel de retroiluminación en función de esta entrada térmica y otras entradas en Windows. A continuación, Monitor.sys aplicará la configuración del nivel de retroiluminación a través de ACPI o el controlador de pantalla.

Tenga en cuenta que si la temperatura de la zona térmica que incluye la luz trasera continúa aumentando, el porcentaje de limitación térmica solicitado podría caer finalmente a cero por ciento. La implementación de nivel de retroiluminación en ACPI o controlador de pantalla debe asegurarse de que el nivel de brillo mínimo disponible para los controles de rendimiento sigue siendo visible para los usuarios finales.

Nota Mientras funciona, el brillo de la pantalla del sistema nunca se limita térmicamente a menos de 100 nits.

Batería

Otra fuente de calor principal en el sistema es la carga de la batería. Desde la perspectiva de un usuario, la carga debe reducirse e incluso detenerse completamente bajo condiciones térmicas restringidas. Sin embargo, la carga de la batería no debe verse obstaculizada en casos de uso normales.

Nota Recomendamos que la carga de la batería no esté limitada mientras el sistema está inactivo (1) y dentro del intervalo de temperatura ambiente por debajo de 35^oC, o (2) en cualquier condición mientras la temperatura ambiente es inferior a 25^oC.

El controlador de miniclase del método de control de Windows, Cmbatt.sys, usa directamente la interfaz de refrigeración térmica, como se ha descrito anteriormente. El firmware es responsable de tener en cuenta el límite térmico actual al realizar la carga. Se necesita un nuevo método de control ACPI para establecer el límite térmico para la carga. Este método se implementa como un método específico del dispositivo (_DSM), tal y como se define en la especificación ACPI 5.0, Sección 9.14.1.

Para aplicar el porcentaje de limitación térmica, Cmbatt.sys evaluará el método de control Método específico del dispositivo (_DSM) para solicitar el firmware ACPI para establecer el límite térmico para la carga. Dentro del método de control _DSM, se define un GUID para indicar el límite térmico.

Arg #	Valor	Descripción
Arg0	4c2067e3-887d-475c-9720-4af1d3ed602e	UUID
Arg1	0	Revisión
Arg2	1	Función
Arg3	Valor entero de 0 a 100	Límite térmico para la carga de la batería. Equivalente al porcentaje calculado de limitación pasiva.
Valor devuelto	N/D	Sin valor devuelto

Refrigeración activa

Desde el punto de vista del sistema operativo, una plataforma tiene dos estrategias que puede usar para implementar el control de ventilador:

• Implemente una o varias zonas térmicas ACPI con puntos de viaje activos para atraer o desenganchar el ventilador.

  El marco térmico de Windows admite dispositivos de refrigeración activos a un nivel muy básico. La única bandeja de entrada compatible con el dispositivo es un ventilador ACPI y solo se puede controlar con señal de encendido/apagado.

• Implemente una solución propietaria para controlar el ventilador (a través de controladores, un controlador incrustado, etc.).

  Aunque Windows no controla el comportamiento de las soluciones propietarias para ventiladores, Windows admite notificaciones de ventilador en el administrador térmico para todas las implementaciones, incluidos los controladores incrustados, de modo que se pueda recopilar información de diagnóstico y telemetría. Por lo tanto, la exposición del ventilador al sistema operativo es necesaria para todos los equipos en espera modernos y se recomienda encarecidamente para todos los demás.

Tenga en cuenta que la implementación de la refrigeración activa es completamente independiente de las mitigaciones de refrigeración pasiva descritas anteriormente.

Control de ventilador por zona térmica ACPI

Windows admite la definición del ventilador basado en estado D ACPI 1.0. (Para obtener más información, consulte la especificación ACPI). Por lo tanto, el control se limita a ventilador encendido y apagado. El controlador del ventilador se proporciona en el controlador ACPI de Windows, Acpi.sys.

1. El sensor de temperatura lee la temperatura ha cruzado un punto de viaje y emite Notify(0x80) en la zona térmica asociada.
2. La zona térmica lee la temperatura con el método de control _TMP y compara la temperatura con los puntos de viaje activos (_ACx) para decidir si el ventilador debe estar encendido o desactivado.
3. El sistema operativo coloca el dispositivo ventilador en D0 o D3, lo que hace que el ventilador se active o desactive.

En el diagrama de bloques siguiente se muestra el flujo de control de un ventilador controlado por una zona térmica 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})
    }
}

Ventilador de varias velocidades en ACPI

Para lograr varias velocidades para un ventilador mediante ACPI 1.0, hay dos opciones:

• La zona térmica puede contener varios "ventiladores", cuando solo existe un ventilador físico. Tener más "fans" en una vez se traduce en una velocidad de ventilador más rápida. Para obtener más información, vea el ejemplo de esta opción en la sección 11.7.2 de la especificación ACPI 5.0.
• Cuando el ventilador está encendido, puede decidir por sí mismo la rapidez con la que girar. Los sistemas con controladores incrustados, por ejemplo, pueden elegir esta opción.

Solución propietaria para ventiladores

Windows debe ser capaz de detectar la actividad del ventilador con cualquiera de las implementaciones. Cuando una plataforma usa el modelo térmico ACPI, Windows es responsable de encender y apagar el ventilador y, por lo tanto, ya sabe cuándo está activo. Cuando se usa una solución propietaria para controlar el ventilador, Windows necesita notificación de que el ventilador se está ejecutando. Para habilitar esto, Windows admitirá un subconjunto parcial de las extensiones de ventilador ACPI 4.0, que se enumeran en la tabla siguiente.

Característica	Descripción	Compatible
_FST	Devuelve el estado del ventilador.	sí
Notify(0x80)	Indica que el estado del ventilador ha cambiado.	sí
_FIF	Devuelve información del dispositivo ventilador.	no
_FPS	Devuelve una lista de estados de rendimiento del ventilador.	no
_FSL	Establece el estado de rendimiento del ventilador (velocidad).	no

Windows usará el objeto _FST para determinar si el ventilador se está ejecutando (el campo control es distinto de cero) o desactivado (el campo control es cero). Windows también admitirá Notify(0x80) en el dispositivo ventilador como indicación de que _FST ha cambiado y debe volver a evaluarse.

No es necesario que un ventilador que implemente el objeto _FST esté en la lista de dispositivos _ALx de una zona térmica, pero puede estar en esta lista, como opción. Esta opción habilita una solución híbrida en la que un ventilador normalmente está controlado por un controlador de terceros, pero se puede controlar mediante la zona térmica del sistema operativo si el controlador de terceros no está instalado. Si un ventilador está en una lista de dispositivos de _ALx y está establecido por la zona térmica (colocada en D0), se requiere el objeto _FST para indicar un valor control distinto de cero.

Para todos los fans, Windows usará el siguiente algoritmo para determinar el estado del ventilador:

1. Si un ventilador está en D0 (como resultado de la _ACx punto de viaje de una zona térmica que se cruza), se activa.
2. Si un ventilador está en D3 y no admite las extensiones ACPI 4.0, se desconecta.
3. Si un ventilador está en D3 y admite las extensiones ACPI 4.0, el sistema operativo comprobará _FST campo Control de un valor distinto de cero para ver si el ventilador está comprometido.

Ejemplo 1: Control de ventilador de hardware

En este ejemplo, un controlador incrustado controla un ventilador.

1. El controlador incrustado decide iniciar o detener el ventilador en función de su propio algoritmo interno.
2. Después de iniciar o detener el ventilador, el controlador incrustado emite una notificación (0x80) en el dispositivo ventilador.
3. El sistema operativo evalúa _FST y lee el nuevo estado del ventilador.

En el diagrama de bloques siguiente se muestra el flujo de control de un ventilador controlado por un controlador incrustado.

En el siguiente ejemplo de ASL se define un dispositivo "FAN" que puede notificar al sistema operativo los cambios en el estado del ventilador:

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
}

Ejemplo 2: Control del ventilador del controlador

En este ejemplo, un controlador de terceros controla el ventilador.

1. El controlador decide iniciar o detener el ventilador en función de su propio algoritmo interno.
2. El controlador modifica el estado del ventilador y evalúa un método de control personalizado (SFST) en su dispositivo térmico.
3. El método de control de dispositivos térmicos actualiza el contenido _FST del dispositivo ventilador y emite Notify(0x80) en el dispositivo ventilador.
4. El sistema operativo evalúa _FST y lee el nuevo estado del ventilador.

En el diagrama de bloques siguiente se muestra el flujo de control de un ventilador controlado por un controlador de terceros.

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)
        }
    }
}

Presencia de ventilador

Una plataforma indica que hay un ventilador en el sistema incluyendo un dispositivo de ventilador (PnP ID PNP0C0B) en el espacio de nombres ACPI. Windows tomará la presencia de este dispositivo como indicación de que el sistema tiene un ventilador y la ausencia de este dispositivo como indicación de que el sistema no tiene ventilador.

Guía específica para el modo de espera moderno

El marco de administración térmica de Windows forma parte del kernel y se distribuye con todos los sistemas Windows. Por lo tanto, el material anterior se aplica a todas las máquinas. Sin embargo, varios tipos de máquinas requieren instrucciones adicionales más específicas para el modo de espera moderno.

El modo de espera moderno lleva el modelo de alimentación del teléfono inteligente al equipo. Proporciona una experiencia instantánea de usuario activada e instantánea que los usuarios han esperado en su teléfono. Y al igual que en el teléfono, Modern Standby permite al sistema mantenerse fresco, actualizado y accesible siempre que haya una red adecuada disponible. Windows 10 admite el modo de espera moderno en plataformas de bajo consumo que cumplen requisitos específicos de certificación de Windows.

Los equipos en espera modernos son dispositivos muy móviles en un factor de forma fino y ligero. Además, los equipos en espera modernos siempre están encendidos y en el estado ACPI S0. Para ofrecer una experiencia de cliente sólida y confiable, todo el sistema ,desde el diseño mecánico hasta la implementación de firmware y software, debe diseñarse con atención crítica a las características térmicas. Por lo tanto, todos los equipos en espera modernos deben cumplir los requisitos térmicos.

Requisitos modernos de espera

Todos los equipos en espera modernos deben superar las siguientes pruebas HCK:

• Todos los equipos modernos en espera deben tener al menos una zona térmica para la que se defina una temperatura crítica de apagado (_CRT). Para los sistemas x86, se recomienda definir una temperatura de hibernación crítica (_HOT) para desencadenar el almacenamiento de datos de usuario. _HOT debe ser inferior a _CRT y _CRT debe ser inferior al punto de viaje térmico seguro para errores del firmware.
• Cada zona térmica debe notificar la temperatura real en el sensor (_TMP). La prueba ejecuta una carga de trabajo variable en el equipo y se espera que cambie la temperatura.

Además, recomendamos que cada EQUIPO incluya al menos un sensor de temperatura para el SoC.

Requisitos de refrigeración activos

Los equipos en espera modernos que usan ventiladores deben cumplir los siguientes requisitos adicionales, que se prueban en HCK:

• El ventilador debe exponerse al sistema operativo. Para obtener más información, consulte Presencia de ventilador.
• El sistema operativo debe saber en todo momento si el ventilador está encendido o apagado. Incluso mientras se encuentra en resistencia inactiva en el modo de espera moderno, los cambios en la actividad del ventilador deben reactivar el SoC para actualizar el estado. Para obtener más información sobre la implementación de notificaciones de ventilador, consulta Control de ventilador por zona térmica ACPI.
• El ventilador no debe encenderse mientras el equipo está en espera moderna. Con una carga de trabajo realista durante el modo de espera moderno, que es cada vez que la pantalla está desactivada, el ventilador no debe activarse.

Desde la perspectiva del usuario, el equipo parece estar desactivado cuando se encuentra en modo de espera moderno. Los usuarios esperan que un equipo en modo de espera moderno se comporte como si estuviera en estado de "suspensión" del sistema. Por lo tanto, los usuarios esperan que el ventilador nunca aparezca, igual que en los equipos tradicionales durante la suspensión. Si el ventilador está encendido, es posible que los usuarios lo escuchen o sientan el aire caliente que circula y piensan que el equipo no funciona correctamente. Por lo tanto, el ventilador no debe activarse mientras está en espera moderna. Para obtener más información sobre el comportamiento necesario, consulte Requisitos de prueba de HCK para equipos en espera modernos.

Estos requisitos implican que la directiva de refrigeración cuando la pantalla está activada puede ser diferente de cuando la pantalla está apagada. El equipo puede usar la refrigeración activa mientras la pantalla está activada, pero solo debe confiar en la refrigeración pasiva cuando la pantalla está apagada. El punto de viaje activo para el ventilador puede ser mucho menor cuando la pantalla está activada que cuando está desactivada. Para la implementación acpI, _ACx tendría que actualizarse al entrar en espera moderna. Para las soluciones propietarias, asegúrese de actualizar la directiva en el controlador incrustado.

Limitación del procesador

El PPM comunica los niveles máximos, deseados y mínimos de rendimiento al PEP. En condiciones de limitación térmica, el nivel máximo de rendimiento debe ser igual al rendimiento de limitación solicitado por el administrador térmico. A continuación, el PEP establece el voltaje físico y la frecuencia de la CPU en función de los requisitos de nivel de rendimiento del PPM.

Señal de ruido del ventilador

A partir de Windows 11, los dispositivos pueden enviar una señal de ruido del ventilador al sistema operativo para su uso en las decisiones de administración de recursos, con el objetivo de proporcionar a los usuarios una experiencia fresca y silenciosa. Esta interfaz de participación permite al firmware enviar información rpm del ventilador al sistema operativo como un valor de 0 (ventilador desactivado) a Max RPM, que el sistema operativo puede usar en las decisiones de administración de recursos para enfriar el dispositivo según sea necesario. Esto contribuye a dos ventajas principales:

1. Experiencia de usuario silenciosa: El ruido del ventilador y el soplado de aire caliente son una fuente significativa de frustración del cliente. Esto es especialmente cierto cuando el usuario no espera mucha actividad de ventilador, como cuando el dispositivo ejecuta una cantidad baja de trabajo o no hay trabajo en primer plano.
2. Vida útil mejorada de la batería: Las velocidades de ventilador más altas dan lugar a un mayor uso de energía, lo que provoca una descarga de batería más rápida mientras está en dc y carga más lenta mientras está en ca.

Actualmente, esta señal se puede usar para administrar las tareas del indexador de búsqueda y hay planes para habilitar también tareas en segundo plano adicionales para consumir esta señal.

En el diagrama siguiente se resume cómo se envía la señal de ruido del ventilador en las capas del firmware al software.

Funcionamiento de la señal de ruido del ventilador

Detalles de la interfaz ACPI

A continuación se muestran las cuatro funciones del método específico del dispositivo (_DSM, UUID: A7611840-99FE-41ae-A488-35C75926C8EB) usadas para admitir esta característica. Puede encontrar información sobre _FST (Estado del ventilador) en la sección 11.3.1.4 de la especificación ACPI y en ejemplo 1: Control de ventilador de hardware de dispositivos administrados térmicamente

En el diagrama siguiente se resume el flujo de cómo se usan estas funciones.

En el diagrama de bloques siguiente se muestra el flujo de control de un ventilador controlado por un controlador incrustado, incluido el método de control Notify(0x80).

Nota

La señal de ruido del ventilador no controlaría el ventilador RPM, sino que, en su lugar, notifique al sistema operativo que hay ruido de ventilador que requiere mover el recurso de CPU de las tareas en segundo plano para completar el trabajo prioritario.

Enumerar funciones (función 0)

Para que el sistema operativo interactúe con la plataforma, se debe exponer un dispositivo ACPI a través del espacio de nombres . Este dispositivo debe incluir un objeto _CID que contenga EISAID("PNP0C0B"). El ámbito de este dispositivo debe contener la siguiente definición de _DSM que indica qué _DSMs admite el dispositivo.

UUID	Revisión	Función	Descripción
A7611840-99FE-41ae-A488-35C75926C8EB	0	0	Enumerar funciones

Devolución: Para indicar la compatibilidad con las funciones del 0 al 3 enumerados anteriormente, la función Enumerar funciones (función 0) debe devolver 0xF. Consulte la sección 9.1.1 de la especificación ACPI para obtener más información.

Función get Fan Trip Point Support (Función 1)

El hardware indica al sistema operativo lo que se admite en términos de RPM.

UUID	Revisión	Función	Descripción
A7611840-99FE-41ae-A488-35C75926C8EB	0	1	Obtener compatibilidad con el punto de viaje de ventilador

Argumentos

Arg0: UUID: A7611840-99FE-41ae-A488- 35C75926C8EB

Arg1: Revisión: 0

Arg2: Función: 1

Arg3: Un paquete vacío

Devolución: Valor entero que contiene la granularidad admitida para los puntos de viaje de ventilador, en RPM. Si no es cero, el sistema operativo puede seleccionar puntos de viaje que son varios de la granularidad de notificación. Por ejemplo, con una granularidad de 200, OSPM podría seleccionar puntos de viaje en 0, 200, 400, 600, etc. Rpms. Un valor de 0 indica que no se admiten puntos de viaje.

Función Set Fan Trip Points (Función 2)

El sistema operativo se comunica con hardware lo que es el siguiente punto de viaje de notificación; el hardware notifica al sistema operativo cuando esto sucede.

UUID	Revisión	Función	Descripción
A7611840-99FE-41ae-A488-35C75926C8EB	0	2	Obtener puntos de viaje de ventilador

Argumentos

Arg0: UUID: A7611840-99FE-41ae-A488-35C75926C8EB

Arg1: Revisión: 0

Arg2: Función: 2

Arg3: Paquete que contiene los puntos de viaje inferiores y superiores. (2 elementos int. Inferior en el índice 0, Superior en el índice 1)

OSPM solo seleccionará los puntos de viaje que son un múltiplo de la granularidad del punto de viaje especificado en la función 1. Cuando la velocidad real del ventilador va por encima o por debajo de los puntos de viaje superior/inferior, la plataforma debe emitir Notify(0x80) en el dispositivo de ventilador. A continuación, OSPM evaluará _FST (estado del ventilador) para determinar la velocidad del ventilador actual. Si la velocidad del ventilador ya está fuera de los puntos de viaje especificados cuando se establecen los puntos de viaje, la plataforma debe emitir inmediatamente Notify(0x80).

El punto de viaje superior será un múltiplo de granularidad. El punto de viaje inferior será (múltiplo de granularidad) + 1 (punto < de viaje superior inferior). Cuando RPM es 0, el sistema operativo establecerá un punto de viaje inferior en 0 y el punto de viaje superior en 1.

Devolución: Ninguno.

Función Get Fan Operating Ranges (Función 3)

Asignación entre RPM:> impacto. Tenga en cuenta que solo un ventilador (el más cercano al SoC) puede implementar esta interfaz, debe implementar todas las tres funciones más la función 0 de la sección 9.1.1 de la especificación ACPI.

UUID	Revisión	Función	Descripción
A7611840-99FE-41ae-A488-35C75926C8EB	0	3	Obtención de rangos operativos de ventilador

Argumentos

Arg0: UUID: A7611840-99FE-41ae-A488-35C75926C8EB

Arg1: Revisión: 0

Arg2: Función: 3

Arg3: Un paquete vacío.

Devolución: Un paquete que contiene el siguiente formato:

Package () {
	Impact1MaxRPM,		// Integer (DWORD)
	Impact2MaxRPM, 		// Integer (DWORD)
	Impact3MaxRPM, 		// Integer (DWORD)
	MaxRPM				// Integer (DWORD)
}

Campo	Formato	Descripción
Impact1MaxRPM	Entero (DWORD)	Número máximo de RPM para el intervalo de impacto del ventilador 1.
Impact2MaxRPM	Entero (DWORD)	Número máximo de RPM para el intervalo de impacto del ventilador 2. Debe ser >= Impact1MaxRPM.
Impact3MaxRPM	Entero (DWORD)	Número máximo de RPM para el intervalo de impacto del ventilador 3. Debe ser >= Impact2MaxRPM.
MaxRPM	Entero (DWORD)	Número máximo de RPM en los que puede funcionar el ventilador. Debe ser >= Impact3MaxRPM.

Esta tabla se usa para derivar el intervalo RPM para cada uno de los niveles de impacto del ventilador:

Puntuación de impacto	Valor de RPM inferior	Valor superior de RPM
1	1	Impact1MaxRPM
2	Impact1MaxRPM + 1	Impact2MaxRPM.
3	Impact2MaxRPM + 1	Impact3MaxRPM
4	Impact3MaxRPM + 1	MaxRPM

Si una plataforma no usa un intervalo de impacto (por ejemplo, si el ventilador realiza transiciones directamente desde el intervalo de impacto 2 al intervalo de impacto 4), puede indicarlo estableciendo el valor de RPM máximo para el intervalo de impacto no utilizado igual al rpm máximo para el intervalo de impacto inferior.

Asignación de ejemplo

Valor enviado al sistema operativo	RPM del ventilador	Experiencia del usuario	Techo rpm
0 – Bajo	1-4000 RPM (<=25 dBA)	Ventilador no encendido o encendido con poca molestia	Impact1MaxRPM = 4000
1 – Medio	4001-5000 RPM (25-30 dBA)	Ventilador encendido con molestias medias	Impact2MaxRPM = 5000
2 – Medium-High	5001-6000 RPM (30-36 dBA)	Ventilador encendido con molestias medias y altas	Impact3MaxRPM = 6000
3 – Alto	6001+ RPM (36+ dBA)	Fan on with high annoyance	MaxRPM = 9000

Ejemplo de código 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
}

Pruebas y seguimiento

Consulte los pasos siguientes para recopilar el registro y la vista en Windows Analizador de rendimiento (WPA):

1. Configuración-> Buscar en Windows -> Configuración avanzada del indexador de búsqueda -> Avanzadas -> Eliminar y recompilar índice (Recompilar)
2. wpr -boottrace -addboot AcpiFanNoiseImpact.wprp –filemode
3. Reiniciar el sistema
4. Comprobar el estado del índice de configuración:> búsqueda de Windows (asegúrese de que el dispositivo se conecte con la fuente de alimentación de CA).
5. Cuando se complete el índice, detenga el seguimiento: wpr -boottrace -stopboot AcpiFanNoiseImpact.etl (Cancelar seguimiento sin guardar: wpr -boottrace –cancel)
6. Abra AcpiFanNoiseImpact.etl a través de Windows Analizador de rendimiento (WPA).

Descargue el archivo en AcpiFanNoiseImpact.zip O, copie lo siguiente y guárdelo como 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>

La imagen siguiente es un gráfico WPA de ejemplo que muestra que el indexador de búsqueda funciona de nuevo cuando el ventilador es alto.

Hay un nivel del ventilador que haría que el índice de búsqueda se desactivara en su totalidad (el más alto, que debería ser la puntuación de impacto 4), pero todos los demás niveles del ventilador deben reducirse la actividad y no suspenderse. Por ejemplo, si ACPI declaró Impact3MaxRPM = 4000 RPM en la función 3 (obtener rangos operativos de ventilador), cuando fan RPM > 4000 (4100RPM, 4500RPM), se vería SearchIndexer.exe y SearchProtocalHost.exe uso de CPU se suspendería.

Nota

Para ver el uso de CPU, puede usar wpr -start power -filemode para recopilar el uso en tiempo de ejecución. Use wpr -stop fan_noise.etl para detener la recopilación del registro.

En la imagen siguiente se muestra un gráfico WPA de ejemplo que muestra la suspensión de SearchIndexer.exe y SearchProtocolHost