Guida alla progettazione
Questa guida alla progettazione della gestione termica del PC fornisce informazioni su come determinare i valori di temperatura del PC "troppo caldo" e "troppo freddo".
L'esecuzione di queste decisioni è un requisito fondamentale per una progettazione che offre un'esperienza utente di PC ottimale. Inoltre, queste soglie consentono di scegliere la prima azione di mitigazione da intraprendere per i componenti PC che risiedono in più zone termiche.
Progettazione delle soglie di temperatura
Variabili e presupposti
I fattori seguenti influiscono sul comportamento termica di un PC:
Progettazione hardware
L'importanza di una buona progettazione hardware non può essere eccessivamente stressata. Per altre informazioni, vedere Modellazione termica hardware e valutazione.
Environment
Questi sono fattori esterni che contribuiscono al comportamento termica del sistema. Il software può influire solo sull'ambiente notificando all'utente che i vincoli termica sono un problema, ad esempio visualizzando il logo di avvio a errore termica. L'utente deve passare a un ambiente diverso per questi fattori da modificare:
Radiazione solare
L'intensità e l'angolo della luce solare che influisce sullo schermo o su qualsiasi parte del sistema.
Temperatura ambiente
Temperatura dell'ambiente.
Flusso d'aria
Con o senza circolazione aerea. Vento o in un caso computer.
Umidità
Secco o umido.
Consumo di carico di lavoro e energia
Il presupposto è che il carico di lavoro e il consumo di energia sono proporzionali tra loro. In altre parole, più funziona un PC o un componente, più energia consuma e il calore che genera. Anche se questo potrebbe non essere vero in tutti i casi, questo modello semplificato è più o meno sufficiente qui. Questo è il punto in cui vengono fornite le mitigazioni software. Riducendo il carico di lavoro, viene generato meno calore e il PC mantiene il funzionamento.
Durante la progettazione e la modellazione dell'hardware, tenere conto dei parametri menzionati nell'elenco precedente. Usare i valori di caso peggiore per l'ambiente. L'unico parametro che può essere controllato direttamente dal software è il carico di lavoro.
Nozioni fondamentali sul calore
Prendere in considerazione il comportamento termica di un PC quando esegue un carico di lavoro costante. Quando inizia il carico di lavoro, i componenti hardware del PC, ad esempio la CPU e la GPU generano calore e aumentano la temperatura. Quando la temperatura aumenta rispetto alla temperatura ambientale, il PC inizia a dissipare il calore più velocemente fino alla fine la generazione di calore è uguale alla dissipazione del calore e la temperatura raggiunge lo stato costante. Per l'intera durata di questo carico di lavoro costante, poiché non sono presenti limitazioni, le prestazioni e la velocità effettiva sono costanti.
Il diagramma seguente illustra la relazione tra generazione di calore, temperatura e prestazioni quando non è coinvolto alcun limite. Si noti che la temperatura del PC rimane all'interno della busta termica, come delimitato dalla temperatura ambientale e dalla temperatura di limitazione.
Si consideri ora il comportamento termica di un PC quando esegue un carico di lavoro diverso che è costante ma più intensivo delle risorse. Poiché questo carico di lavoro viene eseguito, il calore generato è molto superiore a quello che il sistema è in grado di dissipare nell'ambiente ambientale e di conseguenza la temperatura aumenta costantemente. Senza raffreddamento passivo, la temperatura continuerà a salire fino a quando il sistema diventerà troppo caldo e influisce negativamente sul comfort e sulla sicurezza degli utenti finali. L'hardware può essere danneggiato anche a temperature elevate. La limitazione termica consente di garantire che il PC non raggiunga queste temperature elevate. Quando la temperatura aumenta su un punto di viaggio della temperatura pre-definito, il sistema avvia le prestazioni di limitazione. Di conseguenza, la generazione di calore viene ridotta e gradualmente, dopo la generazione di calore e la dissipazione, la temperatura del sistema raggiunge lo stato costante.
Il diagramma seguente illustra la relazione tra generazione di calore, temperatura e prestazioni quando le prestazioni sono limitate per ridurre la generazione di calore.
In entrambi i casi illustrati nei diagrammi precedenti, i carichi di lavoro devono operare all'interno di una busta termica per garantire che la temperatura del sistema non superi i limiti sicuri. La busta inizia con la temperatura ambientale e termina con la temperatura di limitazione. Anche in entrambi i casi, la generazione di calore e la dissipazione raggiungono uno stato bilanciato e la temperatura del sistema viene stabilizzata.
Definizione di una busta termica
Un PC ben progettato deve avere una busta termica il più grande possibile, fornendo agli utenti un'esperienza lunga e senza mitigazione. Come illustrato nei diagrammi precedenti, la busta termica ha un limite inferiore determinato dalla temperatura ambientale. È delimitato sopra dalla temperatura di limitazione. Anche se la temperatura ambientale non è una variabile che i progettisti di sistema possono controllare, il limite superiore può essere spostato più alto da una buona progettazione hardware. Per altre informazioni, vedere Modellazione termica hardware e valutazione. Ma anche presupponendo che l'hardware non sia la limitazione principale, è necessario considerare altri fattori importanti quando si definisce la busta termica.
L'intervallo operativo desiderato deve essere il più grande possibile senza incroaching su questi fattori di limitazione:
Sicurezza
La temperatura del sistema deve prima assicurarsi che gli utenti non soffrono di lesioni dall'uso del sistema. Questo requisito si applica principalmente al sensore di temperatura della pelle.
Protezione hardware
La temperatura deve impedire ai componenti di sistema di "fusione" o altrimenti causare danni a causa del calore. Questo requisito si applica principalmente ai sensori di temperatura dei componenti, ad esempio un sensore che si trova sopra il processore.
Regolamentazione del governo
Tutti i sistemi devono soddisfare gli standard di settore applicabili (ad esempio IEC 62368) per la sicurezza elettronica di consumo.
Modellazione termica hardware e valutazione
Software come complemento alla progettazione hardware
Quando si progetta l'hardware, è fondamentale tenere presente la gestione termica. La selezione di parti a bassa potenza, l'inserimento di componenti caldi lontano tra loro e l'incorporamento dell'isolamento termico sono solo alcuni esempi di come l'hardware può migliorare notevolmente l'esperienza termica. Questi metodi non possono essere sostituiti nel software. Di conseguenza, la soluzione software funge solo da complemento alla progettazione hardware nell'esperienza termica complessiva.
Obiettivo hardware
I carichi di lavoro tipici non devono avere alcuna forma di mitigazione termica software da eseguire. La progettazione termica hardware deve essere in grado di disperdere il calore per questi carichi di lavoro da solo.
Modellazione
La modellazione è un processo iterativo per raggiungere l'obiettivo hardware descritto in precedenza. In questo processo, non tenere conto di alcuna mitigazione software. Si basano esclusivamente sulle funzionalità hardware e modificare in base alle esigenze.
Definire un carico di lavoro tipico. A seconda della piattaforma del sistema, dal telefono al server, ogni sistema deve avere un set standard di carichi di lavoro tipici. Questi carichi di lavoro non devono essere intensi, ad esempio videoconferenze HD, ma piuttosto un carico di lavoro più medio, ad esempio la navigazione sul Web o l'ascolto della musica.
Sistema del modello e consumo di energia del singolo componente su carichi di lavoro tipici poiché il calore non verrà distribuito in modo uniforme nello chassis. Prestare particolare attenzione ai componenti che consumano la maggior parte della potenza, ad esempio il processore.
In base alla stima del consumo di energia del carico di lavoro, modellare l'aumento della temperatura del componente e della pelle nel tempo.
Regolare la progettazione meccanica del sistema per garantire che la temperatura del componente sia entro il limite di sicurezza hardware e il limite di comfort utente su tutte le temperature ambientali. Alcuni metodi per risolvere i problemi di progettazione meccanica sono:
- Migliorare la capacità di dissipazione del calore aggiungendo materiali di condotta termica migliori.
- Aumentare la temperatura differenziale tra la pelle e la temperatura interna aggiungendo livelli di isolamento.
Ripetere i passaggi da 1 a 4 fino a quando non è stato soddisfatto.
Compilare l'hardware e valutare.
Versione di valutazione
Per ogni revisione hardware, è necessario eseguire una misurazione della temperatura e della potenza rispetto ai carichi di lavoro rappresentativi per valutare il comportamento termica e la progettazione meccanica deve essere modificata in base alle esigenze.
I passaggi seguenti sono consigliati per eseguire tale valutazione termica:
Definire una matrice di test di misurazione termica:
- La matrice deve coprire la temperatura ambiente normale e massima.
- La matrice deve includere tutti i carichi di lavoro tipici identificati come parte della modellazione termica e per ogni carico di lavoro, i dati devono essere acquisiti per almeno un'ora.
- La matrice deve essere eseguita in più PC più volte per generare risultati coerenti.
Per ogni carico di lavoro definito nella matrice di test, acquisire i dati seguenti:
- Dati relativi al consumo di energia del sistema e del componente.
- Dati sulla temperatura dell'ambiente, dei componenti interni e della pelle.
- Tracce software per rilevare la limitazione termica, le metriche delle prestazioni e l'utilizzo del processore.
I dati sulla temperatura della pelle e dei componenti indicano direttamente la temperatura massima della pelle che il sistema potrebbe raggiungere e se questa temperatura è accettabile. Prendere in considerazione la quantità di headroom termica che il sistema potrebbe avere prima dell'arresto critico. I dati delle metriche delle prestazioni consentono di determinare se il sistema offre le prestazioni necessarie. I dati di traccia registrati dal software di limitazione termica mostrano la percentuale di limitazione termica. I dati sull'utilizzo di energia e i dati sull'utilizzo della CPU possono aiutare a determinare quali fattori influiscono sulle variazioni della temperatura.
La tabella seguente fornisce un esempio di tale raccolta dati per un PC con la configurazione seguente:
Configuration
- Nome macchina: Thermal-Test-1
- Temperatura ambiente media: 23oC
- Punto di viaggio della zona termica (_PSV): 80oC
| Category | Subcategory | Video in streaming | Giochi casuali | Fishbowl | Gioco 3D | TDP |
|---|---|---|---|---|---|---|
| Configurazione del carico di lavoro | Streaming video A schermo intero 720p H.264 tramite Wi-Fi | Nome del gioco Uso della CPU |
IE classico con 100 pesci | Nome del gioco Uso della CPU |
CPU e GPU 100% | |
| Consumo di energia elettrica | Alimentazione del sistema | |||||
| Potenza soC | ||||||
| Potenza di visualizzazione | ||||||
| Alimentazione di backlight | ||||||
| Temperatura | Temperatura massima soC | |||||
| Temperatura massima della pelle | ||||||
| Metriche delle prestazioni | Frequenza media dei fotogrammi | Frequenza media dei fotogrammi | Frequenza media dei fotogrammi | Frequenza media dei fotogrammi |
Framework di gestione termica windows
Il framework di gestione termica di Windows offre una soluzione completa per la gestione termica software. Gli esempi seguenti illustrano come implementare la gestione termica. Con la corretta modellazione termica, la convalida e la progettazione meccanica termica efficace, tutti i sistemi devono essere in grado di offrire un'esperienza utente uniforme sulla maggior parte dei carichi di lavoro sulle temperature di ambiente più mirate. Se è necessaria la mitigazione termica, Windows offre un'architettura di gestione termica efficace ed estendibile.
La gestione termica di Windows supporta sia il raffreddamento attivo che passivo. Con il raffreddamento attivo, i fan si attivano per circolare l'aria e aiutano a raffreddare il sistema. Con il raffreddamento passivo, i dispositivi riducono le prestazioni del dispositivo in risposta a condizioni termiche eccessive. Ridurre le prestazioni riduce il consumo di energia e quindi genera meno calore.
Il framework di gestione termica di Windows si basa sui criteri specificati dai progettisti di sistema per applicare la gestione termica nel sistema. A livello generale, i progettisti devono specificare il modo in cui la lettura ottenuta da ogni sensore termica è influenzata da ogni componente. Senza queste specifiche, Windows non può gestire in modo termica il sistema. È quindi responsabilità di ogni progettista di sistema caratterizzare il proprio sistema termicamente per ottenere un buon design termica.
Anche se i sistemi non sono necessari per usare il framework di gestione termica di Windows, è la soluzione consigliata a causa della sua stretta integrazione con il sistema operativo. Tuttavia, indipendentemente dalla soluzione di gestione termica usata, tutti i PC standby moderni devono rispettare i requisiti HCK per scopi diagnostici.
Architettura di gestione termica
L'architettura di gestione termica di Windows si basa sul concetto ACPI di zone termiche. Il modello di zona termica ACPI richiede la cooperazione tra il firmware, il sistema operativo e i driver. Questo modello astrae i sensori e i dispositivi di raffreddamento dal componente di gestione termica centrale tramite interfacce ben definite. I miglioramenti della gestione termica si basano sul capitolo 11 della specifica ACPI 5.0. Il framework di gestione termica di Windows implementa un subset delle funzionalità descritte in questo capitolo.
I componenti essenziali del modello sono:
- Definizioni della zona termica della piattaforma descritte in Windows tramite il firmware. Una zona termica è un'entità astratta che ha un valore di temperatura associato. Il sistema operativo monitora questa temperatura in modo che possa applicare la mitigazione termica ai dispositivi all'interno della zona. La zona contiene un set di dispositivi funzionali che generano calore e un subset di dispositivi la cui generazione di calore può essere controllata modificando le prestazioni.
- Sensore di temperatura che rappresenta la temperatura dell'area. Il sensore deve implementare l'interfaccia Read Temperature per recuperare la temperatura di una zona dal firmware o da un driver di temperatura di Windows.
- Un'interfaccia di raffreddamento termica per abilitare i driver per i dispositivi all'interno delle zone termiche per implementare azioni di raffreddamento passivo. Ogni driver gestito deve avere l'interfaccia di raffreddamento per partecipare all'infrastruttura termica Windows.
- Gestione termica centralizzata che orchestra il raffreddamento interpretando le definizioni della zona termica e richiamando le interfacce nei tempi necessari. Il gestore termica viene implementato nel kernel di Windows e non richiede alcun lavoro dai progettisti di sistema.
Il diagramma a blocchi seguente è una panoramica dell'architettura di gestione termica di Windows. I componenti principali sono la gestione termica, la zona termica, i driver gestiti e il sensore di temperatura. La zona termica determina il comportamento di limitazione dei propri dispositivi gestiti in base ai vincoli forniti dal gestore termica. L'algoritmo usato dalla gestione termica usa la lettura della temperatura del sensore per la zona termica come parametro di input.
Le zone termiche nel sistema devono essere descritte nel firmware ACPI ed esposte alla gestione termica tramite ACPI. Con le informazioni di configurazione, il gestore termica sa quanti zone termiche devono essere gestite, quando avviare la limitazione di ogni zona termica e quali dispositivi fanno parte della zona. Per monitorare la temperatura, la finestra di progettazione del sistema fornisce supporto nel firmware ACPI per le notifiche termiche.
Quando il gestore termica riceve una notifica di un evento termica in una zona enumerata, inizierà periodicamente a valutare la temperatura della zona e determinare la percentuale di prestazioni di limitazione termica da applicare ai dispositivi nella zona termica. Questa valutazione viene eseguita dall'algoritmo di limitazione termica descritto nella specifica ACPI. Il gestore termica notifica quindi a tutti i dispositivi nella zona di limitare le prestazioni in base a una percentuale specifica e i driver di dispositivo traducono la percentuale di limitazione in un'azione specifica della classe di dispositivo per ridurre le prestazioni. La valutazione periodica e la limitazione si arresteranno quando la temperatura della zona termica scende al di sotto della temperatura della soglia di limitazione e non è necessaria alcuna limitazione.
Retroazione
Un altro modo per pensare all'architettura di gestione termica è in termini di input, direttore dei criteri e dispositivi gestiti. Nel diagramma a blocchi seguente, gli input al ciclo di feedback sono la temperatura e l'corrente elettrica. Questi input vengono usati per determinare la politica termica da implementare. Il gestore termica si basa esclusivamente sull'input della temperatura e il driver dei criteri può usare qualsiasi input desideri. La zona termica applica quindi tale criterio ai driver gestiti. Dopo l'applicazione dei criteri, i sensori aggiorneranno i valori e chiuderanno il ciclo.
Il diagramma a blocchi seguente illustra le tre fasi del modello di risposta termica. Gli input dai sensori di temperatura e corrente elettrica forniscono informazioni utili per determinare i criteri termica da applicare. Questo criterio viene applicato ai driver gestiti, che influiscono quindi sulle letture sui sensori. Il processo viene ripetuto in un ciclo di feedback.
Responsabilità degli implementatori del sistema
Come accennato in precedenza, è necessario disporre di una soluzione termica Windows completa. L'architettura del framework termico è progettata specificamente in modo che le responsabilità del fornitore di hardware e dell'integratore di sistemi possano essere separate.
I componenti necessari per i partner da implementare sono:
Sensori
I driver dei sensori di temperatura devono essere forniti dal fornitore dell'hardware. Dato che i sensori di temperatura non necessitano di conoscenza delle zone termiche che si basano su di essi, le loro funzionalità devono essere standard in diverse progettazioni della piattaforma. I sensori personalizzati per i driver dei criteri, ad esempio i sensori correnti, sono anche responsabilità del fornitore dell'hardware.
Zone termiche
Le zone termiche possono essere definite dal fornitore dell'hardware e/o dall'integratore di sistemi. Tutti i sistemi devono avere almeno una zona termica che implementa una temperatura di arresto critico (e temperatura di ibernazione, se supportata), che può essere eseguita dal fornitore dell'hardware o dall'integratore di sistemi. Tuttavia, per altre zone termiche che monitorano dispositivi specifici o la temperatura della pelle per la mitigazione, è comune che l'integratore di sistemi abbia una conoscenza più specifica del comportamento termico del sistema. Di conseguenza, queste zone termiche vengono in genere implementate dall'integratore di sistemi.
Interfaccia di raffreddamento termico per i driver di dispositivo
Lo sviluppatore che scrive il driver per il dispositivo che deve essere gestito termicamente deve essere anche quello per implementare l'interfaccia di raffreddamento. Il driver di dispositivo usa questa interfaccia per acconsentire esplicitamente al framework di gestione termica. I driver di dispositivo hanno una conoscenza specifica delle funzionalità dei propri dispositivi. Questi stessi driver devono implementare l'interfaccia di raffreddamento termico in modo che possa interpretare correttamente le azioni richieste dalla zona termica.
Sensori
I sensori forniscono input per determinare quale criterio termico deve essere. Windows supporta solo i sensori di temperatura come input per il gestore termico. Tuttavia, un driver di criteri può anche accettare input da driver personalizzati, ad esempio un driver del sensore corrente.
Sensore temperatura
Il sensore temperatura fornisce le modalità di funzionalità seguenti:
- Monitora continuamente le variazioni di temperatura senza il coinvolgimento del gestore termico o della zona termica.
- Notifica al gestore termico quando la temperatura supera la soglia definita da _PSV, _HOT o _CRT.
- Risponde alle query sulla temperatura e restituisce il valore della temperatura corrente.
Il diagramma seguente illustra come funziona il monitoraggio della temperatura durante la limitazione. Il firmware ACPI o il driver del sensore temperatura devono notificare al gestore termico quando la temperatura raggiunge una soglia predefinita, ad esempio _PSV, _HOT o _CRT, e quindi rispondere alle query periodiche dal gestore termico per la temperatura corrente. Il periodo della query sulla temperatura viene definito da _TSP.
Per assicurarsi che il gestore termico riceverà sempre una notifica quando la temperatura supera la soglia, l'interruzione del sensore di temperatura deve essere sempre attiva (anche quando il sistema è in standby moderno e il SoC è in uno stato a basso consumo). Se l'interruzione del sensore di temperatura non è sempre attiva, almeno l'interrupt deve essere configurato come attivato dal livello per evitare potenziali perdite di interruzioni.
Un sensore termico può essere usato da più zone termiche, anche se non può essere presente più di un sensore termico in una zona termica.
È consigliabile che l'hardware del sensore sia accurato su +/- 2oC.
La temperatura segnalata da _TMP o da un driver del sensore di temperatura può essere il valore effettivo di un sensore o un valore estrapolato in base a diversi sensori.
Questo viene in genere fornito dal fornitore dell'hardware. Windows supporta due implementazioni per il monitoraggio della temperatura:
- Driver sensore temperatura
- Basato su ACPI
Implementazione 1: Driver sensore temperatura
Il driver del sensore di temperatura segnala semplicemente la temperatura del sensore. Il driver ACPI emetterà un IOCTL in sospeso con il driver del sensore per rilevare un attraversamento di uno dei punti di viaggio. Inoltre, ACPI può emettere un IOCTL senza timeout per leggere la temperatura corrente. Il driver del sensore deve gestire l'annullamento dell'IOCTL di lettura, se viene annullato durante l'attesa della scadenza del timeout. Il sensore temperatura deve implementare l'interfaccia seguente:
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)
Nella tabella seguente vengono descritti i parametri di input e output per l'interfaccia di lettura della temperatura.
| Parametro | Descrizione |
|---|---|
| Timeout | Tempo di attesa prima della restituzione dei dati relativi alla temperatura, espresso in millisecondi. 0 indica che la temperatura deve essere letta immediatamente, senza attendere. -1 indica che la lettura non deve scadere. |
| LowTemperature | Soglia inferiore per la restituzione della nuova temperatura. Non appena la temperatura scende al di sotto della soglia di bassa temperatura, il driver deve completare l'IOCTL. Se la temperatura è già al di sotto della temperatura bassa, l'IOCTL deve essere completato immediatamente. |
| HighTemperature | Soglia superiore per la restituzione della nuova temperatura. Non appena la temperatura aumenta al di sopra della soglia di temperatura elevata, il driver deve completare l'IOCTL. Se la temperatura è già superiore alla temperatura elevata, l'IOCTL deve essere completato immediatamente. |
| Valore restituito IOCTL | Buffer di output di dimensioni ULONG che restituirà la temperatura corrente, in decimi di gradi Kelvin. |
Un sensore di temperatura può essere usato da una zona termica o da più zone termiche. Per specificare quale sensore di temperatura deve essere usato per una zona termica, il _DSM termico deve essere specificato nella zona termica e deve implementare la funzione 2. (Per compatibilità con le versioni precedenti, il driver del sensore temperatura può essere caricato sopra lo stack di zone termiche. Tuttavia, l'implementazione preferita consiste nel fare in modo che il driver del sensore sia separato dallo stack di zone termiche. Questo _DSM viene definito come segue:
ArgomentiArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revisione = 0 Arg2: Funzione = 2 Arg3: Un pacchetto vuoto Restituisce un singolo riferimento al dispositivo che restituirà la temperatura della zona termica.
La zona termica deve anche specificare una dipendenza dal dispositivo sensore temperatura con _DEP. Ecco un semplice esempio per _DSM'implementazione di un dispositivo sensore.
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.
}
Per altre informazioni, vedere Metodo specifico del dispositivo per le estensioni termiche Microsoft.
Implementazione 2: basata su ACPI
Il firmware ACPI deve supportare _TMP e notify 0x80, come definito nella specifica ACPI. Il vantaggio di questo approccio è che non richiede l'installazione di driver aggiuntivi nel sistema. Tuttavia, questo approccio è limitato all'interazione con le risorse accessibili tramite aree operative ACPI.
Controllo dei criteri termico
Zona termica
Una zona termica è una singola entità di limitazione termica. Ha le proprie caratteristiche di limitazione termica, ad esempio punti di corsa, frequenza di campionamento di limitazione e costanti equazioni di limitazione. Una zona termica può includere più dispositivi di limitazione termica, ognuno dei quali può contribuire all'aumento della temperatura nella zona termica. Tutti i dispositivi nella stessa zona termica devono seguire gli stessi vincoli applicati alla zona termica.
Per assicurarsi che le zone termiche e i relativi parametri siano definiti in modo accurato, i progettisti di sistema devono:
- Identificare i punti caldi nello chassis del sistema e determinare in che modo questi punti caldi dissiparono il calore ai sensori di temperatura. (Idealmente, i sensori termico sono seduti nei punti caldi del sistema, ad eccezione dei sensori di temperatura della pelle.
- Caratterizzare la relazione di temperatura del sistema. Eseguire il mapping delle letture del sensore temperatura alla temperatura del componente e alla temperatura della pelle.
Soglia di overthrottle
A partire da Windows 10, una nuova funzionalità denominata stato termico, è stata introdotta nella gestione termica di Windows, insieme a uno stato: overthrottled. Quando una zona termica supera il livello di limitazione progettato del dispositivo, il gestore termico informerà i componenti del sistema operativo che il sistema è sovrasagliato. Questa notifica consente al sistema di ridurre il carico di lavoro per migliorare lo stato termico.
Il gestore termico mantiene un conteggio globale del numero di zone termiche che si trovano nello stato overthrottled. Quando il conteggio aumenta al di sopra di zero (0), il gestore termico invia una notifica di Windows Notification Facility (WNF) al sistema, a indicare che è eccessiva. Quando il numero di zone con overthrottled torna a zero (0), il gestore termico invia un'altra notifica WNF al sistema, a indicare che non ci sono zone overthrottled.
Per specificare la soglia di overthrottle per una zona termica, il _DSM termico deve essere specificato nella zona termica, con la funzione 3 implementata. Questo _DSM viene definito come segue:
ArgomentiArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 3 Arg3: An empty package Return An Integer value with the current overthrottle threshold, espresso come percentuale.
Di seguito è riportato un esempio di _DSM che indica che la zona è eccessivamente insodetta, a livelli di limitazione da 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
La soglia di overthrottle verrà rilette quando viene ricevuta una notifica (0x81) in riferimento alla zona termica.
Implementazione di oggetti ACPI
Nella tabella seguente sono elencati tutti gli oggetti ACPI che devono essere implementati nel firmware ACPI per definire una zona termica.
| Category | Metodo control |
|---|---|
| Identificare i dispositivi contenuti nella zona |
|
| Specificare le soglie termiche in corrispondenza delle quali devono essere eseguite le azioni |
|
| Descrivere il comportamento di raffreddamento passivo |
|
| Descrivere il comportamento di raffreddamento attivo |
|
| Impostare i criteri di raffreddamento attivi/passivi |
|
| Limite minimo di limitazione |
|
| Segnalare la temperatura |
|
| Inviare una notifica al gestore termico |
|
| Specificare il dispositivo sensore temperatura |
|
Limite minimo di limitazione
Il limite minimo di limitazione è un metodo di estensione termica Microsoft _DSM che crea un limite inferiore per _PSV richiesto di un dispositivo limitato. In altre parole, determina la quantità di zona termica che limita le prestazioni dei dispositivi che controlla. Se presente, la limitazione minima _DSM verrà letta all'avvio e ogni volta che la zona termica riceve ACPI Notify (0x81). A ogni iterazione dell'algoritmo di raffreddamento passivo, viene usato quanto segue per calcolare la modifica del limite di prestazioni (DP) applicato ai dispositivi nella zona:
DP [%] = _TC1 × (Tn – Tn₋₁) + _TC2 × (Tn – Tt) Viene quindi usato il codice seguente per calcolare il limite effettivo delle prestazioni:
Pn = Pn₋₁ - DP Con il limite minimo di limitazione (MTL) implementato, questa seconda equazione cambia in:
Pn = max(Pn₋₁ – DP, MTL) Per specificare il limite minimo di limitazione per una zona termica, il _DSM termico deve essere specificato nella zona termica, con la funzione 1 implementata. Questo _DSM viene definito come segue:
ArgomentiArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 1 Arg3: An empty package Return An Integer value with the current minimum throttle limit, espresso come percentuale.
Ecco un esempio semplice per _DSM limitazione della limitazione non inferiore 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)
}
}
}
}
}
Gestione termica nel kernel
Il gestore termico Di Windows viene implementato come parte del kernel di Windows. Monitora la temperatura di tutte le zone termiche e applica la limitazione termica in base alle esigenze.
Ogni volta che il gestore termico esegue una query sul driver ACPI per la temperatura corrente, eseguirà un calcolo sulla percentuale di prestazioni di limitazione termica da applicare a tutti i dispositivi di limitazione termica nella zona termica. Il limite termico viene valutato e applicato quando viene superata la soglia di raffreddamento passivo (_PSV) e a ogni intervallo di campionamento della temperatura (_TSP) fino a quando la temperatura non viene raffreddata al di sotto di essa e il limite termico torna al 100%. L'hardware deve rilevare quando il _PSV è stato superato e deve segnalare che tramite una notifica degli eventi ACPI hardware.
Algoritmo di limitazione termica
L'algoritmo di limitazione termica utilizza l'equazione seguente, definita nella specifica ACPI:
DP [%] = _TC1 × ( Tn – Tn₋₁ ) + _TC2 × (Tn – Tt) dove
Tn = lettura della temperatura corrente del sensore di temperatura nella zona termica in decimi di gradi Kelvin. Tn₋₁ = temperatura della lettura precedente. Tt = temperatura di destinazione in decimi di gradi Kelvin (_PSV). DP = modifica delle prestazioni richiesta. Si tratta di un valore lineare compreso tra 0 (completamente limitato) e il 100% (insoddisabile), che deve essere applicato a ogni dispositivo di raffreddamento nella zona. Questa equazione descrive il ciclo di feedback tra le variazioni di temperatura e le prestazioni di limitazione. In ogni iterazione del ciclo, il delta della temperatura tra le letture della temperatura corrente e quella precedente richiede che le prestazioni P diminuisca per percentuale dp. Il valore DP è la quantità di limitazione termica da applicare. Molti dispositivi di raffreddamento non hanno una risposta termica lineare alle mitigazioni del raffreddamento. In questi dispositivi, il limite termico è un suggerimento per il dispositivo per indicare la quantità di raffreddamento necessaria. Ogni dispositivo di raffreddamento avrà il proprio mapping di questo valore lineare alle mitigazioni termiche specifiche del dispositivo. La limitazione delle prestazioni del dispositivo riduce il consumo di energia e la generazione di calore, che causa la diminuzione della temperatura.
Le due costanti, _TC1 e _TC2, controllano la modalità di applicazione della limitazione termica aggressiva in questo ciclo di feedback. La _TC1 più grande è, la limitazione termica più aggressiva viene usata per mantenere una temperatura stabile. La _TC2 più grande è, la limitazione termica più aggressiva viene usata per spingere la temperatura vicino al punto di viaggio.
La tabella seguente fornisce un esempio di come il gestore termica calcola e applica il DP. In questo esempio vengono usati i valori dei parametri seguenti:
Configuration
- _PSV = 325oK
- _TC1 = 2
- _TC2 = 3
- _TSP = 5000 millisecondi
- Si supponga che la temperatura aumenti continuamente di 1 grado ogni 5 secondi.
La colonna più a destra nella tabella seguente (etichettata P) indica il livello di prestazioni limitato che comporta l'applicazione dei vincoli specificati da questi parametri.
| Iterazione | Ora | Tn | Punto di distribuzione (DP) | P |
|---|---|---|---|---|
| 1 | 0 secondi | 326oK | = 2 × 1 + 3 × 1 = 5% | 95% |
| 2 | 5 secondi | 327oK | = 2 × 1 + 3 × 2 = 8% | 87% |
| 3 | 10 secondi | 328oK | = 2 × 1 + 3 × 3 = 11% | 76% |
| 4 | 5 secondi | 320oK | = 2 × 1 + 3 × 4 = 14% | 62% |
| 5 | 20 secondi | 330oK | = 2 × 1 + 3 × 5 = 17% | 45% |
| ... |
Driver dei criteri
Per impostazione predefinita, l'algoritmo usato per determinare la percentuale di limitazione come dettata dalle specifiche ACPI viene usata per tutte le zone termiche. Come descritto in precedenza, questo algoritmo è basato esclusivamente sul sensore di temperatura collegato alla zona termica, che può essere limitato.
Se si preferisce un algoritmo diverso, la finestra di progettazione del sistema può implementare un driver di criteri per rappresentare l'algoritmo preferito. Un driver di criteri si trova sopra lo stack di zone termiche per la zona che controlla. Per questa zona, l'algoritmo del driver dei criteri può essere usato al posto dell'algoritmo ACPI nel gestore termica. L'algoritmo del driver di criteri ha la possibilità di considerare qualsiasi informazione a cui può accedere come input. Le decisioni politiche prese dal conducente vengono passate al gestore termica, che registra le informazioni e lo passa alla zona termica per eseguire.
L'uso di un driver di criteri per una zona termica significa che il driver dei criteri, non ACPI e non il sistema operativo, è responsabile solo per decidere quando limitare una zona e per quanto tempo.
Se un driver di criteri è presente, tutti i punti di viaggio, tutte le costanti termiche, il limite minimo di limitazione e così via, vengono completamente ignorati. Il sistema operativo non ha informazioni dettagliate sul motivo per cui la zona termica è impostata a livello di limitazione corrente. Alcuni vantaggi sono offerti dall'uso di un driver di criteri anziché da una soluzione di proprietà. Un driver di criteri sfrutta il processo predefinito di limitazione dei dispositivi. Qualsiasi operazione che una zona termica possa fare per fornire una mitigazione termica può essere eseguita da un driver di criteri. Inoltre, la diagnostica per la gestione termica di Windows viene ereditata automaticamente.
L'interfaccia dei criteri termica è stata aggiornata per includere un nuovo parametro per indicare se la zona è sovrathrottled. Questo parametro viene inizializzato in FALSE. I driver di criteri precedenti non saranno consapevoli del nuovo parametro e i nuovi driver sapranno che il nuovo parametro è supportato, quando rilevano una versione dei criteri di '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;
Il driver di criteri può indicare che la zona termica è sovrathrottled, completando il criterio IOCTL con il parametro OverThrottled impostato su TRUE. Quando le condizioni termiche migliorano, il driver di criteri termica può quindi completare l'IOCTL con OverThrottled reimpostato su FALSE, per indicare che la zona termica è stata ripristinata. Windows non richiederà che il driver dei criteri venga limitato quando viene impostato il flag overthrottle.
Dispositivi gestiti in modo termica
Le zone termiche controllano il comportamento termica dei dispositivi gestiti tramite i driver in modalità kernel. Un dispositivo di limitazione termica potrebbe risiedere in più zone termiche. Quando più zone termiche richiede percentuali di prestazioni di limitazione termica diverse, la gestione termica sceglie la percentuale minima di prestazioni di limitazione termica da applicare al dispositivo di limitazione termica.
Molti dispositivi di raffreddamento non hanno una risposta termica lineare alle mitigazioni del raffreddamento. In questi casi, il limite di calore è un suggerimento per il dispositivo del grado di raffreddamento richiesto. Ogni dispositivo di raffreddamento avrà il proprio mapping di questo valore lineare alle sue mitigazioni termiche specifiche.
Quando ogni driver di dispositivo viene caricato, ACPI eseguirà una query per l'interfaccia di raffreddamento termica e registrare ogni dispositivo di risposta come dispositivo di raffreddamento. Successivamente, quando il raffreddamento passivo è in fase di elaborazione e il limite termica per una zona è cambiato, ACPI chiamerà questa interfaccia su ogni dispositivo di raffreddamento nella zona. Il dispositivo di raffreddamento eseguirà quindi il mapping del limite termica fornito alle caratteristiche di raffreddamento specifiche e implementerà le mitigazioni appropriate per il raffreddamento. Si noti che se il dispositivo di raffreddamento viene visualizzato in più zone termiche, il limite termica che limita il dispositivo al massimo (ovvero la percentuale più bassa) viene passata al dispositivo.
Nota Windows offre implementazioni predefinite della limitazione termica per processori, backlight e batteria del metodo di controllo ACPI.
Interfaccia di raffreddamento termica
Windows fornisce i punti di estensione per i driver di dispositivo da registrare come dispositivi di limitazione termica e per ricevere la richiesta percentuale di limitazione termica. Il dispositivo è quindi responsabile della conversione di tale percentuale in un'azione che ha senso per se stessa.
I dispositivi che vogliono essere aggiunti come dispositivo di limitazione termica devono innanzitutto aggiungere il _HIDs nell'elenco dei dispositivi termica della zona termica e quindi implementare il set di interfacce seguente. Quando ogni driver di dispositivo viene caricato, ACPI eseguirà una query per questa interfaccia e registrerà ogni dispositivo di risposta come dispositivo di raffreddamento. Successivamente, quando il raffreddamento passivo è in fase di elaborazione e il limite termica per una zona è cambiato, ACPI chiamerà questa interfaccia su ogni dispositivo di raffreddamento nella zona. Il dispositivo di raffreddamento eseguirà quindi il mapping del limite termica fornito alle caratteristiche di raffreddamento specifiche e implementerà le mitigazioni appropriate per il raffreddamento. Si noti che se il dispositivo di raffreddamento viene visualizzato in più zone termiche, il limite termica che limita il dispositivo al massimo (ovvero la percentuale più bassa) viene passata 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
Processore
Per un processore, il gestore termica comunica la percentuale di limitazione termica al processore power manager (PPM). La limitazione termica dei processori è una funzionalità predefinita di Windows.
Aggregator del processore
Il dispositivo aggregator del processore consente il parcheggio principale come mitigazione termica. Le zone possono specificare il parcheggio principale come mitigazione termica se il dispositivo aggregatore del processore è un membro di una zona termica. I processori non devono essere limitati per il parcheggio principale da eseguire. Questa implementazione funziona in parallelo con l'idling del processore logico (LPI). Si noti che questo è ancora soggetto alle caveat del parcheggio principale. In particolare, qualsiasi lavoro affinizzato a un core parcheggiato causerà l'esecuzione del core.
Device(\_SB.PAGR) {
Name(_HID, "ACPI000C")
}
ThermalZone(\_TZ.TZ01) {
Name(_TZD, Package() {"\_SB.PAGR"})
// Other thermal methods: _PSV, etc.
}
Grafica
Affinché un driver miniport grafico di terze parti venga gestito in modo termica, deve interagire con il driver della porta grafica Windows, Dxgkrnl.sys. Dxgkrnl.sys ha l'interfaccia di raffreddamento termica e passa qualsiasi richiesta di limitazione verso il basso dello stack al driver miniport. È responsabilità del driver miniport tradurre la richiesta in un'azione specifica per il dispositivo.
Il diagramma a blocchi seguente illustra l'architettura della zona termica che controlla la GPU.
Retroilluminazione
La riduzione del backlight può migliorare notevolmente le condizioni termiche su una piattaforma mobile. Windows consiglia che durante il funzionamento, la luminosità dello schermo del sistema non è mai limitata termicamente a meno di 100 nit.
Per il controllo della luce posteriore, il gestore termico comunica la percentuale di limitazione termica al driver di monitoraggio, Monitor.sys. Monitor.sys deciderà l'impostazione effettiva del livello di backlight in base a questo input termico e ad altri input in Windows. Quindi Monitor.sys applicherà l'impostazione del livello di backlight tramite ACPI o il driver di visualizzazione.
Si noti che se la temperatura della zona termica che include il backlight continua ad aumentare, la percentuale di limitazione termica richiesta potrebbe infine scendere a zero%. L'implementazione del livello di backlight in ACPI o driver di visualizzazione deve garantire che il livello di luminosità minimo disponibile per i controlli delle prestazioni sia ancora visibile per gli utenti finali.
Nota Mentre funziona, la luminosità dello schermo del sistema non è mai limitata termicamente a meno di 100 nit.
Batteria
Un'altra fonte di calore principale nel sistema è la ricarica della batteria. Dal punto di vista di un utente, la ricarica deve essere ridotta e anche completamente interrotta in condizioni termiche vincolate. Tuttavia, la ricarica della batteria non deve essere ostacolata nei casi d'uso normali.
Nota Si consiglia di non limitare la ricarica della batteria mentre il sistema è inattiva (1) e nell'intervallo di temperatura ambientale inferiore a 35oC o (2) in qualsiasi condizione mentre la temperatura ambientale è inferiore a 25oC.
Il driver miniclasse Della batteria del metodo di controllo Di Windows, Cmbatt.sys, usa direttamente l'interfaccia di raffreddamento termico, come descritto in precedenza. Il firmware è responsabile dell'assunzione del limite termico corrente quando si attiva la ricarica. È necessario un nuovo metodo di controllo ACPI per impostare il limite termico per la ricarica. Questo metodo viene implementato come metodo specifico del dispositivo (_DSM), come definito nella specifica ACPI 5.0, sezione 9.14.1.
Per applicare la percentuale di limitazione termica, Cmbatt.sys valuterà il metodo di controllo Device Specific Method (_DSM) per richiedere al firmware ACPI di impostare il limite termico per la ricarica. All'interno del metodo di controllo _DSM, viene definito un GUID per indicare il limite termico.
| Arg # | Valore | Descrizione |
|---|---|---|
| Arg0 | 4c2067e3-887d-475c-9720-4af1d3ed602e | UUID |
| Arg1 | 0 | Revisione |
| Arg2 | 1 | Funzione |
| Arg3 | Valore intero compreso tra 0 e 100 | Limite termico per la ricarica della batteria. Equivalente alla limitazione passiva percentuale calcolata. |
| Valore restituito | N/D | Nessun valore restituito |
Raffreddamento attivo
Dal punto di vista del sistema operativo, una piattaforma ha due strategie che può usare per implementare il controllo ventola:
Implementare una o più zone termiche ACPI con punti di viaggio attivi per coinvolgere/sganciare la ventola.
Il framework termico Windows supporta i dispositivi di raffreddamento attivi a un livello molto semplice. L'unico dispositivo supportato nella posta in arrivo è una ventola ACPI e può essere controllata solo con segnale attivato/spento.
Implementare una soluzione proprietaria per controllare la ventola (tramite driver, controller incorporato e così via).
Anche se Windows non controlla il comportamento delle soluzioni proprietarie per gli appassionati, Windows supporta le notifiche dei fan al gestore termico per tutte le implementazioni, inclusi i controller incorporati, in modo che sia possibile raccogliere informazioni di diagnostica e dati di telemetria. Pertanto, l'esposizione della ventola al sistema operativo è necessaria per tutti i PC di standby moderni e fortemente consigliata per tutti gli altri.
Si noti che l'implementazione per il raffreddamento attivo è completamente separata dalle mitigazioni del raffreddamento passivo descritte in precedenza.
Controllo ventola da zona termica ACPI
Windows supporta la definizione di ventola basata sullo stato ACPI 1.0 D. Per altre informazioni, vedere la specifica ACPI. Pertanto, il controllo è limitato alla ventola acceso e spento. Il driver per la ventola viene fornito nel driver ACPI di Windows, Acpi.sys.
- Il sensore di temperatura legge la temperatura ha superato un punto di corsa e genera una notifica (0x80) sulla zona termica associata.
- La zona termica legge la temperatura con il metodo di controllo _TMP e confronta la temperatura con i punti di corsa attivi (_ACx) per decidere se il ventilatore deve essere acceso o spento.
- Il sistema operativo inserisce il dispositivo ventola in D0 o D3, che causa l'accensione o la disattivazione della ventola.
Il diagramma a blocchi seguente mostra il flusso di controllo per una ventola controllata da una zona termica 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})
}
}
Ventola a più velocità in ACPI
Per ottenere più velocità per una ventola che usa ACPI 1.0, sono disponibili due opzioni:
- La zona termica può contenere più "fan", quando esiste una sola ventola fisica. Avere più "fan" in una sola volta si traduce in velocità della ventola più veloce. Per altre informazioni, vedere l'esempio di questa opzione nella sezione 11.7.2 nella specifica ACPI 5.0.
- Quando il ventilatore è acceso, può decidere per se stesso quanto velocemente girare. I sistemi con controller incorporati, ad esempio, possono scegliere questa opzione.
Soluzione proprietaria per i fan
Windows deve essere in grado di rilevare l'attività fan con entrambe le implementazioni. Quando una piattaforma usa il modello termico ACPI, Windows è responsabile dell'attivazione e della disattivazione della ventola e quindi sa già quando è attiva. Quando viene usata una soluzione proprietaria per controllare la ventola, Windows deve notificare che la ventola è in esecuzione. Per abilitare questa operazione, Windows supporterà un subset parziale delle estensioni della ventola ACPI 4.0, elencate nella tabella seguente.
| Funzionalità | Descrizione | Supportato |
|---|---|---|
| _FST | Restituisce lo stato della ventola. | sì |
| Notify(0x80) | Indica che lo stato della ventola è cambiato. | sì |
| _FIF | Restituisce informazioni sul dispositivo ventola. | no |
| _FPS | Restituisce un elenco di stati delle prestazioni della ventola. | no |
| _FSL | Imposta lo stato delle prestazioni della ventola (velocità). | no |
Windows userà l'oggetto _FST per determinare se la ventola è in esecuzione (il campo di controllo è diverso da zero) o disattivato (il campo di controllo è zero). Windows supporterà anche Notify(0x80) nel dispositivo ventola come indicazione che _FST è stato modificato e deve essere rivalutato.
Una ventola che implementa l'oggetto _FST non deve trovarsi nell'elenco di dispositivi _ALx di una zona termica, ma può, come opzione, essere in questo elenco. Questa opzione abilita una soluzione ibrida in cui una ventola è in genere controllata da un driver di terze parti, ma può essere controllata dalla zona termica del sistema operativo se il driver di terze parti non è installato. Se una ventola si trova in un elenco di dispositivi di _ALx ed è impegnata dalla zona termica (posizionata in D0), l'oggetto _FST è necessario per indicare un valore di controllo diverso da zero.
Per tutti gli appassionati, Windows userà l'algoritmo seguente per determinare lo stato della ventola:
- Se un ventilatore è in D0 (a causa del _ACx punto di corsa di una zona termica che viene attraversato), viene impegnato.
- Se una ventola è in D3 e non supporta le estensioni ACPI 4.0, viene disattivata.
- Se una ventola è in D3 e supporta le estensioni ACPI 4.0, il sistema operativo verificherà _FST campo Di controllo per un valore diverso da zero per verificare se la ventola è attivata.
Esempio 1: Controllo ventola hardware
In questo esempio, una ventola è controllata da un controller incorporato.
- Il controller incorporato decide di avviare o arrestare la ventola in base al proprio algoritmo interno.
- Dopo l'avvio o l'arresto della ventola, il controller incorporato emette una notifica (0x80) nel dispositivo ventola.
- Il sistema operativo valuta _FST e legge il nuovo stato della ventola.
Il diagramma a blocchi seguente mostra il flusso di controllo per una ventola controllata da un controller incorporato.
L'esempio ASL seguente definisce un dispositivo "FAN" in grado di notificare al sistema operativo le modifiche nello stato della ventola:
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
}
Esempio 2: Controllo ventola driver
In questo esempio un driver di terze parti controlla la ventola.
- Il driver decide di avviare o arrestare la ventola in base al proprio algoritmo interno.
- Il driver modifica lo stato della ventola e valuta un metodo di controllo personalizzato (SFST) nel dispositivo termico.
- Il metodo di controllo del dispositivo termico aggiorna il contenuto _FST del dispositivo ventola e genera una notifica (0x80) nel dispositivo ventola.
- Il sistema operativo valuta _FST e legge il nuovo stato della ventola.
Il diagramma a blocchi seguente mostra il flusso di controllo per una ventola controllata da un driver di terze parti.
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)
}
}
}
Presenza ventola
Una piattaforma indica che nel sistema è presente una ventola includendo un dispositivo ventola (ID PnP PNP0C0B) nello spazio dei nomi ACPI. Windows assumerà la presenza di questo dispositivo come indicazione che il sistema ha una ventola e l'assenza di questo dispositivo come indicazione che il sistema non ha ventola.
Linee guida specifiche per lo standby moderno
Il framework di gestione termica di Windows fa parte del kernel e viene fornito con tutti i sistemi Windows. Di conseguenza, il materiale precedente si applica a tutte le macchine. Tuttavia, vari tipi di computer richiedono indicazioni aggiuntive più specifiche per modern standby.
Standby moderno porta il modello di alimentazione smart phone al PC. Offre un'esperienza utente immediata e immediata che gli utenti si aspettano sul telefono. E proprio come sul telefono, Modern Standby consente al sistema di rimanere aggiornato, aggiornato e raggiungibile ogni volta che è disponibile una rete appropriata. Windows 10 supporta modern standby su piattaforme a basso consumo che soddisfano requisiti di certificazione Windows specifici.
I PC standby moderni sono dispositivi altamente mobili in un fattore di forma sottile e leggero. Inoltre, i PC moderni standby sono sempre attivati e nello stato ACPI S0. Per offrire un'esperienza cliente affidabile e affidabile, l'intero sistema, dal design meccanico all'implementazione del firmware e del software, deve essere progettato con attenzione critica alle caratteristiche termiche. Pertanto, tutti i PC moderni standby devono rispettare i requisiti termico.
Requisiti moderni di standby
Tutti i PC di standby moderni devono superare i test HCK seguenti:
- Tutti i PC di standby moderni devono avere almeno una zona termica per cui è definita una temperatura di arresto critico (_CRT). Per i sistemi x86, è consigliabile definire una temperatura di ibernazione critica (_HOT) per attivare il salvataggio dei dati utente. _HOT deve essere inferiore a _CRT e _CRT deve essere inferiore al punto di viaggio termico non sicuro del firmware.
- Ogni zona termica deve segnalare la temperatura effettiva del sensore (_TMP). Il test esegue un carico di lavoro variabile nel PC e si prevede che la temperatura cambi.
Inoltre, è consigliabile che ogni PC includa almeno un sensore di temperatura per il SoC.
Requisiti di raffreddamento attivi
I PC di standby moderni che usano i fan devono rispettare i requisiti aggiuntivi seguenti, che vengono testati in HCK:
- La ventola deve essere esposta al sistema operativo. Per altre informazioni, vedere Presenza della ventola.
- Il sistema operativo deve sapere in qualsiasi momento se la ventola è acceso o spento. Anche durante la resilienza inattiva nello standby moderno, tutte le modifiche apportate all'attività fan devono riattivare il SoC per aggiornare lo stato. Per altre informazioni sull'implementazione delle notifiche dei fan, vedere Controllo della ventola da parte della zona termica ACPI.
- La ventola non deve accendere mentre il PC è in standby moderno. Con un carico di lavoro realistico durante lo standby moderno, che è ogni volta che lo schermo è spento, la ventola non deve attivare.
Dal punto di vista dell'utente, il PC sembra essere disattivato quando è in standby moderno. Gli utenti si aspettano che un PC in standby moderno si comporti come se fosse nello stato di sospensione del sistema. Pertanto, gli utenti si aspettano che il fan non venga mai acceso, proprio come nei PC tradizionali durante il sonno. Se il ventilatore viene attivato, gli utenti potrebbero sentirlo e/o sentire l'aria calda circolante e pensare che il computer non funziona correttamente. Pertanto, la ventola non deve essere attivata durante lo standby moderno. Per altre informazioni sul comportamento richiesto, vedere Requisiti di test HCK per PC di standby moderni.
Questi requisiti implicano che i criteri di raffreddamento quando lo schermo è attivato potrebbe dover essere diverso da quando lo schermo è spento. Il PC potrebbe usare il raffreddamento attivo mentre lo schermo è acceso, ma deve basarsi solo sul raffreddamento passivo quando lo schermo è spento. Il punto di viaggio attivo per la ventola potrebbe essere molto inferiore quando lo schermo è acceso rispetto a quando è spento. Per l'implementazione ACPI, è necessario aggiornare _ACx all'ingresso in Standby moderno. Per le soluzioni proprietarie, assicurarsi di aggiornare i criteri nel controller incorporato.
Limitazione del processore
Ppm comunica i livelli massimi, desiderati e minimi di prestazioni al PEP. In condizioni di limitazione termica, il livello di prestazioni massimo deve essere uguale alle prestazioni di limitazione richieste dal gestore termico. Il PEP imposta quindi la tensione fisica e la frequenza della CPU in base ai requisiti del livello di prestazioni di PPM.
Segnale rumore ventola
A partire da Windows 11, i dispositivi possono inviare un segnale di rumore della ventola al sistema operativo per l'uso nelle decisioni di gestione delle risorse, con l'obiettivo di fornire agli utenti un'esperienza interessante e tranquilla. Questa interfaccia di consenso esplicito consente al firmware di inviare informazioni rpm fan al sistema operativo come valore compreso tra 0 (ventola) e Max RPM, che il sistema operativo può usare nelle decisioni di gestione delle risorse per raffreddare il dispositivo in base alle esigenze. Ciò contribuisce a due vantaggi principali:
- Esperienza utente non interattiva: Il rumore della ventola e l'aria calda soffiano sono una fonte significativa di insoddisfazione dei clienti. Ciò è particolarmente vero quando l'utente non prevede un'attività di ventola pesante, ad esempio quando il dispositivo esegue una quantità ridotta di lavoro o nessun lavoro in primo piano.
- Miglioramento della durata della batteria: Una maggiore velocità della ventola comporta un maggiore utilizzo dell'alimentazione, che causa una maggiore scaricamento della batteria mentre è in dc e ricarica più lenta mentre è in ac.
Attualmente, questo segnale può essere usato per gestire le attività dell'indicizzatore di ricerca e sono previsti piani per consentire anche attività in background aggiuntive di utilizzare questo segnale.
Il diagramma seguente riepiloga il modo in cui il segnale di rumore della ventola viene inviato nei livelli dal firmware al software.
Funzionamento del segnale di rumore della ventola
Dettagli dell'interfaccia ACPI
Di seguito sono riportate le quattro funzioni del metodo specifico del dispositivo (_DSM, UUID: A7611840-99FE-41ae-A488-35C75926C8EB) usato per supportare questa funzionalità. Informazioni su _FST (Stato ventola) sono disponibili nella sezione 11.3.1.4 della specifica ACPI e nell'esempio 1: Controllo della ventola hardware dei dispositivi gestiti termicamente
Il diagramma seguente riepiloga il flusso di come vengono usate queste funzioni.
Il diagramma a blocchi seguente mostra il flusso di controllo per una ventola controllata da un controller incorporato, incluso il metodo di controllo Notify(0x80).
Nota
Il segnale di rumore della ventola non controlla l'RPM della ventola, ma notifica al sistema operativo il rumore della ventola che richiede lo spostamento della risorsa CPU dalle attività in background per completare il lavoro con priorità.
Enumerare le funzioni (funzione 0)
Affinché il sistema operativo interagisca con la piattaforma, è necessario esporre un dispositivo ACPI tramite lo spazio dei nomi . Questo dispositivo deve includere un oggetto _CID contenente EISAID("PNP0C0B"). L'ambito del dispositivo deve contenere la definizione di _DSM seguente che indica quale _DSMs il dispositivo supporta.
| UUID | Revisione | Funzione | Descrizione |
|---|---|---|---|
A7611840-99FE-41ae-A488-35C75926C8EB |
0 |
0 |
Enumerare le funzioni |
Ritorno: Per indicare il supporto per le funzioni da 0 a 3 elencate in precedenza, la funzione Enumerate Functions (funzione 0) deve restituire 0xF. Per altre informazioni, vedere la sezione 9.1.1 della specifica ACPI.
Funzione get fan trip point support (funzione 1)
L'hardware indica al sistema operativo cosa è supportato in termini di RPM.
| UUID | Revisione | Funzione | Descrizione |
|---|---|---|---|
A7611840-99FE-41ae-A488-35C75926C8EB |
0 |
1 |
Ottenere il supporto per il punto di viaggio dei fan |
Argomenti
Arg0: UUID: A7611840-99FE-41ae-A488- 35C75926C8EB
Arg1: Revisione: 0
Arg2: Funzione: 1
Arg3: Pacchetto vuoto
Ritorno: Valore intero contenente la granularità supportata per i punti di viaggio fan, in RPMs. Se non zero, il sistema operativo può selezionare i punti di viaggio che sono un multiplo della granularità della notifica. Ad esempio, con una granularità di 200, OSPM può selezionare i punti di viaggio a 0, 200, 400, 600 e così via. Rpm. Un valore pari a 0 indica che i punti di viaggio non sono supportati.
Funzione Set Fan Trip Points (Funzione 2)
Il sistema operativo comunica all'hardware qual è il successivo punto di viaggio di notifica; l'hardware notifica al sistema operativo quando ciò accade.
| UUID | Revisione | Funzione | Descrizione |
|---|---|---|---|
A7611840-99FE-41ae-A488-35C75926C8EB |
0 |
2 |
Ottenere i punti di viaggio dei fan |
Argomenti
Arg0: UUID: A7611840-99FE-41ae-A488-35C75926C8EB
Arg1: Revisione: 0
Arg2: Funzione: 2
Arg3: Pacchetto contenente i punti di viaggio inferiore e superiore. (2 elemento int. Inferiore all'indice 0, Superiore all'indice 1)
OSPM seleziona solo i punti di viaggio che sono un multiplo della granularità del punto di viaggio specificata nella funzione 1. Quando la velocità effettiva della ventola è superiore o inferiore ai punti di viaggio superiore/inferiore, la piattaforma deve emettere Notifica(0x80) sul dispositivo della ventola. OSPM valuterà quindi _FST (stato fan) per determinare la velocità corrente della ventola. Se la velocità della ventola è già al di fuori dei punti di viaggio specificati quando vengono impostati i punti di viaggio, la piattaforma deve inviare immediatamente Notifica(0x80).
Il punto di viaggio superiore sarà un multiplo di granularità. Il punto di viaggio inferiore sarà (più granularità) + 1 (punto di viaggio superiore del punto di viaggio < inferiore). Quando RPM è 0, il sistema operativo imposta un punto di viaggio inferiore su 0 e il punto di viaggio superiore a 1.
Ritorno: Nessuno.
Funzione Get Fan Operating Range (Funzione 3)
Mapping tra RPM -> Impatto. Si noti che solo una ventola (quella più vicina al SoC) può implementare questa interfaccia, deve implementare tutte le 3 funzioni più funzione 0 dalla sezione 9.1.1 della specifica ACPI.
| UUID | Revisione | Funzione | Descrizione |
|---|---|---|---|
A7611840-99FE-41ae-A488-35C75926C8EB |
0 |
3 |
Ottenere gli intervalli operativi della ventola |
Argomenti
Arg0: UUID: A7611840-99FE-41ae-A488-35C75926C8EB
Arg1: Revisione: 0
Arg2: Funzione: 3
Arg3: Pacchetto vuoto.
Ritorno: Pacchetto contenente il formato seguente:
Package () {
Impact1MaxRPM, // Integer (DWORD)
Impact2MaxRPM, // Integer (DWORD)
Impact3MaxRPM, // Integer (DWORD)
MaxRPM // Integer (DWORD)
}
| Campo | Formato | Descrizione |
|---|---|---|
Impact1MaxRPM |
Intero (DWORD) |
Numero massimo di RPM per l'intervallo di impatto della ventola 1. |
Impact2MaxRPM |
Intero (DWORD) |
Numero massimo di RPM per l'intervallo di impatto della ventola 2. Deve essere >= Impact1MaxRPM. |
Impact3MaxRPM |
Intero (DWORD) |
Numero massimo di RPM per l'intervallo di impatto della ventola 3. Deve essere >= Impact2MaxRPM. |
MaxRPM |
Intero (DWORD) |
Numero massimo di RPMS in cui è possibile operare la ventola. Deve essere >= Impact3MaxRPM. |
Questa tabella viene usata per derivare l'intervallo RPM per ogni livello di impatto della ventola:
| Punteggio di impatto | Valore RPM inferiore | Valore RPM superiore |
|---|---|---|
1 |
1 |
Impact1MaxRPM |
2 |
Impact1MaxRPM + 1 |
Impact2MaxRPM. |
3 |
Impact2MaxRPM + 1 |
Impact3MaxRPM |
4 |
Impact3MaxRPM + 1 |
MaxRPM |
Se un intervallo di impatto non viene usato da una piattaforma (ad esempio, se la ventola passa direttamente dall'intervallo di impatto 2 all'intervallo di impatto 4), può indicare questa impostazione impostando l'intervallo di impatto massimo per l'intervallo di impatto inutilizzato uguale al numero massimo di rpm per l'intervallo di impatto inferiore.
Mapping di esempio
| Valore inviato al sistema operativo | Fan RPM | Esperienza dell'utente | Soffitto RPM |
|---|---|---|---|
0 – Basso |
1-4000 RPM (<=25 dBA) |
Fan non su o su con bassa annoia |
Impact1MaxRPM = 4000 |
1 – Medio |
4001-5000 RPM (25-30 dBA) |
Ventola con fastidio medio |
Impact2MaxRPM = 5000 |
2 – Medium-High |
5001-6000 RPM (30-36 dBA) |
Ventola con fastidio medio-alto |
Impact3MaxRPM = 6000 |
3 – Alto |
6001+ RPM (36+ dBA) |
Ventola con forte fastidio |
MaxRPM = 9000 |
Codice ASL di esempio
...
// _DSM - Device Specific Method
// Arg0: UUID Unique function identifier
// Arg1: Integer Revision Level
// Arg2: Integer Function Index (0 = Return Supported Functions)
// Arg3: Package Parameters
Method(_DSM, 0x4, NotSerialized) {
If(LEqual(Arg0, ToUUID("A7611840-99FE-41ae-A488-35C75926C8EB"))) {
Switch (ToInteger(Arg2)) {
Case(0) {
// _DSM functions 0 through 3 are supported
Return (Buffer() {0xf})
}
Case(1) {
// Report 200 RPM granularity for trip points
Return (\_SB.FAN0.GRAN)
}
Case(2) {
// Save lower RPM trip point
Store(DeRefOf(Index(Arg3, 0)), \_SB.FAN0.LRPM)
// Save upper RPM trip point
Store(DeRefOf(Index(Arg3, 1)), \_SB.FAN0.URPM)
// Configure hardware for the trip points, Tell EC to set fan speed trip point.
\_SB.FAN0.CRNF()
Return (0)
}
Case(3) {
Return (Package(4) {
4000, // 1-4000 RPM is impact score 1
5000, // 4001-5000 RPM is impact score 2
6000, // 5001-6000 RPM is impact score 3
9000})// 6001-9000 RPM is impact score 4
}
Default {
Return(Buffer(One) { 0x00 }) // Guid mismatch
}
}
}
Else {
Return(Buffer(One) { 0x00 }) // Guid mismatch
}
}
} // end of FAN0
}
Test e traccia
Fare riferimento alla procedura seguente per raccogliere log e visualizzare in Windows analizzatore prestazioni (WPA):Please reference following steps to collect log and view in Windows analizzatore prestazioni (WPA):
- Impostazioni -> Ricerca in Windows -> Impostazioni dell'indicizzatore di ricerca avanzata -> Avanzate -> Eliminazione e ricompilazione dell'indice (ricompilazione)
- wpr -boottrace -addboot AcpiFanNoiseImpact.wprp –filemode
- Riavviare il sistema
- Controllare lo stato dell'indice delle impostazioni -> Ricerca in Windows (assicurarsi che il dispositivo si connetta con l'origine di alimentazione AC).
- Al termine dell'indice, arrestare la traccia: wpr -boottrace -stopboot AcpiFanNoiseImpact.etl (Annulla traccia senza salvare: wpr -boottrace –cancel)
- Aprire AcpiFanNoiseImpact.etl tramite Windows analizzatore prestazioni (WPA).
Scaricare il file in AcpiFanNoiseImpact.zip Oppure, copiare il codice seguente e salvare come AcpiFanNoiseImpact.wprp
<?xml version="1.0" encoding="utf-8"?>
<WindowsPerformanceRecorder Version="1.0" Comments="Test" Company="Microsoft Corporation" Copyright="Microsoft Corporation">
<Profiles>
<!-- BufferSizes are in KB in WPRP -->
<!-- System Collectors -->
<SystemCollector Id="MySystemCollector" Name="NT Kernel Logger">
<BufferSize Value="1024" />
<Buffers Value="100" />
<StackCaching BucketCount="2048" CacheSize="20480" />
<FlushThreshold Value="70" />
</SystemCollector>
<!-- Event Collectors -->
<EventCollector Id="MyEventCollector" Name="User Session Logger">
<BufferSize Value="1024" />
<Buffers Value="100" />
<StackCaching BucketCount="2048" CacheSize="20480" />
<FlushThreshold Value="70" />
</EventCollector>
<!-- System Providers for collecting kernel events. -->
<SystemProvider Id="SP_AcpiFanNoiseImpactTrace">
<Keywords Operation="Add">
<Keyword Value="Loader" />
<Keyword Value="Power" />
<Keyword Value="ProcessThread" />
</Keywords>
</SystemProvider>
<!-- System Providers for collecting kernel events. -->
<!---->
<EventProvider Id="EP_Microsoft-Windows-Kernel-Power" Name="Microsoft-Windows-Kernel-Power" Level="5" NonPagedMemory="true">
<Keywords>
<Keyword Value="0x2" />
</Keywords>
<CaptureStateOnStart>
<Keyword Value="0x0" />
</CaptureStateOnStart>
<CaptureStateOnSave>
<Keyword Value="0x0" />
</CaptureStateOnSave>
</EventProvider>
<EventProvider Id="EP_Microsoft-Windows-Kernel-Acpi" Name="Microsoft-Windows-Kernel-Acpi" Level="5">
<Keywords>
<Keyword Value="0xffffffff" />
</Keywords>
<CaptureStateOnSave>
<Keyword Value="0xffffffff" />
</CaptureStateOnSave>
</EventProvider>
<EventProvider Id="CustomEventProvider_Microsoft.Windows.SRUM.Telemetry_TraceLogging" Name="7073707A-0587-4E03-B31F-6443EB1ACBCD" Level="5" />
<EventProvider Id="CustomEventProvider_Microsoft.Windows.Kernel.Acpi_TraceLogging" Name="C42BBFDB-4140-4ada-81DF-2B9A18AC6A7B" Level="5" />
<EventProvider Id="CustomEventProvider_Microsoft.Windows.Kernel.Power_TraceLogging" Name="63bca7a1-77ec-4ea7-95d0-98d3f0c0ebf7" Level="5" />
<EventProvider Id="CustomEventProvider_AcpiTraceGuid_WPP" Name="03906A40-CCE8-447F-83F4-E2346215DB84" Level="7" />
<EventProvider Id="CustomEventProvider_Microsoft.Windows.CentralResourceManager_TraceLogging" Name="8215e965-d26e-548e-af0e-940c1f06f250" Level="5" NonPagedMemory="true">
<CaptureStateOnSave>
<Keyword Value="0xFFFFFFFFFFFFFFFF" />
</CaptureStateOnSave>
</EventProvider>
<Profile Id="PowerTrace.Verbose.File" LoggingMode="File" Name="PowerTrace" DetailLevel="Verbose" Description="Power trace logging">
<Collectors>
<SystemCollectorId Value="MySystemCollector">
<SystemProviderId Value="SP_AcpiFanNoiseImpactTrace" />
</SystemCollectorId>
<EventCollectorId Value="MyEventCollector">
<EventProviders>
<EventProviderId Value="EP_Microsoft-Windows-Kernel-Power" />
<EventProviderId Value="EP_Microsoft-Windows-Kernel-Acpi" />
<EventProviderId Value="CustomEventProvider_Microsoft.Windows.Kernel.Acpi_TraceLogging" />
<EventProviderId Value="CustomEventProvider_AcpiTraceGuid_WPP" />
<EventProviderId Value="CustomEventProvider_Microsoft.Windows.Kernel.Power_TraceLogging" />
<EventProviderId Value="CustomEventProvider_Microsoft.Windows.SRUM.Telemetry_TraceLogging" />
<EventProviderId Value="CustomEventProvider_Microsoft.Windows.CentralResourceManager_TraceLogging" />
</EventProviders>
</EventCollectorId>
</Collectors>
</Profile>
</Profiles>
<TraceMergeProperties>
<TraceMergeProperty Id="TraceMerge_Default" Name="TraceMerge_Default" Base="">
<DeletePreMergedTraceFiles Value="true" />
<FileCompression Value="true" />
<CustomEvents>
<CustomEvent Value="ImageId" />
<CustomEvent Value="BuildInfo" />
<CustomEvent Value="VolumeMapping" />
<CustomEvent Value="EventMetadata" />
<CustomEvent Value="PerfTrackMetadata" />
<CustomEvent Value="WinSAT" />
<CustomEvent Value="NetworkInterface" />
</CustomEvents>
</TraceMergeProperty>
</TraceMergeProperties>
</WindowsPerformanceRecorder>
L'immagine seguente è un grafico WPA di esempio che mostra il lavoro dell'indicizzatore di ricerca quando la ventola è forte.
C'è un livello della ventola che renderebbe l'indice di ricerca pieno (il più alto, che dovrebbe essere il punteggio di impatto 4), ma tutti gli altri livelli della ventola dovrebbero essere ridotti e non sospensione. Ad esempio, se ACPI ha dichiarato Impact3MaxRPM = 4000 RPM nella funzione 3 (funzione Get fan operating ranges), quando Fan RPM > 4000 (4100RPM, 4500RPM), si noterà SearchIndexer.exe e SearchProtocalHost.exe l'utilizzo della CPU verrebbe sospeso.
Nota
Per visualizzare l'utilizzo della CPU, è possibile usare wpr -start power -filemode per raccogliere l'utilizzo del runtime. Usare wpr -stop fan_noise.etl per interrompere la raccolta dei log.
L'immagine seguente mostra un grafico WPA di esempio che mostra la sospensione di SearchIndexer.exe e SearchProtocolHost
