Guia de design

Esse guia de design de gerenciamento térmico do computador fornece informações sobre como determinar os valores de temperatura do computador que são "muito quentes" e "muito frios".

Fazer essas determinações é um requisito fundamental para um design que oferece uma boa experiência do usuário do computador. Além disso, esses limites ajudam a escolher a primeira ação mitigadora a ser tomada para componentes do computador que residem em várias zonas térmicas.

Projetando os limites de temperatura

Variáveis e suposições

Os seguintes fatores influenciam o comportamento térmico de um computador:

• Design de hardware

  A importância de um bom design de hardware não pode ser excessivamente estressada. Para obter mais informações, consulte Modelagem e avaliação térmicas de hardware.

• Ambiente

  Esses são fatores externos que contribuem para o comportamento térmico do sistema. O software só pode influenciar o ambiente notificando o usuário de que as restrições térmicas são um problema, por exemplo, exibindo o logotipo de falha térmica na inicialização. O usuário deve mudar para um ambiente diferente para que esses fatores mudem:

  • Radiação solar

    A intensidade e o ângulo da luz solar que afetam a tela ou qualquer parte do sistema.

  • Temperatura ambiente

    A temperatura do ambiente.

  • Fluxo de ar

    Com ou sem circulação de ar. Vento ou em um caso de computador.

  • Umidade

    Seco ou úmido.

• Carga de trabalho e consumo de energia

  A suposição aqui é que a carga de trabalho e o consumo de energia são proporcionais uns aos outros. Em outras palavras, quanto mais trabalho um computador ou componente faz, mais energia ele consome e mais calor ele gera. Embora isso possa não ser verdade em todos os casos, esse modelo simplificado é mais ou menos suficiente aqui. É aí que entram as mitigações de software. Ao reduzir a carga de trabalho, menos calor é gerado e o computador continua operando.

Ao projetar e modelar o hardware, leve em conta os parâmetros mencionados na lista anterior. Use os piores valores para o ambiente. O único parâmetro que pode ser controlado diretamente pelo software é a carga de trabalho.

Conceitos básicos térmicos

Considere o comportamento térmico de um computador quando ele estiver executando uma carga de trabalho constante. À medida que a carga de trabalho é iniciada, os componentes de hardware do computador, como a CPU e a GPU, geram calor e aumentam a temperatura. À medida que a temperatura aumenta em relação à temperatura ambiente, o computador começa a dissipar o calor mais rapidamente até que, eventualmente, a geração de calor seja igual à dissipação de calor e a temperatura atinja o estado estável. Durante toda a duração dessa carga de trabalho constante, já que não há limitação envolvida, o desempenho e a taxa de transferência são constantes.

O diagrama a seguir mostra a relação entre geração de calor, temperatura e desempenho quando não há limitação envolvida. Observe que a temperatura do computador permanece dentro do envelope térmico, conforme limitado pela temperatura ambiente e temperatura de limitação.

Agora considere o comportamento térmico de um computador quando ele estiver executando uma carga de trabalho diferente que também seja constante, mas com mais uso intensivo de recursos. Conforme essa carga de trabalho é executada, o calor gerado é muito maior do que o que o sistema é capaz de dissipar para o ambiente ambiente e, como resultado, a temperatura aumenta constantemente. Sem resfriamento passivo, a temperatura continuará subindo até que o sistema fique muito quente e afete negativamente o conforto e a segurança do usuário final. O hardware também pode ser danificado em altas temperaturas. A limitação térmica ajuda a garantir que o computador não atinja essas altas temperaturas. Quando a temperatura sobe sobre um ponto de viagem de temperatura de limitação predefinido, o sistema inicia o desempenho de limitação. Como resultado, a geração de calor é reduzida e gradualmente, após a geração de calor e a dissipação se equalizarem, a temperatura do sistema atinge o estado estável.

O diagrama a seguir mostra a relação entre geração de calor, temperatura e desempenho quando o desempenho é limitado para reduzir a geração de calor.

Em ambos os casos mostrados nos diagramas anteriores, as cargas de trabalho devem operar dentro de um envelope térmico para garantir que a temperatura do sistema não exceda os limites seguros. O envelope começa com a temperatura ambiente e termina com a temperatura de limitação. Também em ambos os casos, a geração de calor e a dissipação eventualmente atingem um estado equilibrado, e a temperatura do sistema é estabilizada.

Definindo um envelope térmico

Um computador bem projetado deve ter o maior número possível de envelopes térmicos, proporcionando aos usuários uma experiência duradoura e livre de mitigação. Conforme mostrado nos diagramas anteriores, o envelope térmico tem um limite inferior determinado pela temperatura ambiente. Ele é limitado acima pela temperatura de limitação. Embora a temperatura ambiente não seja uma variável que os designers do sistema podem controlar, o limite superior pode ser enviado por push por um bom design de hardware. Para obter mais informações, consulte Modelagem e avaliação térmicas de hardware. Mas mesmo supondo que o hardware não seja a principal limitação, outros fatores importantes devem ser considerados ao definir o envelope térmico.

O intervalo operacional desejado deve ser o maior possível sem invadir esses fatores limitantes:

• Segurança

  A temperatura do sistema deve primeiro garantir que os usuários não sofram ferimentos ao usar o sistema. Esse requisito se aplica principalmente ao sensor de temperatura da pele.

• Proteção de hardware

  A temperatura deve impedir que os componentes do sistema "desabilitar" ou causar danos devido ao calor. Esse requisito se aplica principalmente a sensores de temperatura do componente, por exemplo, um sensor que fica na parte superior do processador.

• Regulamentação governamental

  Todos os sistemas devem atender aos padrões aplicáveis do setor (como o IEC 62368) para segurança de eletrônicos de consumo.

Modelagem e avaliação térmicas de hardware

Software como complemento ao design de hardware

Ao projetar hardware, é importante ter em mente o gerenciamento térmico. Selecionar partes de baixa potência, colocar componentes quentes longe uns dos outros e incorporar isolamento térmico são apenas alguns exemplos de como o hardware pode melhorar muito a experiência térmica. Esses métodos não podem ser substituídos no software. Dessa forma, a solução de software serve apenas como um complemento ao design de hardware na experiência térmica geral.

Meta de hardware

As cargas de trabalho típicas não devem precisar de nenhuma forma de mitigação térmica de software para serem executadas. O design térmico de hardware deve ser capaz de dispersar o calor para essas cargas de trabalho por si só.

Modelagem

A modelagem é um processo iterativo para atingir a meta de hardware descrita anteriormente. Nesse processo, não considere nenhuma mitigação de software. Dependa exclusivamente dos recursos de hardware e ajuste conforme necessário.

1. Defina uma carga de trabalho típica. Dependendo da plataforma do sistema, do telefone ao servidor, cada sistema deve ter um conjunto padrão de cargas de trabalho típicas. Elas não devem ser cargas de trabalho intensas, como videoconferência HD, mas sim uma carga de trabalho mais média, como navegar na Web ou ouvir música.

2. Sistema de modelos e consumo de energia de componente individual em cargas de trabalho típicas, pois o calor não será espalhado pelo chassi uniformemente. Preste atenção especial aos componentes que consomem mais energia, como o processador.

3. Com base na estimativa de consumo de energia da carga de trabalho, modele o aumento do componente e da temperatura da pele ao longo do tempo.

4. Ajuste o design mecânico do sistema para garantir que a temperatura do componente esteja dentro do limite de segurança do hardware e do limite de conforto do usuário em todas as temperaturas ambientes. Alguns métodos para resolver problemas de design mecânico são:

   1. Melhore a capacidade de dissipação de calor adicionando melhores materiais de condução de calor.
   2. Aumente a temperatura delta entre a pele e a temperatura interna adicionando camadas de isolamento.

5. Repita as etapas de 1 a 4 até que sejam atendidas.

6. Crie o hardware e avalie.

Evaluation

Para cada revisão de hardware, uma medição de temperatura e energia em relação a cargas de trabalho representativas deve ser executada para avaliar o comportamento térmico e o design mecânico deve ser modificado conforme necessário.

As seguintes etapas são recomendadas para executar essa avaliação térmica:

1. Defina uma matriz de teste de medida térmica:

   1. A matriz deve abranger a temperatura ambiente normal e máxima.
   2. A matriz deve incluir todas as cargas de trabalho típicas identificadas como parte da modelagem térmica e, para cada carga de trabalho, os dados devem ser capturados por pelo menos uma hora.
   3. A matriz deve ser executada em vários computadores várias vezes para gerar resultados consistentes.

2. Para cada carga de trabalho definida na matriz de teste, capture os seguintes dados:

   1. Dados de consumo de energia do sistema e do componente.
   2. Dados de ambiente, componente interno e temperatura da pele.
   3. Rastreamentos de software para detectar limitação térmica, métricas de desempenho e utilização do processador.

Os dados de temperatura da pele e do componente indicam diretamente a temperatura máxima da pele que o sistema pode atingir e se essa temperatura é aceitável. Considere a quantidade de espaço térmico que o sistema pode ter antes do desligamento crítico. Os dados de métricas de desempenho ajudarão a determinar se o sistema está fornecendo o desempenho necessário. Os dados de rastreamento registrados pelo software de limitação térmica mostram o percentual de limitação térmica. Os dados de consumo de energia e os dados de utilização da CPU podem ajudar a determinar quais fatores influenciam as alterações de temperatura.

A tabela a seguir fornece um exemplo dessa coleta de dados para um computador com a seguinte configuração:

Configuration

• Nome do computador: Teste térmico-1
• Temperatura ambiente média: 23^oC
• Ponto de viagem de zona térmica (_PSV): 80^oC

Categoria	Subcategoria	Streaming de vídeos	Jogos casuais	Aquário	Jogos 3D	TDP
Configuração da carga de trabalho		Streaming de vídeo H.264 de tela inteira por meio de Wi-Fi	Nome do jogo Utilização da CPU	IE clássico com 100 peixes	Nome do jogo Utilização da CPU	CPU e GPU 100%
Consumo de energia	Energia do sistema
	Energia soc
	Poder de exibição
	Energia da luz de fundo
Temperatura	Temperatura máxima do SoC
	Temperatura máxima da pele
Métricas de desempenho		Taxa média de quadros	Taxa média de quadros	Taxa média de quadros	Taxa média de quadros

Estrutura de gerenciamento térmico do Windows

A estrutura de gerenciamento térmico do Windows fornece uma solução abrangente para o gerenciamento térmico de software. Os exemplos a seguir mostram como implementar o gerenciamento térmico. Com modelagem térmica adequada, validação e design mecânico térmico eficaz, todos os sistemas devem ser capazes de proporcionar uma experiência suave do usuário na maioria das cargas de trabalho na maioria das temperaturas ambientes direcionadas. Quando a mitigação térmica é necessária, o Windows fornece uma arquitetura de gerenciamento térmico eficaz e extensível.

O gerenciamento térmico do Windows dá suporte ao resfriamento ativo e passivo. Com o resfriamento ativo, os ventiladores ligam para circular o ar e ajudar a resfriar o sistema. Com o resfriamento passivo, os dispositivos reduzem o desempenho do dispositivo em resposta a condições térmicas excessivas. Reduzir o desempenho reduz o consumo de energia e, portanto, gera menos calor.

A estrutura de gerenciamento térmico do Windows depende das políticas especificadas pelos designers do sistema para impor o gerenciamento térmico no sistema. Em um alto nível, os designers devem especificar como a leitura obtida de cada sensor térmico é afetada por cada componente. Sem essas especificações, o Windows não pode gerenciar o sistema de maneira térmica. Portanto, é responsabilidade de cada designer de sistema caracterizar seu sistema térmicamente para alcançar um bom design térmico.

Embora os sistemas não sejam necessários para usar a estrutura de gerenciamento térmico do Windows, ela é a solução recomendada devido à sua forte integração com o sistema operacional. No entanto, independentemente da solução de gerenciamento térmico usada, todos os computadores em espera modernos devem aderir aos requisitos de HCK para fins de diagnóstico.

Arquitetura de gerenciamento térmico

A arquitetura de gerenciamento térmico do Windows baseia-se no conceito de ACPI de zonas térmicas. O modelo de zona térmica ACPI requer cooperação entre o firmware, o sistema operacional e os drivers. Esse modelo abstrai os sensores e os dispositivos de resfriamento do componente de gerenciamento térmico central por meio de interfaces bem definidas. Os aprimoramentos de gerenciamento térmico baseiam-se no Capítulo 11 da especificação acpi 5.0. A estrutura de gerenciamento térmico do Windows implementa um subconjunto dos recursos descritos neste capítulo.

Os componentes essenciais do modelo são:

• Definições de zona térmica de plataforma descritas para o Windows por meio do firmware. Uma zona térmica é uma entidade abstrata que tem um valor de temperatura associado. O sistema operacional monitora essa temperatura para que possa aplicar mitigação térmica a dispositivos dentro da zona. A zona contém um conjunto de dispositivos funcionais que geram calor e um subconjunto de dispositivos cuja geração de calor pode ser controlada ajustando o desempenho.
• Um sensor de temperatura que representa a temperatura da região. O sensor deve implementar a interface Temperatura de Leitura para recuperar a temperatura de uma zona do firmware ou de um driver de temperatura do Windows.
• Uma interface de resfriamento térmico para habilitar drivers para dispositivos dentro de zonas térmicas para implementar ações de resfriamento passivo. Cada driver gerenciado deve ter a interface de resfriamento para participar da infraestrutura térmica do Windows.
• Um gerenciador térmico centralizado que orquestra o resfriamento interpretando as definições de zona térmica e invocando as interfaces nos horários necessários. O gerenciador térmico é implementado no kernel do Windows e não requer nenhum trabalho dos designers do sistema.

O diagrama de bloco a seguir é uma visão geral da arquitetura de gerenciamento térmico do Windows. Os componentes main são o gerenciador térmico, a zona térmica, os drivers gerenciados e o sensor de temperatura. A zona térmica determina o comportamento de limitação de seus dispositivos gerenciados com base nas restrições fornecidas pelo gerenciador térmico. O algoritmo usado pelo gerenciador térmico usa a leitura de temperatura do sensor para a zona térmica como parâmetro de entrada.

As zonas térmicas no sistema devem ser descritas no firmware ACPI e expostas ao gerenciador térmico por meio da ACPI. Com as informações de configuração, o gerenciador térmico sabe quantas zonas térmicas precisam ser gerenciadas, quando iniciar a limitação de cada zona térmica e quais dispositivos fazem parte da zona. Para monitorar a temperatura, o designer do sistema fornece suporte no firmware ACPI para notificações térmicas.

Quando o gerenciador térmico for notificado de um evento térmico em uma zona enumerada, ele começará a avaliar periodicamente a temperatura da zona e determinar o percentual de desempenho de limitação térmica a ser aplicado aos dispositivos na zona térmica. Essa avaliação é feita pelo algoritmo de limitação térmica que é descrito na especificação de ACPI. Em seguida, o gerenciador térmico notifica todos os dispositivos na zona para limitar o desempenho em uma porcentagem específica e os drivers de dispositivo convertem a porcentagem de limitação em uma ação específica da classe de dispositivo para reduzir o desempenho. A avaliação periódica e a limitação serão interrompidas quando a temperatura da zona térmica ficar abaixo da temperatura do limite de limitação e não for necessária mais limitação.

Retroalimentação

Outra maneira de pensar na arquitetura de gerenciamento térmico é em termos de entradas, diretor de política e dispositivos gerenciados. No diagrama de bloco a seguir, as entradas para o loop de comentários são a temperatura e a corrente elétrica. Essas entradas são usadas para determinar a política térmica a ser implementada. O gerenciador térmico depende exclusivamente da entrada de temperatura e o driver de política pode usar qualquer entrada desejada. Em seguida, a zona térmica aplica essa política aos drivers gerenciados. Depois que a política for aplicada, os sensores atualizarão seus valores e fecharão o loop.

O diagrama de bloco a seguir mostra os três estágios do modelo de resposta térmica. As entradas dos sensores de temperatura e corrente elétrica fornecem informações para ajudar a determinar qual política térmica deve ser aplicada. Essa política é aplicada aos drivers gerenciados, o que afeta as leituras nos sensores. O processo se repete em um loop de comentários.

Responsabilidades dos implementadores do sistema

Conforme mencionado acima, vários componentes são necessários para ter uma solução térmica completa do Windows. A arquitetura da estrutura térmica foi projetada especificamente para que as responsabilidades do fornecedor de hardware e do integrador do sistema possam ser separadas.

Os componentes necessários para os parceiros implementarem são:

• Sensores

  Os drivers do sensor de temperatura devem ser fornecidos pelo fornecedor de hardware. Considerando que os sensores de temperatura não precisam de conhecimento das zonas térmicas que dependem delas, suas funcionalidades devem ser padrão em diferentes designs de plataforma. Sensores personalizados para drivers de política, como sensores atuais, também são de responsabilidade do fornecedor de hardware.

• Zonas térmicas

  As zonas térmicas podem ser definidas pelo fornecedor de hardware e/ou pelo integrador do sistema. Todos os sistemas devem ter pelo menos uma zona térmica que implemente uma temperatura de desligamento crítica (e temperatura de hibernação, se houver suporte), o que pode ser feito pelo fornecedor de hardware ou pelo integrador do sistema. No entanto, para outras zonas térmicas que monitoram dispositivos específicos ou a temperatura da pele para mitigação, é comum que o integrador do sistema tenha conhecimento mais específico do comportamento térmico do sistema. Portanto, essas zonas térmicas geralmente são implementadas pelo integrador do sistema.

• Interface de resfriamento térmico para drivers de dispositivo

  O desenvolvedor que grava o driver para o dispositivo que deve ser gerenciado térmicamente também deve ser o único a implementar a interface de resfriamento. O driver do dispositivo usa essa interface para aceitar a estrutura de gerenciamento térmico. Os drivers de dispositivo têm conhecimento específico dos recursos de seus dispositivos. Esses mesmos drivers devem implementar a interface de resfriamento térmico para que ela possa interpretar corretamente as ações solicitadas pela zona térmica.

Sensores

Os sensores fornecem entradas para determinar qual deve ser a política térmica. O Windows dá suporte apenas a sensores de temperatura como entradas para o gerenciador térmico. No entanto, um driver de política também pode receber entradas de drivers personalizados, como um driver de sensor atual.

Sensor de temperatura

O sensor de temperatura fornece os seguintes modos de funcionalidade:

• Monitora continuamente as alterações de temperatura sem o envolvimento do gerenciador térmico ou da zona térmica.
• Notifica o gerenciador térmico quando a temperatura ultrapassa o limite definido por _PSV, _HOT ou _CRT.
• Responde a consultas de temperatura e retorna o valor de temperatura atual.

O diagrama a seguir mostra como o monitoramento de temperatura funciona durante a limitação. O firmware acpi ou o driver do sensor de temperatura devem notificar o gerenciador térmico quando a temperatura atingir um limite predefinido, como _PSV, _HOT ou _CRT e responder às consultas periódicas do gerenciador térmico para a temperatura atual. O período da consulta de temperatura é definido por _TSP.

Para garantir que o gerenciador térmico sempre será notificado quando a temperatura exceder o limite, a interrupção do sensor de temperatura deve ser sempre ativada (mesmo quando o sistema estiver em Espera Moderna e o SoC estiver em um estado de baixa potência). Se a interrupção do sensor de temperatura nem sempre for ativada, pelo menos a interrupção deverá ser configurada como disparada em nível para evitar possíveis perdas de interrupção.

Um sensor térmico pode ser usado por várias zonas térmicas, embora não possa haver mais de um sensor térmico em uma zona térmica.

Recomendamos que o hardware do sensor seja preciso para +/- 2^oC.

A temperatura relatada por _TMP ou um driver de sensor de temperatura pode ser o valor real de um sensor ou um valor extrapolado com base em vários sensores.

Isso geralmente é fornecido pelo fornecedor de hardware. O Windows dá suporte a duas implementações para monitorar a temperatura:

• Driver do sensor de temperatura
• Baseado em ACPI

Implementação 1: Driver do sensor de temperatura

O driver do sensor de temperatura simplesmente relata a temperatura do sensor. O driver acpi emitirá um IOCTL pendente com o driver do sensor para detectar uma travessia de um dos pontos de viagem. Além disso, a ACPI pode emitir um IOCTL sem tempo limite para ler a temperatura atual. O driver do sensor deve lidar com o cancelamento do IOCTL de leitura, se ele for cancelado enquanto aguarda o tempo limite expirar. O sensor de temperatura deve implementar a seguinte interface:

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)

A tabela a seguir descreve os parâmetros de entrada e saída para a interface de leitura de temperatura.

Parâmetro	Descrição
Tempo Limite	O tempo de espera antes de retornar dados de temperatura, em milissegundos. 0 indica que a temperatura deve ser lida imediatamente, sem espera. -1 indica que a leitura não deve ter tempo limite.
LowTemperature	O limite mais baixo para retornar a nova temperatura. Assim que a temperatura cair abaixo do limite de temperatura baixa, o driver deverá concluir o IOCTL. Se a temperatura já estiver abaixo da baixa temperatura, o IOCTL deverá ser concluído imediatamente.
HighTemperature	O limite superior para retornar a nova temperatura. Assim que a temperatura subir acima do limite de temperatura alta, o driver deverá concluir o IOCTL. Se a temperatura já estiver acima da alta temperatura, o IOCTL deverá ser concluído imediatamente.
Valor retornado de IOCTL	Um buffer de saída do tamanho ULONG que retornará a temperatura atual, em décimos de grau Kelvin.

Um sensor de temperatura pode ser usado por uma zona térmica ou várias zonas térmicas. Para especificar qual sensor de temperatura deve ser usado para uma zona térmica, a _DSM térmica deve ser especificada na zona térmica e deve implementar a função 2. (Para compatibilidade com versões anteriores, o driver do sensor de temperatura pode ser carregado sobre a pilha de zona térmica. No entanto, a implementação preferencial é ter o driver do sensor separado da pilha de zona térmica.) Essa _DSM é definida da seguinte maneira:

ArgumentosArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 2 Arg3: Um pacote vazio Retornar Uma única Referência ao dispositivo que retornará a temperatura da zona térmica.

A zona térmica também deve especificar uma dependência no dispositivo do sensor de temperatura com _DEP. Aqui está um exemplo simples para _DSM implementação de um dispositivo de 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 obter mais informações, consulte Método específico do dispositivo para extensões térmicas da Microsoft.

Implementação 2: baseado em ACPI

O firmware acpi deve dar suporte a _TMP e notificar 0x80, conforme definido na especificação acpi. A vantagem dessa abordagem é que ela não exige que nenhum driver adicional seja instalado no sistema. No entanto, essa abordagem é limitada à interação com recursos acessíveis por meio de regiões de operação do ACPI.

Controle de política térmica

Zona térmica

Uma zona térmica é uma entidade de limitação térmica individual. Ele tem suas próprias características de limitação térmica, como pontos de viagem, taxa de exemplo de limitação e constantes de equação de limitação. Uma zona térmica pode incluir vários dispositivos de limitação térmica, cada um dos quais pode contribuir para aumentos de temperatura na zona térmica. Todos os dispositivos na mesma zona térmica devem seguir as mesmas restrições aplicadas à zona térmica.

Para garantir que as zonas térmicas e seus parâmetros sejam definidos com precisão, os designers do sistema devem:

• Identifique os pontos quentes no chassi do sistema e determine como esses pontos quentes dissipam o calor para os sensores de temperatura. (Idealmente, os sensores térmicos estão sentados nos pontos quentes do sistema, exceto para sensores de temperatura da pele.)
• Caracterizar a relação de temperatura do sistema. Mapeie as leituras do sensor de temperatura para a temperatura do componente e a temperatura da pele.

Limite de excesso de detalhamento

Começando com Windows 10, um novo recurso chamado estado de zona térmica foi introduzido no gerenciamento térmico do Windows, juntamente com um estado: overthrottled. Quando uma zona térmica exceder o nível de aceleração projetado pelo dispositivo, o gerenciador térmico notificará os componentes do sistema operacional de que o sistema está sobrecarregado. Essa notificação permite que o sistema reduza a carga de trabalho para melhorar o estado térmico.

O gerenciador térmico mantém uma contagem global do número de zonas térmicas que estão no estado de excesso de energia. Quando a contagem aumenta acima de zero (0), o gerenciador térmico envia uma notificação do WNF (Windows Notification Facility) para o sistema, indicando que ele está sobrecarregado. Quando o número de zonas superthrottled retorna a zero (0), o gerenciador térmico envia outra notificação WNF para o sistema, indicando que não há zonas excessivas.

Para especificar o limite de excesso de capacidade para uma zona térmica, a _DSM térmica deve ser especificada na zona térmica, com a função 3 implementada. Essa _DSM é definida da seguinte maneira:

ArgumentosArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 3 Arg3: um pacote vazio Retornar um valor Inteiro com o limite de excesso de capacidade atual, expresso como uma porcentagem.

Aqui está um exemplo _DSM que indica que a zona é superestimada, com níveis de aceleração de 0% a 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

O limite de excesso de energia será lido novamente quando um Notify(0x81) for recebido em referência à zona térmica.

Implementando objetos ACPI

A tabela a seguir lista todos os objetos ACPI que precisam ser implementados no firmware ACPI para definir uma zona térmica.

Categoria	Método control
Identificar os dispositivos contidos na zona	_TZD Lista os dispositivos na zona térmica. _PSL (Opcional) Lista os processadores na zona térmica. Em vez disso, os processadores podem ser incluídos no _TZD — o Windows dá suporte a ambas as implementações.
Especificar limites térmicos nos quais as ações devem ser tomadas	_PSV A temperatura na qual iniciar a limitação. Para obter mais informações, consulte Definindo um envelope térmico. _QUENTE (Opcional) A temperatura na qual o sistema operacional hiberna o sistema. Para sistemas que não dão suporte à hibernação, o sistema operacional iniciará o desligamento crítico. Isso é altamente recomendado para pelo menos uma zona térmica para todos os sistemas x86/x64 devido ao benefício da hibernação para salvar dados do usuário. _CRT A temperatura na qual o sistema operacional inicia o desligamento crítico. Nenhuma notificação de modo de usuário. Pelo menos uma zona térmica em um sistema deve ter _CRT especificado. Caso contrário, o sistema não passará pelo caminho de desligamento quando o sistema atingir a temperatura crítica. Em vez disso, o ponto de viagem com falha de firmware é atingido e a energia provavelmente é extraída do sistema operacional.
Descrever o comportamento de resfriamento passivo	_TC1 Controlar a agressividade com que o gerenciador térmico aplica o desempenho de limitação térmica contra a alteração de temperatura. _TC2 Controlar a agressividade com que o gerenciador térmico aplica o desempenho de limitação térmica ao delta de temperatura entre a temperatura atual e a _PSV. _TSP Intervalo de amostragem de temperatura apropriado para a zona em décimos de segundo. O gerenciador térmico usa esse intervalo para determinar com que frequência deve avaliar o desempenho da limitação térmica. Deve ser maior que zero. Para obter mais informações, consulte Algoritmo de limitação térmica.
Descrever o comportamento de resfriamento ativo	_ACx (Opcional) A temperatura na qual ligar o ventilador. Deve ser na ordem do maior para o mínimo, com _AC0 sendo maior. _Alx Lista de dispositivos de resfriamento ativos.
Definir a política de resfriamento ativo/passivo	_SCP (Opcional) Para definir a política de resfriamento preferencial do usuário, se o resfriamento ativo e passivo tiver suporte de uma zona.
Limite mínimo de limitação	_DSM Use UUID: 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 para definir o limite mínimo de limitação. Observe que isso é personalizado para a estrutura térmica do Windows e não está definido no ACPI. Para obter mais informações, consulte Limite mínimo de limitação.
Temperatura do relatório	_TMP Leia a temperatura da zona térmica. _ESCONDEU Um identificador de hardware exclusivo do fornecedor para carregar o driver de temperatura do Windows. _DTI (Opcional) Para notificar o firmware da plataforma de que um dos limites térmicos da zona foi excedido. Esse método permite que o firmware implemente a histerese alterando os limites da zona. _NTT (Opcional) Para especificar alterações de temperatura significativas das quais o firmware da plataforma também deve ser notificado por meio de _DTI.
Notificar o gerenciador térmico	Notificar 0x80 Notifica o sistema operacional de que o limite (_PSV) foi excedido. O gerenciador térmico do Windows iniciará o controle térmico. Notificar 0x81 (Opcional) Notifica o sistema operacional de que os valores de limite da zona foram alterados. O gerenciador térmico do Windows se atualizará para usar os novos valores. Esse método normalmente é usado para implementar a histerese.
Especificar dispositivo de sensor de temperatura	_DSM Use UUID: 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500. Para obter mais informações, consulte Sensor de temperatura. _DEP Carregue um dispositivo ao qual o sensor de temperatura se refere.

Limite mínimo de limitação

O limite mínimo de limitação é uma extensão térmica da Microsoft _DSM método que cria um limite inferior para _PSV solicitado de um dispositivo limitado. Em outras palavras, ele determina quanto uma zona térmica limita o desempenho dos dispositivos que controla. Se presente, o _DSM mínimo de restrição será lido na inicialização e sempre que a zona térmica receber a Notificação de ACPI (0x81). Em cada iteração do algoritmo de resfriamento passivo, o seguinte é usado para calcular a alteração no limite de desempenho (DP) que o gerenciador térmico aplica aos dispositivos na zona:

DP [%] = _TC1 × (Tn – Tn₋₁) + _TC2 × (Tn – Tt) Em seguida, usamos o seguinte para calcular o limite de desempenho real:

Pn = Pn₋₁ – DP Com o MTL (limite mínimo de limitação) implementado, esta segunda equação muda para:

Pn = max(Pn₋₁ – DP, MTL) Para especificar o limite mínimo de limitação para uma zona térmica, o _DSM térmico deve ser especificado na zona térmica, com a função 1 implementada. Essa _DSM é definida da seguinte maneira:

ArgumentosArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 1 Arg3: um pacote vazio Retornar um valor Inteiro com o limite mínimo atual, expresso como uma porcentagem.

Aqui está um exemplo simples para _DSM limitar a limitação não menos que 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)
                    }
                }
            }
        }
    }

Gerenciador térmico no kernel

O gerenciador térmico do Windows é implementado como parte do kernel do Windows. Ele monitora a temperatura de todas as zonas térmicas e aplica a limitação térmica conforme apropriado.

Sempre que o gerenciador térmico consultar o driver acpi quanto à temperatura atual, ele executará um cálculo de quanto percentual de desempenho de limitação térmica deve ser aplicado a todos os dispositivos de limitação térmica na zona térmica. O limite térmico é avaliado e aplicado quando o limite passivo de resfriamento (_PSV) é excedido e em cada intervalo de amostragem de temperatura (_TSP) até que a temperatura seja resfriada abaixo dele e o limite térmico retorne a 100%. O hardware deve detectar quando o _PSV foi excedido e deve sinalizar isso por meio de uma notificação de evento ACPI de hardware.

Algoritmo de limitação térmica

O algoritmo de limitação térmica usa a seguinte equação, que é definida na especificação acpi:

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

Tn = leitura de temperatura atual do sensor de temperatura na zona térmica em décimos de grau Kelvin. Tn₋₁ = temperatura da leitura anterior. Tt = temperatura-alvo em décimos de grau Kelvin (_PSV). DP = alteração de desempenho necessária. Esse é um valor linear entre 0 (totalmente limitado) e 100% (sem restrições), que deve ser aplicado a cada dispositivo de resfriamento na zona. Esta equação descreve o loop de comentários entre as alterações de temperatura e o desempenho de limitação. Em cada iteração do loop, o delta de temperatura entre as leituras de temperatura atuais e anteriores requer que o desempenho P diminua por porcentagem de DP. O valor DP é a quantidade de limitação térmica a ser aplicada. Muitos dispositivos de resfriamento não têm uma resposta térmica linear a mitigações de resfriamento. Nesses dispositivos, o limite térmico é uma dica para o dispositivo para indicar quanto resfriamento é necessário. Cada dispositivo de resfriamento terá seu próprio mapeamento desse valor linear para mitigações térmicas específicas do dispositivo. A limitação do desempenho do dispositivo reduz o consumo de energia e a geração de calor, o que faz com que a temperatura diminua.

As duas constantes, _TC1 e _TC2, controlam o quão agressivamente a limitação térmica é aplicada neste loop de comentários. Quanto maior _TC1 é, mais agressivamente a limitação térmica é usada para manter uma temperatura estável. Quanto maior _TC2 é, mais agressivamente a limitação térmica é usada para empurrar a temperatura perto do ponto de viagem.

A tabela a seguir fornece um exemplo de como o gerenciador térmico calcula e aplica o DP. Este exemplo usa os seguintes valores de parâmetro:

Configuration

• _PSV = 325^oK
• _TC1 = 2
• _TC2 = 3
• _TSP = 5000 milissegundos
• Suponha que a temperatura suba continuamente 1 grau a cada 5 segundos.

A coluna mais à direita na tabela a seguir (rotulada como P) indica o nível de desempenho limitado resultante da imposição das restrições especificadas por esses parâmetros.

Iteração	Hora	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 s	320oK	= 2 × 1 + 3 × 4 = 14%	62%
5	20 segundos	330oK	= 2 × 1 + 3 × 5 = 17%	45%
...

Driver de política

Por padrão, o algoritmo usado para determinar a porcentagem de limitação conforme ditado pelas especificações de ACPI é usado para todas as zonas térmicas. Conforme descrito anteriormente, esse algoritmo é baseado apenas no sensor de temperatura anexado à zona térmica, o que pode ser limitador.

Se um algoritmo diferente for preferencial, o designer de sistema poderá implementar um driver de política para incorporar o algoritmo preferencial. Um driver de política fica sobre a pilha de zona térmica para a zona que ele controla. Para essa zona, o algoritmo do driver de política pode ser usado no lugar do algoritmo ACPI no gerenciador térmico. O algoritmo do driver de política tem a capacidade de considerar qualquer informação que possa acessar como entrada. As decisões de política tomadas pelo motorista são passadas para o gerente térmico, que registra as informações e as passa para a zona térmica a ser executada.

Usar um driver de política para uma zona térmica significa que o driver de política, não o ACPI e não o sistema operacional, é o único responsável por decidir quando limitar uma zona e por quanto.

Se um driver de política estiver presente, todos os pontos de viagem, todas as constantes térmicas, o limite mínimo de limitação e assim por diante serão completamente ignorados. O sistema operacional não tem informações sobre por que a zona térmica está definida em seu nível de limitação atual. Alguns benefícios vêm com o uso de um driver de política em vez de uma solução proprietária. Um driver de política aproveita o processo interno de limitação de dispositivos. Qualquer coisa que uma zona térmica possa fazer para fornecer mitigação térmica pode ser feita por um driver de política. Além disso, diagnóstico para gerenciamento térmico do Windows são herdadas automaticamente.

A interface de política térmica foi atualizada para incluir um novo parâmetro para indicar se a zona está ou não em excesso. Esse parâmetro é inicializado como FALSE. Os drivers de política antigos não estarão cientes do novo parâmetro e os novos drivers saberão que o novo parâmetro tem suporte quando detectarem uma versão de política 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;

O driver de política pode indicar que a zona térmica está sobrecarregada, concluindo a política IOCTL com o parâmetro OverThrottled definido como TRUE. Quando as condições térmicas melhoram, o driver de política térmica pode concluir o IOCTL com OverThrottled redefinido para FALSE, para indicar que a zona térmica se recuperou. O Windows não exigirá que o driver de política seja limitação quando o sinalizador overthrottle estiver definido.

Dispositivos gerenciados térmicamente

As zonas térmicas controlam o comportamento térmico dos dispositivos gerenciados por meio de seus drivers de modo kernel. Um dispositivo de limitação térmica pode residir em várias zonas térmicas. Quando várias zonas térmicas solicitam diferentes percentuais de desempenho de limitação térmica, o gerenciador térmico escolhe o percentual mínimo de desempenho de limitação térmica para aplicar ao dispositivo de limitação térmica.

Muitos dispositivos de resfriamento não têm resposta térmica linear a mitigações de resfriamento. Nesses casos, o limite térmico é uma dica para o dispositivo do grau de resfriamento necessário. Cada dispositivo de resfriamento terá seu próprio mapeamento desse valor linear para suas mitigações térmicas específicas.

À medida que cada driver de dispositivo é carregado, a ACPI consultará a Interface de Resfriamento Térmico e registrará cada dispositivo respondendo como um dispositivo de resfriamento. Posteriormente, quando o resfriamento passivo estiver em processo e o limite térmico de uma zona for alterado, a ACPI chamará essa interface em cada dispositivo de resfriamento na zona. O dispositivo de resfriamento mapeará o limite térmico fornecido para suas características de resfriamento específicas e implementará mitigações de resfriamento apropriadas. Observe que, se o dispositivo de resfriamento aparecer em várias zonas térmicas, o limite térmico que mais restringe o dispositivo (ou seja, o menor percentual) será passado para o dispositivo.

Nota O Windows fornece implementações internas de limitação térmica para processadores, luz de fundo e bateria do método de controle ACPI.

Interface de resfriamento térmico

O Windows fornece os pontos de extensão para que os drivers de dispositivo se registrem como dispositivos de limitação térmica e recebam a solicitação de percentual de limitação térmica. Em seguida, o dispositivo é responsável por traduzir esse percentual para uma ação que faz sentido para si mesmo.

Os dispositivos que desejam ser adicionados como um dispositivo de limitação térmica devem primeiro adicionar o _HIDs à lista de dispositivos térmicos da zona térmica e, em seguida, implementar o conjunto de interfaces a seguir. À medida que cada driver de dispositivo é carregado, o ACPI consultará essa interface e registrará cada dispositivo respondendo como um dispositivo de resfriamento. Posteriormente, quando o resfriamento passivo estiver em processo e o limite térmico de uma zona for alterado, a ACPI chamará essa interface em cada dispositivo de resfriamento na zona. O dispositivo de resfriamento mapeará o limite térmico fornecido para suas características de resfriamento específicas e implementará mitigações de resfriamento apropriadas. Observe que, se o dispositivo de resfriamento aparecer em várias zonas térmicas, o limite térmico que mais restringe o dispositivo (ou seja, o menor percentual) será passado para o 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

Processador

Para um processador, o gerenciador térmico comunica a porcentagem de limitação térmica ao PPM (gerenciador de energia do processador). A limitação térmica de processadores é um recurso interno do Windows.

Agregador de processador

O dispositivo agregador de processador permite o estacionamento principal como uma mitigação térmica. As zonas poderão especificar o estacionamento principal como uma mitigação térmica se o dispositivo agregador do processador for membro de uma zona térmica. Os processadores não precisam ser limitados para que o estacionamento principal ocorra. Essa implementação funciona em paralelo com LPI ( idling de processador lógico ). Observe que isso ainda está sujeito às ressalvas do estacionamento principal. Em particular, qualquer trabalho com afinidade com um núcleo estacionado fará com que o núcleo seja executado.

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

Elementos gráficos

Para que um driver de miniporte gráfico de terceiros seja gerenciado térmicamente, ele deve interagir com o driver de porta gráfica do Windows, Dxgkrnl.sys. Dxgkrnl.sys tem a interface de resfriamento térmico e passa todas as solicitações de limitação para o driver de miniporta. É responsabilidade do driver de miniporta traduzir a solicitação para uma ação específica para seu dispositivo.

O diagrama de bloco a seguir mostra a arquitetura da zona térmica que controla a GPU.

Retroiluminação

Reduzir a luz de fundo pode melhorar drasticamente as condições térmicas em uma plataforma móvel. O Windows recomenda que, durante a operação, o brilho de exibição do sistema nunca seja limitado térmicamente a menos de 100 nits.

Para o controle de luz de fundo, o gerenciador térmico comunica o percentual de limitação térmica ao driver de monitor, Monitor.sys. Monitor.sys decidirá a configuração de nível de luz de fundo real com base nessa entrada térmica e em outras entradas no Windows. Em seguida, Monitor.sys aplicará a configuração de nível de luz de fundo por meio do ACPI ou do driver de exibição.

Observe que, se a temperatura da zona térmica que inclui a luz de fundo continuar subindo, a porcentagem de limitação térmica solicitada poderá eventualmente cair para zero por cento. A implementação no nível de luz de fundo no ACPI ou no driver de exibição deve garantir que o nível mínimo de brilho disponível para controles de desempenho ainda esteja visível para os usuários finais.

Nota Durante a operação, o brilho de exibição do sistema nunca é limitado térmicamente a menos de 100 nits.

Bateria

Outro main fonte de calor no sistema é o carregamento de bateria. Do ponto de vista de um usuário, o carregamento deve ser reduzido e até mesmo completamente interrompido em condições térmicas restritas. No entanto, o carregamento da bateria não deve ser prejudicado em casos de uso normais.

Nota Recomendamos que o carregamento da bateria não seja limitado enquanto o sistema estiver (1) ocioso e dentro da faixa de temperatura ambiente abaixo de 35^oC ou (2) em qualquer condição enquanto a temperatura ambiente estiver abaixo de 25^oC.

O driver de miniclasse de bateria do Método de Controle do Windows, Cmbatt.sys, usa diretamente a Interface de Resfriamento Térmico, conforme descrito acima. O firmware é responsável por levar em conta o limite térmico atual ao envolver o carregamento. Um novo método de controle ACPI é necessário para definir o limite térmico para carregamento. Esse método é implementado como um método específico do dispositivo (_DSM), conforme definido na especificação do ACPI 5.0, Seção 9.14.1.

Para aplicar o percentual de limitação térmica, Cmbatt.sys avaliará o método de controle Método Específico do Dispositivo (_DSM) para solicitar que o firmware ACPI defina o limite térmico para carregamento. Dentro do método de controle _DSM, um GUID é definido para indicar o limite térmico.

Arg #	Valor	Descrição
Arg0	4c2067e3-887d-475c-9720-4af1d3ed602e	UUID
Arg1	0	Revisão
Arg2	1	Função
Arg3	Valor inteiro de 0 a 100	Limite térmico para carregamento de bateria. Equivalente à limitação passiva percentual calculada.
Retornar valor	N/D	Nenhum valor retornado

Resfriamento ativo

Do ponto de vista do sistema operacional, uma plataforma tem duas estratégias que pode usar para implementar o controle de ventilador:

• Implemente uma ou mais zonas térmicas ACPI com pontos de viagem ativos para envolver/desativar o ventilador.

  A estrutura térmica do Windows dá suporte a dispositivos de resfriamento ativos em um nível muito básico. A única caixa de entrada com suporte do dispositivo é um ventilador ACPI e só pode ser controlada com o sinal de ativação/desativação.

• Implemente uma solução proprietária para controlar o ventilador (por meio de drivers, um controlador inserido etc.).

  Embora o Windows não controle o comportamento de soluções proprietárias para fãs, o Windows dá suporte a notificações de ventilador para o gerenciador térmico para todas as implementações, incluindo controladores inseridos, para que as informações de diagnóstico e a telemetria possam ser coletadas. Portanto, a exposição de ventiladores ao sistema operacional é necessária para todos os computadores em espera modernos e altamente recomendada para todos os outros.

Observe que a implementação para resfriamento ativo é completamente separada das mitigações de resfriamento passivo discutidas anteriormente.

Controle de ventilador por zona térmica ACPI

O Windows dá suporte à definição de ventilador baseada em estado D do ACPI 1.0. (Para obter mais informações, consulte a especificação de ACPI.) Assim, o controle é limitado ao ventilador ativado e desativado. O driver do ventilador é fornecido no driver ACPI do Windows, Acpi.sys.

1. O sensor de temperatura lê que a temperatura cruzou um ponto de viagem e emite Notify(0x80) na zona térmica associada.
2. A zona térmica lê a temperatura com o método de controle _TMP e compara a temperatura com os pontos de viagem ativos (_ACx) para decidir se o ventilador precisa estar ligado ou desativado.
3. O sistema operacional coloca o dispositivo ventilador em D0 ou D3, o que faz com que o ventilador ative ou desative.

O diagrama de bloco a seguir mostra o fluxo de controle para um ventilador controlado por uma 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 várias velocidades no ACPI

Para obter várias velocidades para um ventilador usando o ACPI 1.0, há duas opções:

• A zona térmica pode conter vários "ventiladores", quando apenas um ventilador físico existe. Ter mais "fãs" ao mesmo tempo se traduz em velocidade mais rápida do ventilador. Para obter mais informações, consulte o exemplo dessa opção na Seção 11.7.2 na especificação do ACPI 5.0.
• Quando o ventilador está ligado, ele pode decidir por si mesmo o quão rápido girar. Sistemas com controladores inseridos, por exemplo, podem escolher essa opção.

Solução proprietária para fãs

O Windows precisa ser capaz de detectar a atividade do ventilador com qualquer implementação. Quando uma plataforma usa o modelo térmico ACPI, o Windows é responsável por ativar e desativar o ventilador e, portanto, já sabe quando está ativo. Quando uma solução proprietária é usada para controlar o ventilador, o Windows precisa de notificação de que o ventilador está em execução. Para habilitar isso, o Windows dará suporte a um subconjunto parcial das extensões de ventilador ACPI 4.0, que estão listadas na tabela a seguir.

Recurso	Descrição	Com suporte
_FST	Retorna o status do ventilador.	sim
Notify(0x80)	Indica que o status do ventilador foi alterado.	sim
_FIF	Retorna informações do dispositivo do ventilador.	não
_FPS	Retorna uma lista de estados de desempenho do ventilador.	não
_FSL	Define o estado de desempenho do ventilador (velocidade).	não

O Windows usará o objeto _FST para determinar se o ventilador está em execução (o campo Controle não é zero) ou desativado (o campo Controle é zero). O Windows também dará suporte a Notify(0x80) no dispositivo ventilador como uma indicação de que _FST foi alterado e precisa ser reavaliado.

Um ventilador que implementa o objeto _FST não precisa estar na lista de dispositivos _ALx de uma zona térmica, mas pode, como opção, estar nesta lista. Essa opção habilita uma solução híbrida na qual um ventilador normalmente é controlado por um driver de terceiros, mas pode ser controlado pela zona térmica do sistema operacional se o driver de terceiros não estiver instalado. Se um ventilador estiver em uma lista de dispositivos _ALx e estiver envolvido pela zona térmica (colocada em D0), o objeto _FST será necessário para indicar um valor de Controle diferente de zero.

Para todos os fãs, o Windows usará o seguinte algoritmo para determinar o estado do ventilador:

1. Se um ventilador estiver em D0 (como resultado do ponto de viagem _ACx de uma zona térmica sendo cruzado), ele será envolvido.
2. Se um ventilador estiver em D3 e não der suporte às extensões do ACPI 4.0, ele será desengajado.
3. Se um ventilador estiver em D3 e der suporte às extensões do ACPI 4.0, o sistema operacional marcar _FST campo Controle para um valor diferente de zero para ver se o ventilador está envolvido.

Exemplo 1: Controle de ventilador de hardware

Neste exemplo, um ventilador é controlado por um controlador inserido.

1. O controlador inserido decide iniciar ou parar o ventilador com base em seu próprio algoritmo interno.
2. Depois de iniciar ou parar o ventilador, o controlador inserido emite um Notify(0x80) no dispositivo ventilador.
3. O sistema operacional avalia _FST e lê o novo estado do ventilador.

O diagrama de bloco a seguir mostra o fluxo de controle para um ventilador controlado por um controlador inserido.

O exemplo de ASL a seguir define um dispositivo "FAN" que pode notificar o sistema operacional de alterações no estado do 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
}

Exemplo 2: Controle do ventilador do driver

Neste exemplo, um driver de terceiros está controlando o ventilador.

1. O driver decide iniciar ou parar o ventilador com base em seu próprio algoritmo interno.
2. O driver modifica o estado do ventilador e avalia um SFST (método de controle personalizado) em seu dispositivo térmico.
3. O método de controle de dispositivo térmico atualiza o conteúdo _FST do dispositivo ventilador e os problemas de Notify(0x80) no dispositivo ventilador.
4. O sistema operacional avalia _FST e lê o novo estado do ventilador.

O diagrama de bloco a seguir mostra o fluxo de controle para um ventilador controlado por um driver de terceiros.

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

Presença de ventilador

Uma plataforma indica que há um ventilador no sistema incluindo um dispositivo de ventilador (PNP0C0B de ID PnP0C0B) no namespace acpi. O Windows assumirá a presença deste dispositivo como uma indicação de que o sistema tem um ventilador e a ausência desse dispositivo como uma indicação de que o sistema não tem ventilador.

Diretrizes específicas para o Modo de Espera Moderno

A estrutura de gerenciamento térmico do Windows faz parte do kernel e é fornecida com todos os sistemas Windows. Assim, o material acima se aplica a todos os computadores. No entanto, vários tipos de computadores exigem diretrizes adicionais mais específicas para o Modo de Espera Moderno.

O Modo de Espera Moderno traz o modelo de energia de telefone inteligente para o computador. Ele fornece uma experiência instantânea e instantânea do usuário que os usuários esperam em seu telefone. Assim como no telefone, o Modo de Espera Moderno permite que o sistema permaneça atualizado, atualizado e acessível sempre que uma rede adequada estiver disponível. Windows 10 dá suporte ao Modo de Espera Moderno em plataformas de baixa potência que atendem a requisitos específicos de certificação do Windows.

Os computadores em espera modernos são dispositivos altamente móveis em um fator de forma fina e leve. Além disso, os computadores em espera modernos estão sempre ativados e no estado ACPI S0. Para oferecer uma experiência de cliente robusta e confiável, todo o sistema, desde o design mecânico até a implementação de firmware e software, deve ser projetado com atenção crítica às características térmicas. Assim, todos os computadores em espera modernos devem seguir os requisitos térmicos.

Requisitos de espera modernos

Todos os computadores em espera modernos devem passar nos seguintes testes de HCK:

• Todos os computadores em espera modernos devem ter pelo menos uma zona térmica para a qual uma temperatura de desligamento crítica (_CRT) é definida. Para sistemas x86, recomendamos definir uma temperatura de hibernação crítica (_HOT) para disparar o salvamento de dados do usuário. _HOT deve ser menor que _CRT e _CRT deve ser menor do que o ponto de viagem térmica com fail safe do firmware.
• Cada zona térmica deve relatar a temperatura real no sensor (_TMP). O teste executa uma carga de trabalho variável no computador e espera-se que a temperatura seja alterada.

Além disso, recomendamos que cada computador inclua pelo menos um sensor de temperatura para o SoC.

Requisitos de resfriamento ativos

Os computadores em espera modernos que usam ventiladores devem seguir os seguintes requisitos adicionais, que são testados no HCK:

• O ventilador deve ser exposto ao sistema operacional. Para obter mais informações, consulte Presença do ventilador.
• O sistema operacional deve saber o tempo todo se o ventilador está ligado ou desativado. Mesmo em resiliência ociosa no Modo de Espera Moderno, todas as alterações na atividade do ventilador devem ativar o SoC para atualizar o status. Para obter mais informações sobre como implementar notificações de ventilador, consulte Controle de ventilador por zona térmica ACPI.
• O ventilador não deve ativar enquanto o computador estiver em Espera Moderna. Com uma carga de trabalho realista durante o Modo de Espera Moderno, que é sempre que a tela está desativada, o ventilador não deve ativar.

Do ponto de vista do usuário, o computador parece estar desativado quando está em Espera Moderna. Os usuários esperam que um computador em Espera Moderna se comporte como se estivesse no estado de "suspensão" do sistema. Assim, os usuários esperam que o ventilador nunca entre, assim como nos computadores tradicionais durante o sono. Se o ventilador entrar, os usuários poderão ouvi-lo e/ou sentir o ar quente circulando e pensar que o computador não está funcionando corretamente. Portanto, o ventilador não deve ativar enquanto estiver em Espera Moderna. Para obter mais informações sobre o comportamento necessário, consulte Requisitos de teste do HCK para computadores em espera modernos.

Esses requisitos implicam que a política de resfriamento quando a tela está ativada pode precisar ser diferente de quando a tela está desativada. O computador pode usar o resfriamento ativo enquanto a tela estiver ativa, mas deve depender apenas do resfriamento passivo quando a tela estiver desativada. O ponto de viagem ativo para o ventilador pode ser muito menor quando a tela está ativada do que quando está desativada. Para a implementação do ACPI, _ACx teria que ser atualizado na entrada para o Modo de Espera Moderno. Para soluções proprietárias, atualize a política no controlador inserido.

Limitação do processador

O PPM comunica os níveis de desempenho máximo, desejado e mínimo para o PEP. Em condições de limitação térmica, o nível de desempenho máximo deve ser igual ao desempenho de limitação solicitado pelo gerenciador térmico. Em seguida, o PEP define a tensão física e a frequência da CPU com base nos requisitos de nível de desempenho do PPM.

Sinal de Ruído do Ventilador

A partir de Windows 11, os dispositivos podem enviar um sinal de ruído do ventilador para o sistema operacional para uso em decisões de gerenciamento de recursos, com o objetivo de fornecer aos usuários uma experiência fria e tranquila. Essa interface de aceitação permite que o firmware envie informações de RPM do ventilador para o sistema operacional como um valor de 0 (fan off) para Max RPM, que o sistema operacional pode usar em decisões de gerenciamento de recursos para resfriar o dispositivo conforme necessário. Isso contribui para dois benefícios principais:

1. Experiência do usuário silenciosa: O ruído do ventilador e a sopração de ar quente são uma fonte significativa de insatisfação do cliente. Isso é especialmente verdadeiro quando o usuário não está esperando atividades pesadas do ventilador, como quando o dispositivo está executando uma baixa quantidade de trabalho ou nenhum trabalho em primeiro plano.
2. Melhor duração da bateria: Velocidades mais altas do ventilador resultam em mais uso de energia, o que causa um dreno de bateria mais rápido enquanto estiver em DC e carregamento mais lento enquanto estiver no AC.

Atualmente, esse sinal pode ser usado para gerenciar tarefas do Indexador de Pesquisa e há planos para habilitar tarefas adicionais em segundo plano para consumir esse sinal também.

O diagrama a seguir resume como o sinal de ruído do ventilador é enviado nas camadas do firmware para o software.

Como funciona o sinal de ruído do ventilador

Detalhes da interface ACPI

Abaixo estão as quatro funções do Método Específico do Dispositivo (_DSM, UUID: A7611840-99FE-41ae-A488-35C75926C8EB) usadas para dar suporte a esse recurso. Informações sobre _FST (Status do Ventilador) podem ser encontradas na seção 11.3.1.4 da especificação acpi e no Exemplo 1: controle de ventilador de hardware de dispositivos gerenciados térmicamente

O diagrama a seguir resume o fluxo de como essas funções são usadas.

O diagrama de bloco a seguir mostra o fluxo de controle para um ventilador controlado por um controlador inserido, incluindo o método de controle Notify(0x80).

Observação

O Fan Noise Signal não controlaria o RPM do Ventilador, mas notificará o sistema operacional de que há ruído de ventilador que requer a movimentação do recurso de CPU de tarefas em segundo plano para concluir o trabalho de prioridade.

Enumerar funções (Função 0)

Para que o sistema operacional interaja com a plataforma, um dispositivo ACPI deve ser exposto por meio do Namespace. Este Dispositivo deve incluir um objeto _CID contendo EISAID("PNP0C0B"). O escopo desse dispositivo deve conter a seguinte definição de _DSM indicando qual _DSMs o dispositivo dá suporte.

UUID	Revisão	Função	Descrição
A7611840-99FE-41ae-A488-35C75926C8EB	0	0	Enumerar funções

Retorno: Para indicar suporte para funções 0 a 3 listadas acima, a função Enumerar Funções (função 0) deve retornar 0xF. Consulte a seção 9.1.1 da especificação acpi para obter mais informações.

Função obter suporte a fan trip point (função 1)

O hardware informa ao sistema operacional o que tem suporte em termos de RPMs.

UUID	Revisão	Função	Descrição
A7611840-99FE-41ae-A488-35C75926C8EB	0	1	Obter suporte ao ponto de viagem de fãs

Argumentos

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

Arg1: Revisão: 0

Arg2: Função: 1

Arg3: Um pacote vazio

Retorno: Um valor inteiro que contém a granularidade com suporte para pontos de viagem de ventilador, em RPMs. Se não for zero, o sistema operacional poderá selecionar pontos de viagem que são um múltiplo da granularidade de notificação. Por exemplo, com uma granularidade de 200, o OSPM teria permissão para selecionar pontos de viagem em 0, 200, 400, 600 etc. Rpms. Um valor igual a 0 indica que não há suporte para pontos de viagem.

Definir função Fan Trip Points (Função 2)

O sistema operacional comunica ao hardware qual é o próximo ponto de viagem de notificação; O hardware notifica o sistema operacional quando isso acontece.

UUID	Revisão	Função	Descrição
A7611840-99FE-41ae-A488-35C75926C8EB	0	2	Obter pontos de viagem de fãs

Argumentos

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

Arg1: Revisão: 0

Arg2: Função: 2

Arg3: Um Pacote que contém os pontos de viagem inferiores e superiores. (2 elemento int. Menor no índice 0, Superior no índice 1)

O OSPM selecionará apenas pontos de viagem que são um múltiplo da granularidade do ponto de viagem especificado na função 1. Quando a velocidade real do ventilador for superior ou inferior aos pontos de viagem superior/inferior, a plataforma deverá emitir Notify(0x80) no dispositivo ventilador. O OSPM avaliará _FST (status de ventilador) para determinar a velocidade atual do ventilador. Se a velocidade do ventilador já estiver fora dos pontos de viagem especificados quando os pontos de viagem estiverem definidos, a plataforma deverá emitir imediatamente Notify(0x80).

O ponto de viagem superior será um múltiplo de granularidade. O ponto de viagem inferior será (múltiplo de granularidade) + 1 (ponto de viagem superior do ponto < de viagem inferior). Quando RPM for 0, o sistema operacional definirá o ponto de viagem inferior como 0 e o ponto de viagem superior como 1.

Retorno: Nenhum.

Função Obter Intervalos Operacionais do Ventilador (Função 3)

Mapeamento entre RPM –> Impacto. Observe que apenas um ventilador (aquele mais próximo do SoC) pode implementar essa interface, ele deve implementar todas as 3 funções mais a função 0 da seção 9.1.1 da especificação ACPI.

UUID	Revisão	Função	Descrição
A7611840-99FE-41ae-A488-35C75926C8EB	0	3	Obter intervalos operacionais do ventilador

Argumentos

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

Arg1: Revisão: 0

Arg2: Função: 3

Arg3: Um Pacote vazio.

Retorno: Um pacote que contém o seguinte formato:

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

Campo	Formatar	Descrição
Impact1MaxRPM	Inteiro (DWORD)	Máximo de RPMs para o intervalo de impacto do ventilador 1.
Impact2MaxRPM	Inteiro (DWORD)	Máximo de RPMs para o intervalo de impacto do ventilador 2. Deve ser >= Impact1MaxRPM.
Impact3MaxRPM	Inteiro (DWORD)	Máximo de RPMs para o intervalo de impacto do ventilador 3. Deve ser >= Impact2MaxRPM.
MaxRPM	Inteiro (DWORD)	Máximo de RPMs em que o ventilador pode operar. Deve ser >= Impact3MaxRPM.

Esta tabela é usada para derivar o intervalo de RPM para cada um dos níveis de impacto do ventilador:

Pontuação de Impacto	Valor de RPM mais baixo	Valor de RPM superior
1	1	Impact1MaxRPM
2	Impact1MaxRPM + 1	Impact2MaxRPM.
3	Impact2MaxRPM + 1	Impact3MaxRPM
4	Impact3MaxRPM + 1	MaxRPM

Se um intervalo de impacto não for usado por uma plataforma (por exemplo, se o ventilador fizer a transição diretamente do intervalo de impacto 2 para o intervalo de impacto 4), isso poderá indicar isso definindo o RPM Máximo para o intervalo de impacto não utilizado igual ao RPM máximo para o intervalo de impacto inferior.

Mapeamento de exemplo

Valor enviado para o sistema operacional	RPM do ventilador	Experiência de usuário	Teto rpm
0 – Baixo	1-4000 RPM (<=25 dBA)	Ventilador não ligado ou ligado com baixo aborrecimento	Impact1MaxRPM = 4000
1 – Médio	4001-5000 RPM (25-30 dBA)	Ventilador ligado com aborrecimento médio	Impact2MaxRPM = 5000
2 – Medium-High	5001-6000 RPM (30-36 dBA)	Ventilador com aborrecimento médio-alto	Impact3MaxRPM = 6000
3 – Alta	6001+ RPM (mais de 36 dBA)	Ventilador com alto aborrecimento	MaxRPM = 9000

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

Teste e rastreamento

Faça referência às seguintes etapas para coletar log e exibição no WPA (Windows Performance Analyzer)::

1. Configurações –> Pesquisa no Windows –> Configurações avançadas do indexador de pesquisa –> Avançado –> Excluir e recompilar o índice (Recompilar)
2. wpr -boottrace -addboot AcpiFanNoiseImpact.wprp –filemode
3. Reiniciar o sistema
4. Verificar status de Índice de Configurações –> Pesquisa no Windows (verifique se o dispositivo se conecta com a fonte de energia ac.)
5. Quando o índice for concluído, interrompa o rastreamento: wpr -boottrace -stopboot AcpiFanNoiseImpact.etl (Cancelar rastreamento sem salvar: wpr -boottrace –cancel)
6. Abra AcpiFanNoiseImpact.etl por meio do WPA (Windows Performance Analyzer).

Baixe o arquivo em AcpiFanNoiseImpact.zip Ou, copie o seguinte e salve 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>

A imagem abaixo é um exemplo de grafo WPA mostrando o trabalho do Indexador de Pesquisa fazendo backup quando o ventilador está alto.

Há um nível do ventilador que faria o índice de pesquisa voltar na íntegra (o mais alto, que deve ser a pontuação de impacto 4), mas todos os outros níveis do ventilador devem ser atividade reduzida e não suspensão. Por exemplo, se a ACPI declarasse Impact3MaxRPM = 4000 RPM na função 3 (função Obter intervalos operacionais de ventilador), quando o RPM > do ventilador 4000 (4100RPM, 4500RPM), veríamos SearchIndexer.exe e SearchProtocalHost.exe o uso da CPU seria suspenso.

Observação

Para ver o Uso da CPU, você pode usar wpr -start power -filemode para coletar o uso de runtime. Use wpr -stop fan_noise.etl para parar de coletar log.

A imagem abaixo mostra um exemplo de grafo WPA mostrando a suspensão de SearchIndexer.exe e SearchProtocolHost