Entwurfshandbuch

Dieser Designleitfaden für das PC-Wärmemanagement enthält Informationen zum Ermitteln der PC-Temperaturwerte, die „zu heiß“ und „zu kalt“ sind.

Diese Feststellungen sind eine wichtige Anforderung für ein Design, mit dem eine optimale PC-Nutzung ermöglicht werden soll. Diese Grenzwerte helfen zudem dabei, die ersten Korrekturmaßnahmen für PC-Komponenten einzuleiten, die sich in mehreren thermischen Zonen befinden.

Ermitteln der Temperaturgrenzwerte

Variablen und Annahmen

Die folgenden Faktoren beeinflussen das thermische Verhalten von PCs:

• Hardwaredesign

  Die Bedeutung guter Hardwaredesigns kann nicht oft genug betont werden. Weitere Informationen finden Sie unter Thermische Modellierung und Auswertung für Hardware.

• Umgebung

  Dies sind externe Faktoren, die zum thermischen Verhalten des Systems beitragen. Die Software kann die Umgebung nur beeinflussen, indem die Benutzer*innen benachrichtigt werden, dass thermische Einschränkungen ein Problem darstellen (z. B. durch Anzeigen des Logos für einen fehlgeschlagenen Startversuch aufgrund thermischer Einschränkungen). Die Benutzer*innen müssen zu einer anderen Umgebung wechseln, damit diese Faktoren geändert werden können:

  • Sonnenlichteinstrahlung

    Die Intensität und der Winkel des Sonnenlichts, die sich auf den Bildschirm oder einen Teil des Systems auswirken.

  • Umgebungstemperatur

    Die Temperatur der Umgebung.

  • Luftströmung

    Mit oder ohne Luftzirkulation. Der Luft ausgesetzt oder in einem Computergehäuse.

  • Luftfeuchtigkeit

    Trocken oder feucht.

• Auslastung und Stromverbrauch

  Die Annahme ist hier, dass die Auslastung und der Stromverbrauch proportional zueinander sind. Mit anderen Worten: Je höher die Auslastung von PCs oder Komponenten ist, desto mehr Strom wird verbraucht und infolgedessen Wärme generiert. Obwohl dies möglicherweise nicht in allen Fällen zutrifft, ist dieses vereinfachte Modell hier mehr oder weniger ausreichend. An dieser Stelle kommen softwaregesteuerte Korrekturen zum Einsatz. Durch die Verringerung der Auslastung wird weniger Wärme generiert, und der PC kann weiterhin genutzt werden.

Berücksichtigen Sie beim Entwerfen und Modellieren der Hardware die in der vorherigen Liste genannten Parameter. Verwenden Sie für die Umgebung die unvorteilhaftesten Werte. Der einzige Parameter, der direkt von der Software gesteuert werden kann, ist die Auslastung.

Grundlagen der Thermik

Berücksichtigen Sie das thermische Verhalten von PCs bei konstanter Auslastung. Mit Beginn der Auslastung generieren PC-Hardwarekomponenten wie CPU und GPU Wärme, und die Temperatur steigt. Da sich die Temperatur relativ zur Umgebungstemperatur erhöht, beginnt der PC, Wärme schneller abzuführen, bis die Wärmegenerierung schließlich der Wärmeabführung entspricht und die Temperatur einen gleichbleibenden Wert erreicht. Für die gesamte Dauer dieser stetigen Auslastung sind die Leistung und der Durchsatz konstant, da keine Drosselung erfolgt.

Das folgende Diagramm zeigt die Beziehung zwischen Wärmegenerierung, Temperatur und Leistung, wenn keine Drosselung vorliegt. Beachten Sie, dass die Temperatur des PC, begrenzt durch die Umgebungstemperatur und Drosselungstemperatur, innerhalb der thermischen Hülle bleibt.

Betrachten Sie nun das thermische Verhalten eines PC mit einer anderen Auslastung, die zwar auch konstant, aber ressourcenintensiver ist. Bei dieser Auslastung wird mehr Wärme generiert als das System in die Umgebung abführen kann. Aus diesem Grund steigt die Temperatur kontinuierlich. Ohne passive Kühlung steigt die Temperatur weiter, bis das System schließlich überhitzt und die Sicherheit von Endbenutzer*innen gefährdet. Bei hohen Temperaturen kann auch die Hardware beschädigt werden. Die thermische Drosselung sorgt dafür, dass der PC diese hohen Temperaturen nicht erreicht. Wenn die Temperatur einen vordefinierten Drosselungsauslösepunkt für die Temperatur übersteigt, beginnt das System damit, die Leistung zu drosseln. Infolgedessen wird die Wärmegenerierung reduziert, und nachdem die Wärmegenerierung und die Wärmeabführung ausgeglichen wurden, erreicht die Systemtemperatur einen konstanten Wert.

Das folgende Diagramm zeigt die Beziehung zwischen der Wärmegenerierung, der Temperatur und der Leistung, wenn die Leistung gedrosselt wird, um die Wärmegenerierung zu verringern.

In beiden Fällen, die in den vorherigen Diagrammen gezeigt wurden, muss die Auslastung innerhalb einer thermischen Hülle erfolgen, um sicherzustellen, dass die Systemtemperatur keine Sicherheitsgrenzwerte überschreitet. Die thermische Hülle beginnt mit der Umgebungstemperatur und endet mit der Drosselungstemperatur. In beiden Fällen erreichen die Wärmegenerierung und die Ableitung schließlich auch einen ausgewogenen Zustand, und die Systemtemperatur wird stabilisiert.

Definieren einer thermischen Hülle

Ein gut konzipierter PC sollte eine möglichst große thermische Hülle haben, die Benutzer*innen eine langfristige Nutzung ohne softwaregesteuerte Korrekturen ermöglicht. Wie in den vorhergehenden Diagrammen dargestellt, weist die thermische Hülle eine niedrigere Grenze auf, die durch die Umgebungstemperatur bestimmt wird. Sie wird oben von der Drosselungstemperatur eingeschränkt. Während die Umgebungstemperatur keine Variable ist, die Systemdesigner*innen steuern können, kann die obere Grenze durch ein gutes Hardwaredesign weiter nach oben verschoben werden. Weitere Informationen finden Sie unter Thermische Modellierung und Auswertung für Hardware. Selbst unter der Annahme, dass es sich bei der Hardware nicht um die Hauptursache für Einschränkungen handelt, müssen beim Definieren der thermischen Hülle einige wichtige Faktoren berücksichtigt werden.

Der gewünschte Betriebsbereich sollte so groß wie möglich sein, ohne diese Grenzwertfaktoren zu beeinträchtigen:

• Safety

  Hinsichtlich der Temperatur des Systems muss zunächst sichergestellt werden, dass Benutzer*innen keine Verletzungen durch die Verwendung des Systems erleiden. Diese Anforderung gilt hauptsächlich für den Gehäusetemperatursensor.

• Hardwareschutz

  Die Temperatur sollte verhindern, dass Systemkomponenten „schmelzen“ oder anderweitig Schäden aufgrund von Hitze verursachen. Diese Anforderung gilt hauptsächlich für Komponententemperatursensoren (z. B. einen Sensor auf dem Prozessor).

• Behördliche Vorschrift

  Alle Systeme sollten anwendbare Branchenstandards (z. B. IEC 62368) für die Sicherheit von Verbraucherelektronik erfüllen.

Thermische Modellierung und Auswertung für Hardware

Software als Ergänzung zum Hardwaredesign

Beim Entwickeln von Hardwarekomponenten ist es von entscheidender Bedeutung, das Wärmemanagement zu berücksichtigen. Die Auswahl von Komponenten mit niedriger Leistung, das Platzieren von heißen Komponenten weit weg von anderen und die Verwendung von Wärmeisolierung sind nur einige Beispiele dafür, wie Hardware das Wärmemanagement erheblich verbessern kann. Diese Methoden können in Software nicht ersetzt werden. Die Softwarelösung dient beim gesamten Wärmemanagement daher nur als Ergänzung zum Hardwaredesign.

Hardwareziel

Typische Auslastungen sollten keine Form von softwaregesteuerten thermischen Korrekturen erfordern. Das Hardwaredesign sollte hinsichtlich des Wärmemanagements in der Lage sein, Wärme bei diesen Auslastungen selbst abzuführen.

Modellierung

Die Modellierung ist ein iterativer Prozess, um das zuvor beschriebene Hardwareziel zu erreichen. Bei diesem Vorgang sollen softwaregesteuerte Korrekturen nicht berücksichtigt werden. Verlassen Sie sich ausschließlich auf die Hardwarefunktionen, und passen Sie sie nach Bedarf an.

1. Definieren Sie eine typische Auslastung. Je nach Plattform des Systems sollte jedes System (vom Telefon bis hin zum Server) typische Standardauslastungen aufweisen. Diese sollten keine intensiven Auslastungen wie HD-Videokonferenzen sein, sondern eher durchschnittliche Auslastungen wie Suchvorgänge im Internet oder beim Abspielen von Musik.

2. Modellieren Sie den Stromverbrauch des Systems und einzelner Komponenten bei typischen Auslastungen, da die Wärme nicht gleichmäßig im Gehäuse verteilt wird. Achten Sie besonders auf die Komponenten, die den meisten Strom verbrauchen (z. B. der Prozessor).

3. Modellieren Sie basierend auf Schätzungen für den Stromverbrauch während der Auslastung den Anstieg der Temperatur bei den Komponenten und dem Gehäuse im Laufe der Zeit.

4. Passen Sie das mechanische Design des Systems an, um sicherzustellen, dass die Komponententemperatur bei allen Umgebungstemperaturen innerhalb der Grenzwerte für Hardwaresicherheit und Benutzerkomfort liegt. Im Folgenden finden Sie einige Methoden zur Behandlung mechanischer Designprobleme:

   1. Verbessern der Wärmeabführungsfunktion durch Hinzufügen besser wärmeleitender Materialien
   2. Erhöhen der Deltatemperatur zwischen dem Gehäuse und der internen Temperatur durch Hinzufügen von Isolationsschichten

5. Wiederholen Sie die Schritte 1 bis 4, bis Sie das gewünschte Ergebnis erzielen.

6. Montieren Sie die Hardware, und bewerten Sie das Ergebnis.

Auswertung

Bei jeder Hardwareüberprüfung muss eine Temperatur- und Leistungsmessung für repräsentative Auslastungen durchgeführt werden, um das thermische Verhalten zu bewerten. Das mechanische Design sollte bei Bedarf modifiziert werden.

Die folgenden Schritte werden empfohlen, um solche thermischen Auswertungen durchzuführen:

1. Definieren Sie eine Testmatrix für die thermische Messung:

   1. Die Matrix sollte sowohl normale als auch maximale Umgebungstemperatur abdecken.
   2. Die Matrix sollte alle typischen Auslastungen enthalten, die als Teil der thermischen Modellierung identifiziert werden, und für jede Auslastung sollten Daten für mindestens eine Stunde erfasst werden.
   3. Die Matrix sollte mehrmals auf mehreren PCs ausgeführt werden, um konsistente Ergebnisse zu generieren.

2. Erfassen Sie für jede in der Testmatrix definierte Auslastung die folgenden Daten:

   1. Daten zum Stromverbrauch des Systems und der Komponenten
   2. Daten zur Umgebungstemperatur, Temperatur interner Komponenten und der Gehäusetemperatur
   3. Softwareablaufverfolgungen zum Erkennen der thermischen Drosselung, Leistungsmetriken und Prozessorauslastung

Die Daten zur Gehäuse- und Komponententemperatur geben direkt an, welche maximale Gehäusetemperatur das System erreichen kann und ob diese Temperatur akzeptabel ist. Überlegen Sie, welche thermischen Reserven das System vor einem kritischen Herunterfahren haben könnte. Die Leistungsmetriken helfen dabei, zu bestimmen, ob das System die erforderliche Leistung liefert. Die von der Software für die thermische Drosselung aufgezeichneten Ablaufverfolgungsdaten zeigen den Prozentsatz der thermischen Drosselung an. Die Stromverbrauchsdaten und die CPU-Auslastungsdaten können helfen, zu bestimmen, welche Faktoren die Temperaturänderungen beeinflussen.

Die folgende Tabelle enthält ein Beispiel für eine solche Datensammlung für einen PC mit der folgenden Konfiguration:

Configuration

• Computername: Thermal-Test-1
• Durchschnittliche Umgebungstemperatur: 23^oC
• Auslösepunkt der thermischen Zone (_PSV): 80^oC

Category	Unterkategorie	Videostreaming	Casual Games	Fishbowl	3D-Spiele	TDP
Setup für die Auslastung		Vollbildmodus, 720p, H.264-Videostreaming über WLAN	Name des Spiels CPU-Auslastung	IE (klassisch) mit 100 Fish	Name des Spiels CPU-Auslastung	CPU und GPU 100 %
Stromverbrauch	Systemstromversorgung
	Leistung SoC
	Leistung Bildschirm
	Leistung Hintergrundbeleuchtung
Temperature	Maximale SoC-Temperatur
	Maximale Gehäusetemperatur
Leistungsmetriken		Durchschnittliche Bildfrequenz	Durchschnittliche Bildfrequenz	Durchschnittliche Bildfrequenz	Durchschnittliche Bildfrequenz

Windows-Framework für Wärmemanagement

Das Windows-Framework für Wärmemanagement bietet eine umfassende Lösung für das softwaregesteuerte Wärmemanagement. In den folgenden Beispielen wird gezeigt, wie das Wärmemanagement implementiert wird. Mit einer ordnungsgemäßen Wärmemodellierung, Validierung und einem effektiven Wärmemechanikdesign sollten alle Systeme in der Lage sein, bei den meisten Auslastungen bei den meisten Zielumgebungstemperaturen eine reibungslose Nutzung zu ermöglichen. Sollte doch eine thermische Korrektur erforderlich sein, bietet Windows eine effektive und erweiterbare Wärmemanagementarchitektur.

Das Windows-Wärmemanagement unterstützt sowohl die aktive als auch die passive Kühlung. Bei der aktiven Kühlung werden Lüfter eingeschaltet, um die Luft zirkulieren zu lassen und infolgedessen das System abzukühlen. Bei der passiven Kühlung verringern Geräte die Leistung als Reaktion auf übermäßige thermische Bedingungen. Durch das Verringern der Leistung wird der Stromverbrauch reduziert und somit weniger Wärme erzeugt.

Das Windows-Framework für Wärmemanagement basiert auf den Richtlinien, die von Systemdesigner*innen vorgegeben werden, um das Wärmemanagement im System zu erzwingen. Allgemein müssen Designer*innen angeben, wie die Messwerte der jeweiligen Wärmesensoren von jeder Komponente beeinflusst werden. Ohne diese Spezifikationen kann Windows das System thermisch nicht verwalten. Daher sind die Systemdesigner*innen dafür verantwortlich, das System thermisch zu charakterisieren, um ein gutes thermisches Design zu erzielen.

Obwohl es nicht verpflichtend ist, dass Systeme das Windows-Framework für Wärmemanagement verwenden, ist dies aufgrund der engen Integration mit dem Betriebssystem die empfohlene Lösung. Unabhängig von der verwendeten Wärmemanagementlösung müssen jedoch alle Modern-Standby-PCs die HCK-Anforderungen für Diagnosezwecke einhalten.

Wärmemanagementarchitektur

Die Windows-Architektur für Wärmemanagement basiert auf dem ACPI-Konzept der thermischen Zonen. Das ACPI-Modell für thermische Zonen erfordert die Zusammenarbeit zwischen Firmware, Betriebssystem und Treibern. Dieses Modell abstrahiert die Sensoren und Kühlgeräte aus der zentralen Wärmemanagementkomponente über gut definierte Schnittstellen. Die Verbesserungen durch das Wärmemanagement basieren auf Kapitel 11 der ACPI 5.0-Spezifikation. Das Windows-Framework für Wärmemanagement implementiert einige der in diesem Kapitel beschriebenen Funktionen.

Dies sind die essenziellen Komponenten des Modells:

• Plattformdefinitionen für thermische Zonen, die über die Firmware für Windows beschrieben werden. Eine thermische Zone ist eine abstrakte Entität mit einem zugeordneten Temperaturwert. Das Betriebssystem überwacht diese Temperatur, sodass thermische Korrekturmaßnahmen auf Geräte in der Zone angewendet werden können. Die Zone enthält eine Reihe funktionaler Geräte, die Wärme erzeugen, und eine Teilmenge von Geräten, deren Wärmegenerierung durch Anpassen der Leistung gesteuert werden kann.
• Temperatursensor, der die Temperatur der Region darstellt. Der Sensor muss die Schnittstelle zum Abrufen der Temperatur implementieren, um die Temperatur einer Zone der Firmware oder eines Windows-Temperaturtreibers abzurufen.
• Schnittstelle für die thermische Kühlung, mit der Treiber für Geräte in thermischen Zonen Passivkühlaktionen implementieren können. Jeder verwaltete Treiber muss über die Kühlungsschnittstelle verfügen, um Teil der Wärmeinfrastruktur von Windows zu sein.
• Ein zentralisierter Wärme-Manager, der die Kühlung durch Interpretation der thermischen Zonendefinitionen koordiniert und die Schnittstellen zu den erforderlichen Zeiten aufruft. Der Wärme-Manager wird im Windows-Kernel implementiert und erfordert keine Maßnahmen von Systemdesigner*innen.

Das folgende Blockdiagramm ist eine Übersicht über die Windows-Wärmemanagementarchitektur. Die Hauptkomponenten sind der Wärme-Manager, die thermische Zone, verwaltete Treiber und der Temperatursensor. Die thermische Zone bestimmt das Drosselungsverhalten der verwalteten Geräte basierend auf Einschränkungen, die vom Wärme-Manager vorgegeben werden. Der vom Wärme-Manager verwendete Algorithmus nutzt den Temperaturmesswert des Sensors für die thermische Zone als Eingabeparameter.

Die thermischen Zonen im System müssen in der der ACPI-Firmware beschrieben und dem Wärme-Manager über die ACPI dargelegt werden. Durch die Konfigurationsinformationen weiß der Wärme-Manager, wie viele thermische Zonen verwaltet werden müssen, wann diese jeweils zu drosseln sind und wie viele Geräte Teil der Zone sind. Zur Überwachung der Temperatur bieten Systemdesigner*innen Unterstützung in der ACPI-Firmware für thermische Benachrichtigungen.

Wenn der Wärme-Manager über ein thermisches Ereignis in einer spezifizierten Zone benachrichtigt wird, beginnt er regelmäßig mit der Auswertung der Temperatur der Zone und bestimmt den Prozentsatz der thermischen Drosselungsleistung, der auf Geräte in der thermischen Zone angewendet werden soll. Diese Auswertung erfolgt durch den Algorithmus für die thermische Drosselung, der in der ACPI-Spezifikation beschrieben wird. Anschließend benachrichtigt der Wärme-Manager alle Geräte in der Zone, um die Leistung um einen bestimmten Prozentsatz zu reduzieren, und die Gerätetreiber wandeln den Drosselungsprozentsatz in eine geräteklassenspezifische Aktion zur Leistungsreduktion um. Die regelmäßige Auswertung und Drosselung wird beendet, wenn die Temperatur der thermischen Zone unter die Drosselungsgrenzwerttemperatur fällt und keine Drosselung mehr erforderlich ist.

Feedbackschleife

Ein weiterer Aspekt der Wärmemanagementarchitektur bezieht sich auf Eingaben, Richtliniendirektion und verwaltete Geräte. Im folgenden Blockdiagramm sind die Eingaben der Feedbackschleife die Temperatur und der elektrische Strom. Diese Eingaben werden verwendet, um die zu implementierende Wärmerichtlinie zu bestimmen. Der Wärme-Manager basiert ausschließlich auf der Temperatureingabe, und der Richtlinientreiber kann jede gewünschte Eingabe verwenden. Anschließend wendet die thermische Zone diese Richtlinie auf die verwalteten Treiber an. Nachdem die Richtlinie angewendet wurde, aktualisieren die Sensoren ihre Werte und schließen die Schleife.

Das folgende Blockdiagramm zeigt die drei Stufen des Wärmereaktionsmodells. Eingaben von Temperatursensoren und elektrischen Stromsensoren bieten Informationen, um zu bestimmen, welche Wärmerichtlinie angewendet werden soll. Diese Richtlinie wird auf die verwalteten Treiber angewendet und wirkt sich dann auf die Messwerte der Sensoren aus. Der Vorgang wiederholt sich in einer Feedbackschleife.

Verantwortlichkeiten der Systemimplementierer*innen

Wie zuvor bereits erwähnt, sind einige Komponenten erforderlich, um über eine vollständige thermische Lösung von Windows zu verfügen. Die Architektur des Wärmeframeworks ist speziell so konzipiert, dass die Verantwortlichkeiten des Hardwareanbieters und der Systemintegrator*innen getrennt werden können.

Dies sind die erforderlichen Komponenten, die Partner implementieren müssen:

• Sensoren

  Die Temperatursensortreiber sollten vom Hardwareanbieter bereitgestellt werden. Da Temperatursensoren keine Kenntnisse über die thermischen Zonen benötigen, die auf diesen basieren, sollten ihre Funktionen bei verschiedenen Plattformdesigns als Standard verwendet werden. Hardwareanbieter sind auch für die benutzerdefinierten Sensoren für Richtlinientreiber (z. B. Stromsensoren) verantwortlich.

• Thermische Zonen

  Die thermischen Zonen können vom Hardwareanbieter und/oder den Systemintegrator*innen definiert werden. Alle Systeme müssen mindestens eine thermische Zone umfassen, die eine kritische Herunterfahrtemperatur (und Ruhezustandstemperatur, sofern unterstützt) implementiert, die vom Hardwareanbieter oder den Systemintegrator*innen verwaltet werden kann. Bei anderen thermischen Zonen, die spezifische Geräte oder die Gehäusetemperatur für Korrekturen überwachen, ist es jedoch üblich, dass Systemintegrator*innen spezifischere Kenntnisse über das thermische Verhalten des Systems haben. Daher werden diese thermischen Zonen in der Regel von den Systemintegrator*innen implementiert.

• Schnittstelle für die thermische Kühlung für Gerätetreiber

  Die Entwickler*innen, die den Treiber für das Gerät konfigurieren, das thermisch verwaltet werden soll, sollten auch die Kühlungsschnittstelle implementieren. Der Gerätetreiber verwendet diese Schnittstelle, um das Framework für das Wärmemanagement zu aktivieren. Gerätetreiber verfügen über spezifische Kenntnisse über die Funktionen ihrer Geräte. Diese Treiber müssen die Schnittstelle für die thermische Kühlung implementieren, damit sie die von der thermischen Zone angeforderten Aktionen ordnungsgemäß interpretieren können.

Sensoren

Sensoren stellen Eingaben bereit, um zu bestimmen, wie die Wärmerichtlinie lautet. Windows unterstützt nur Temperatursensoren als Eingabequelle für den Wärme-Manager. Ein Richtlinientreiber kann jedoch zusätzlich Eingaben von benutzerdefinierten Treibern wie einem Stromsensortreiber verwenden.

Temperatursensor

Der Temperatursensor bietet die folgenden Funktionsmodi:

• Kontinuierliche Überwachung von Temperaturänderungen ohne Beteiligung des Wärme-Managers oder der thermischen Zone
• Benachrichtigung für den Wärme-Manager, wenn die Temperatur den von „_PSV“, „_HOT“ oder „_CRT“ definierten Grenzwert überschreitet
• Reaktion auf Temperaturabfragen und Rückgabe des aktuellen Temperaturwerts

Das folgende Diagramm zeigt, wie die Temperaturüberwachung während der Drosselung funktioniert. Die ACPI-Firmware oder der Temperatursensortreiber sollte den Wärme-Manager informieren, wenn die Temperatur einen vordefinierten Grenzwert wie „_PSV“, „_HOT“ oder „_CRT“ erreicht, und anschließend auf die regelmäßigen Abfragen des Wärme-Managers für die aktuelle Temperatur reagieren. Der Zeitraum der Temperaturabfrage wird durch „_TSP“ definiert.

Um sicherzustellen, dass der Wärme-Manager immer benachrichtigt wird, wenn die Temperatur den Grenzwert überschreitet, sollte die Temperatursensorunterbrechung immer aktivierbar sein (auch wenn sich das System im Modern-Standby-Modus und SoC in einem Niedrigleistungszustand befindet). Wenn die Temperatursensorunterbrechung nicht immer aktivierbar ist, sollte die Unterbrechung zumindest so konfiguriert werden, dass sie in Abhängigkeit von bestimmten Stufen aktiviert wird, um potenzielle Verluste durch Unterbrechungen zu vermeiden.

Ein Wärmesensor kann von mehreren thermischen Zonen verwendet werden, obwohl sich nur ein Wärmesensor in einer thermischen Zone befinden kann.

Es wird empfohlen, dass die Sensorhardware auf +/- 2 ^oC genau ist.

Die von „_TMP“ oder einem Temperatursensortreiber gemeldete Temperatur kann der tatsächliche Wert eines Sensors oder ein abgeleiteter Wert sein, der auf mehreren Sensoren basiert.

Dies wird in der Regel vom Hardwareanbieter bereitgestellt. Windows unterstützt zwei Implementierungen für die Überwachung der Temperatur:

• Temperatursensortreiber
• ACPI-basiert

Implementierung 1: Temperatursensortreiber

Der Temperatursensortreiber meldet einfach die Temperatur des Sensors. Der ACPI-Treiber gibt eine hervorstechende IOCtl mit dem Sensortreiber aus, um eine Überschreitung bei einem der Auslösepunkte zu erkennen. Darüber hinaus kann die ACPI eine IOCtl ohne Timeout ausgeben, um die aktuelle Temperatur zu messen. Der Sensortreiber sollte den Abbruch der bestimmten IOCtl verarbeiten, wenn diese während des Wartens auf den Ablauf des Timeouts abgebrochen wird. Der Temperatursensor muss die folgende Schnittstelle implementieren:

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)

In der folgenden Tabelle werden die Eingabe- und Ausgabeparameter für die Temperaturmesswertschnittstelle beschrieben.

Parameter	Beschreibung
Timeout	Die Zeit in Millisekunden, die gewartet wird, bevor die Temperaturdaten zurückgegeben werden. 0 gibt an, dass die Temperatur sofort abgelesen werden sollte. –1 gibt an, dass beim Lesevorgang kein Timeout auftreten soll.
LowTemperature	Der niedrigere Grenzwert für die Rückgabe des neuen Temperaturwerts. Sobald die Temperatur unter den niedrigen Temperaturgrenzwert fällt, sollte der Treiber die IOCtl abschließen. Wenn die Temperatur bereits unter der niedrigen Temperatur liegt, sollte die IOCtl sofort abgeschlossen werden.
HighTemperature	Der obere Grenzwert für die Rückgabe des neuen Temperaturwerts. Sobald die Temperatur den hohen Temperaturgrenzwert übersteigt, sollte der Treiber die IOCtl abschließen. Wenn die Temperatur bereits über der Höchsttemperatur liegt, sollte die IOCtl sofort abgeschlossen werden.
IOCtl-Rückgabewert	Ausgabepuffer mit ULONG-Größe, der die aktuelle Temperatur in Zehntel Grad Kelvin zurückgibt.

Ein Temperatursensor kann von einer oder mehreren thermischen Zonen verwendet werden. Um anzugeben, welcher Temperatursensor für eine thermische Zone verwendet werden soll, sollte die gerätespezifische thermische Methode (Device Specific Method, „_DSM“) für die thermische Zone angegeben und Funktion 2 implementiert werden. (Für die Abwärtskompatibilität kann der Temperatursensortreiber zusätzlich zum thermischen Zonenstapel geladen werden. Bei der bevorzugten Implementierung ist der Sensortreiber jedoch vom thermischen Zonenstapel getrennt.) Diese „_DSM“ wird wie folgt definiert:

ArgumenteArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Funktion = 2 Arg3: Ein leeres Paket. Rückgabe: Einzelner Verweis auf das Gerät, das die Temperatur der thermischen Zone zurückgibt.

Die thermische Zone muss auch eine Abhängigkeit vom Temperatursensorgerät mit „_DEP“ angeben. Hier sehen Sie ein einfaches Beispiel für die _DSM-Implementierung eines Sensorgeräts.

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.

}

Weitere Informationen finden Sie unter Gerätespezifische Methode für Windows-Wärmeerweiterungen.

Implementierung 2: ACPI-basiert

Wie in der ACPI-Spezifikation definiert sollte die ACPI-Firmware „_TMP“ und „Notify 0x80“ unterstützen. Der Vorteil dieses Ansatzes besteht darin, dass keine zusätzlichen Treiber im System installiert werden müssen. Dieser Ansatz ist jedoch auf die Interaktion mit Ressourcen beschränkt, die über ACPI-Vorgangsregionen zugänglich sind.

Wärmerichtliniensteuerung

Thermische Zone

Eine thermische Zone ist eine einzelne thermische Drosselungsentität. Sie verfügt über eigene thermische Drosselungseigenschaften (z. B. Auslösepunkte, Drosselungsbeispielrate und Drosselungsformelkonstanten). Eine thermische Zone kann mehrere Wärmedrosselungsgeräte umfassen, von denen jedes zur Temperatursteigerung in der thermischen Zone beitragen kann. Alle Geräte in derselben thermischen Zone müssen die gleichen Einschränkungen berücksichtigen, die auf die thermische Zone angewendet werden.

Um sicherzustellen, dass thermische Zonen und deren Parameter genau definiert werden, sollten Systemdesigner*innen Folgendes tun:

• Identifizieren von Hotspots im Systemgehäuse und Bestimmen, wie diese Hotspots Wärme an die Temperatursensoren ableiten (Mit Ausnahme von Gehäusetemperatursensoren sind Wärmesensoren idealerweise an den heißen Stellen im System platziert.)
• Charakterisieren der Temperaturbeziehung des Systems. Ordnen Sie die Messwerte der Temperatursensoren der Komponententemperatur und der Gehäusetemperatur zu.

Grenzwert für Überdrosselung

Ab Windows 10 wurde ein neues Feature für den Status der thermischen Zone zusammen mit dem Status Überdrosselt in das Windows-Wärmemanagement eingeführt. Wenn eine thermische Zone den konzipierten Drosselungsgrad des Geräts überschreitet, benachrichtigt der Wärme-Manager die Betriebssystemkomponenten, dass das System überdrosselt ist. Mit dieser Benachrichtigung kann das System die Auslastung reduzieren, um den Wärmestatus zu verbessern.

Der Wärme-Manager verwaltet eine globale Anzahl der thermischen Zonen, die den Status „Überdrosselt“ aufweisen. Wenn die Anzahl den Wert „0“ (null) übersteigt, sendet der Wärme-Manager eine WNF-Benachrichtigung (Windows Notification Facility) an das System, die angibt, dass eine Überdrosselung vorliegt. Wenn die Anzahl der überdrosselten Zonen wieder „0“ (null) entspricht, sendet der Wärme-Manager eine weitere WNF-Benachrichtigung an das System, die angibt, dass es keine überdrosselten Zonen mehr gibt.

Um den Überdrosselungsgrenzwert für eine thermische Zone anzugeben, sollte die thermische „_DSM“ für die thermische Zone angegeben werden, wobei Funktion 3 implementiert ist. Diese „_DSM“ wird wie folgt definiert:

ArgumenteArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Funktion = 3 Arg3: Ein leeres Paket. Rückgabe: Ein ganzzahliger Wert mit dem aktuellen Überdrosselungsgrenzwert (angegeben in Prozent).

Hier finden Sie ein Beispiel für eine „_DSM“, in der angegeben wird, dass die Zone überdrosselt ist (Drosselungsstufen 0 bis 49 Prozent).

 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

Der Überdrosselungsgrenzwert wird erneut abgelesen, wenn „Notify(0x81)“ in Bezug auf die thermische Zone empfangen wird.

Implementieren von ACPI-Objekten

In der folgenden Tabelle sind alle ACPI-Objekte aufgeführt, die in ACPI-Firmware implementiert werden müssen, um eine thermische Zone zu definieren.

Category	Steuerungsmethode
Identifizieren der Geräte, die in der Zone enthalten sind	_TZD Listet die Geräte in der thermischen Zone auf _PSL (Optional) Listet die Prozessoren in der thermischen Zone auf. Prozessoren können stattdessen in „_TZD“ enthalten sein, Windows unterstützt jedoch beide Implementierungen.
Angeben von thermischen Grenzwerten, bei denen Maßnahmen ergriffen werden müssen	_PSV Die Temperatur, bei der die Drosselung gestartet werden soll. Weitere Informationen finden Sie unter Definieren einer thermischen Hülle. _HOT (Optional) Die Temperatur, bei der das Betriebssystem das System in den Ruhezustand versetzt. Bei Systemen, die den Ruhezustand nicht unterstützen, initiiert das Betriebssystem das kritische Herunterfahren. Dies wird bei x86- bzw. x64-Systemen aufgrund des Vorteils der Speicherung von Benutzerdaten im Ruhezustand für mindestens eine thermische Zone dringend empfohlen. _CRT Die Temperatur, bei der das Betriebssystem kritisches Herunterfahren initiiert. Keine Benutzermodusbenachrichtigung. Für mindestens eine thermische Zone in einem System muss „_CRT“ angegeben sein. Wenn dies nicht der Fall ist, durchläuft das System nicht den Vorgang zum Herunterfahren, wenn das System eine kritische Temperatur erreicht. Stattdessen wird der Fail-Safe-Auslösepunkt der Firmware erreicht und die Stromversorgung wahrscheinlich vom Betriebssystem getrennt.
Beschreiben des passiven Kühlungsverhaltens	_TC1 Steuern Sie, wie aggressiv der Wärme-Manager die thermische Drosselungsleistung für Temperaturänderungen anwendet. _TC2 Steuern Sie, wie aggressiv der Wärme-Manager die thermische Drosselungsleistung für das Temperaturdelta zwischen der aktuellen Temperatur und „_PSV“ anwendet. _TSP Entsprechendes Temperaturmessungsintervall für die Zone in Zehntelsekunden. Der Wärme-Manager verwendet dieses Intervall, um zu bestimmen, wie oft die thermische Drosselungsleistung ausgewertet werden soll. Muss größer sein als Null. Weitere Informationen finden Sie unter Algorithmus für die thermische Drosselung.
Beschreiben des aktiven Kühlungsverhaltens	_ACx (Optional) Die Temperatur, bei der ein Lüfter eingeschaltet werden soll. Muss vom größten zum kleinsten Wert geordnet sein, wobei „_AC0“ der größte Wert ist. _ALx Liste aktiver Kühlgeräte
Festlegen einer aktiven/passiven Kühlungsrichtlinie	_SCP (Optional) Zum Festlegen der bevorzugten Kühlungsrichtlinie der Benutzer*innen, wenn sowohl die aktive als auch die passive Kühlung von einer Zone unterstützt wird
Minimales Drosselungslimit	_DSM Verwenden Sie „UUID: 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500“, um das minimale Drosselungslimit festzulegen. Beachten Sie, dass dies für das Windows-Wärmeframework speziell ist und nicht in der ACPI definiert wird. Weitere Informationen finden Sie unter Minimales Drosselungslimit.
Übermitteln der Temperatur	_TMP Ablesen der Temperatur der thermischen Zone _HID Anbieterspezifischer Hardwarebezeichner zum Laden des Windows-Temperaturtreibers _DTI (Optional) Zum Benachrichtigen der Plattformfirmware, dass einer der thermischen Grenzwerte einer Zone überschritten wurde. Mit dieser Methode kann die Firmware Hysterese implementieren, indem die Grenzwerte der Zone geändert werden. _NTT (Optional) Zum Angeben erheblicher Temperaturänderungen, über die die Plattformfirmware ebenfalls über „_DTI“ benachrichtigt werden sollte
Benachrichtigen des Wärme-Managers	Notify 0x80 Benachrichtigt das Betriebssystem, dass der Grenzwert (_PSV) überschritten wurde. Der Windows-Wärme-Manager beginnt mit der Wärmesteuerung. Notify 0x81 (Optional) Benachrichtigt das Betriebssystem, dass sich die Grenzwerte der Zone geändert haben. Der Windows-Wärme-Manager führt selbst Aktualisierungen durch, um die neuen Werte zu verwenden. Diese Methode wird in der Regel verwendet, um Hysterese zu implementieren.
Angeben des Temperatursensorgeräts	_DSM Verwenden Sie „UUID: 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500“. Weitere Informationen finden Sie unter Temperatursensor. _DEP Laden eines Geräts, auf das sich der Temperatursensor bezieht

Minimales Drosselungslimit

Das minimale Drosselungslimit ist eine _DSM-Methode der thermischen Erweiterung von Microsoft, die eine niedrigere Grenze für „_PSV“ erstellt, die von einem gedrosselten Gerät angefordert wird. Mit anderen Worten: Hiermit wird bestimmt, inwiefern eine thermische Zone die Leistung der gesteuerten Geräte begrenzt. Wenn dieser Wert vorhanden ist, wird die „_DSM“ für die minimale Drosselung beim Start und jedes Mal dann gelesen, wenn die thermische Zone „Notify (0x81)“ (ACPI) empfängt. Bei jeder Iteration des passiven Kühlungsalgorithmus wird Folgendes verwendet, um die Änderung des Leistungslimits (DP) zu berechnen, das der Wärme-Manager auf Geräte in der Zone anwendet:

DP [%] = _TC1 × (Tₙ – Tₙ₋₁) + _TC2 × (Tₙ – Tₜ) Anschließend wird Folgendes verwendet, um das tatsächliche Leistungslimit zu berechnen:

Pₙ = Pₙ₋₁ – DP Wenn das minimale Drosselungslimit (MTL) implementiert ist, ändert sich diese zweite Formel wie folgt:

Pₙ = max(Pₙ₋₁ – DP, MTL) Um das minimale Drosselungslimit für eine thermische Zone anzugeben, sollte die thermische „_DSM“ für die thermische Zone angegeben werden, wobei Funktion 1 implementiert ist. Diese „_DSM“ wird wie folgt definiert:

ArgumenteArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Funktion = 1 Arg3: Ein leeres Paket. Rückgabe: Ein ganzzahliger Wert mit dem aktuellen minimalen Drosselungslimit (angegeben in Prozent).

Dies ist ein einfaches Beispiel dafür, wie die „_DSM“ die Drosselung auf nicht weniger als 50 Prozent begrenzt.

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

Wärme-Manager im Kernel

Der Wärme-Manager von Windows wird im Rahmen des Windows-Kernels implementiert. Er überwacht die Temperatur aller thermischen Zonen und wendet die thermische Drosselung entsprechend an.

Jedes Mal, wenn der Wärme-Manager den ACPI-Treiber für die aktuelle Temperatur abfragt, wird berechnet, welcher Prozentsatz für die thermische Drosselungsleistung auf alle Wärmedrosselungsgeräte in der thermischen Zone angewendet werden soll. Das thermische Limit wird ausgewertet und angewendet, wenn der passive Kühlungsgrenzwert (_PSV) überschritten wird. Zudem wird er bei jedem Temperaturmessungsintervall (_TSP) angewendet, bis die Temperatur auf einen Wert darunter abgekühlt ist, und das thermische Limit entspricht wieder 100 Prozent. Die Hardware muss erkennen, wann der „_PSV“ überschritten wurde. Dies muss dann über eine ACPI-Hardwareereignisebenachrichtigung signalisiert werden.

Algorithmus für die thermische Drosselung

Der Algorithmus für die thermische Drosselung verwendet die folgende Formel, die in der ACPI-Spezifikation definiert ist:

DP [%] = _TC1 × ( Tₙ – Tₙ₋₁ ) + _TC2 × (Tₙ – Tₜ), wobei

Tₙ = aktuelle Temperaturmessung des Temperatursensors in der thermischen Zone in Zehntel Grad Kelvin; Tₙ₋₁ = Temperatur der vorherigen Messung; Tₜ = Zieltemperatur in Zehntel Grad Kelvin (_PSV); DP = Leistungsänderung erforderlich. Dies ist ein linearer Wert zwischen 0 (vollständig gedrosselt) und 100 Prozent (nicht gedrosselt), der auf jedes Kühlgerät in der Zone angewendet werden soll. Diese Formel beschreibt die Feedbackschleife zwischen den Temperaturänderungen und der Drosselungsleistung. Bei jeder Iteration der Schleife erfordert das Temperaturdelta zwischen den aktuellen und vorherigen Temperaturwerten, dass die Leistung P um DP Prozent reduziert wird. Der DP-Wert ist der Wert für die anzuwendende thermische Drosselung. Viele Kühlgeräte umfassen keine lineare thermische Reaktion auf Kühlungskorrekturmaßnahmen. In diesen Geräten ist das thermische Limit ein Hinweis für das Gerät, um anzugeben, welche Kühlleistung erforderlich ist. Jedes Kühlgerät verfügt über eine eigene Zuordnung dieses linearen Werts zu gerätespezifischen thermischen Korrekturmaßnahmen. Die Drosselungsgeräteleistung verringert den Stromverbrauch und die Wärmeerzeugung, sodass die Temperatur sinkt.

Die beiden Konstanten „_TC1“ und „_TC2“ steuern, wie aggressiv die thermische Drosselung in dieser Feedbackschleife angewendet wird. Je größer „_TC1“ ist, desto aggressiver wird die thermische Drosselung verwendet, um eine stabile Temperatur beizubehalten. Je größer „_TC2“ ist, desto aggressiver wird die thermische Drosselung verwendet, um eine Temperatur nahe des Auslösepunkts zu erreichen.

In der folgenden Tabelle wird gezeigt, wie der Wärme-Manager DP berechnet und anwendet. In diesem Beispiel werden die folgenden Parameterwerte verwendet:

Configuration

• _PSV = 325 ^oK
• _TC1 = 2
• _TC2 = 3
• _TSP = 5000 Millisekunden
• Angenommen, die Temperatur steigt alle fünf Sekunden kontinuierlich um ein Grad.

Die Spalte ganz rechts in der folgenden Tabelle (Spalte P) gibt die gedrosselte Leistungsstufe an, die sich aus der Erzwingung der Einschränkungen ergibt, die von diesen Parametern angegebenen werden.

Iteration	Time	Tₙ	DP	P
1	0 Sekunden	326 oK	= 2 × 1 + 3 × 1 = 5 %	95 %
2	5 Sekunden	327 oK	= 2 × 1 + 3 × 2 = 8 %	87 %
3	10 Sekunden	328 oK	= 2 × 1 + 3 × 3 = 11 %	76 %
4	15 Sekunden	320 oK	= 2 × 1 + 3 × 4 = 14 %	62 %
5	20 Sekunden	330 oK	= 2 × 1 + 3 × 5 = 17 %	45 %
...

Richtlinientreiber

Der Algorithmus, der gemäß ACPI-Spezifikation standardmäßig verwendet wird, um den Drosselungsprozentsatz zu bestimmen, wird für alle thermischen Zonen verwendet. Wie zuvor beschrieben, basiert dieser Algorithmus ausschließlich auf dem Temperatursensor, der mit dieser thermischen Zone verknüpft ist, für die die Temperatur begrenzt werden kann.

Wenn ein anderer Algorithmus bevorzugt wird, können die Systemdesigner*innen einen Richtlinientreiber implementieren, um den bevorzugten Algorithmus zu verwenden. Ein Richtlinientreiber befindet sich oben im Stapel für die thermische Zone, die er steuert. Für diese Zone kann der Algorithmus des Richtlinientreibers anstelle des ACPI-Algorithmus im Wärme-Manager verwendet werden. Der Algorithmus des Richtlinientreibers kann alle Informationen, auf die er zugreifen kann, als Eingabe verwenden. Die vom Treiber getroffenen Richtlinienentscheidungen werden an den Wärme-Manager übergeben, der die Informationen protokolliert und für die Anwendung an die thermische Zone übermittelt.

Wenn Sie einen Richtlinientreiber für eine thermische Zone verwenden bedeutet dies, dass der Richtlinientreiber (nicht die ACPI und das Betriebssystem) ausschließlich für die Entscheidung verantwortlich ist, wann und inwiefern eine Zone gedrosselt wird.

Wenn ein Richtlinientreiber vorhanden ist, werden unter anderem alle Auslösepunkte, thermischen Konstanten und das minimale Drosselungslimit vollständig ignoriert. Das Betriebssystem hat keine Informationen darüber, warum die aktuelle Drosselungsstufe für die thermische Zone festgelegt ist. Die Verwendung eines Richtlinientreibers anstelle einer proprietären Lösung bietet einige Vorteile. Ein Richtlinientreiber nutzt den integrierten Prozess der Drosselungsgeräte. Der Richtlinientreiber kann alle Schritte übernehmen, die in einer thermischen Zone für die thermische Korrekturmaßnahme ausgeführt werden können. Darüber hinaus werden Diagnosen für das Windows-Wärmemanagement automatisch geerbt.

Die Wärmerichtlinienschnittstelle wurde aktualisiert, um einen neuen Parameter einzuschließen, der angibt, ob die Zone überdrosselt ist. Dieser Parameter wird als FALSE initialisiert. Alte Richtlinientreiber erkennen den neuen Parameter nicht, und neue Treiber wissen, dass der neue Parameter unterstützt wird, wenn sie die Richtlinienversion 2 erkennen.

#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;

Der Richtlinientreiber kann angeben, dass die thermische Zone überdrosselt ist, indem die Richtlinien-IOCtl mit dem auf TRUE festgelegten OverThrottled-Parameter abgeschlossen wird. Wenn sich die thermischen Bedingungen verbessern, kann der Wärmerichtlinientreiber die IOCtl mit dem auf FALSE zurückgesetzten OverThrottled-Parameter abschließen, um anzugeben, dass die gewünschten Bedingungen in der thermischen Zone wiederhergestellt wurden. Windows erfordert keine Drosselung durch den Richtlinientreiber, wenn das Überdrosselungsflag festgelegt ist.

Thermisch verwaltete Geräte

Thermische Zonen steuern das thermische Verhalten verwalteter Geräte durch die Kernelmodustreiber. Ein Wärmedrosselungsgerät befindet sich möglicherweise in mehreren thermischen Zonen. Wenn mehrere thermische Zonen unterschiedliche Prozentsätze für die thermische Drosselungsleistung anfordern, wählt der Wärme-Manager den minimalen Prozentsatz für die thermische Drosselungsleistung aus, um sie auf das Wärmedrosselungsgerät anzuwenden.

Viele Kühlgeräte umfassen keine lineare thermische Reaktion auf Kühlungskorrekturmaßnahmen. In diesen Fällen ist das thermische Limit ein Hinweis für das Gerät hinsichtlich des erforderlichen Kühlungsgrads. Jedes Kühlgerät verfügt über eine eigene Zuordnung dieses linearen Werts zu seinen spezifischen thermischen Korrekturmaßnahmen.

Da jeder Gerätetreiber geladen wird, fragt die ACPI nach der Schnittstelle für die thermische Kühlung und registriert jedes reagierende Gerät als Kühlgerät. Wenn die passive Kühlung später im Gange ist und sich das thermische Limit für eine Zone geändert hat, ruft die ACPI diese Schnittstelle in jedem Kühlgerät in der Zone auf. Das Kühlgerät ordnet das angegebene thermische Limit dann den spezifischen Kühleigenschaften zu und implementiert geeignete Kühlungskorrekturmaßnahmen. Beachten Sie, dass das thermische Limit, das das Gerät am meisten beschränkt (also der niedrigste Prozentsatz), an das Gerät übergeben wird, wenn sich das Kühlgerät in mehreren thermischen Zonen befindet.

Hinweis: Windows bietet integrierte Implementierungen der thermischen Drosselung für Prozessoren, die Hintergrundbeleuchtung und den ACPI-Steuerungsmethodenakku.

Schnittstelle für die thermische Kühlung

Windows stellt die Erweiterungspunkte für Gerätetreiber für die Registrierung als Wärmedrosselungsgerät und das Empfangen der Anforderung des Prozentsatzes für die thermische Drosselung bereit. Das Gerät ist dann dafür verantwortlich, diesen Prozentsatz in eine Aktion umzuwandeln, die sinnvoll ist.

Geräte, die als Wärmedrosselungsgeräte hinzugefügt werden sollen, sollten zuerst die _HID-Informationen in der Liste mit Geräten für thermische Zonen hinzufügen und dann die folgenden Schnittstellen implementieren. Da jeder Gerätetreiber geladen wird, fragt die ACPI nach dieser Schnittstelle und registriert jedes reagierende Gerät als Kühlgerät. Wenn die passive Kühlung später im Gange ist und sich das thermische Limit für eine Zone geändert hat, ruft die ACPI diese Schnittstelle in jedem Kühlgerät in der Zone auf. Das Kühlgerät ordnet das angegebene thermische Limit dann den spezifischen Kühleigenschaften zu und implementiert geeignete Kühlungskorrekturmaßnahmen. Beachten Sie, dass das thermische Limit, das das Gerät am meisten beschränkt (also der niedrigste Prozentsatz), an das Gerät übergeben wird, wenn sich das Kühlgerät in mehreren thermischen Zonen befindet.

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

Prozessor

Für Prozessoren übermittelt der Wärme-Manager den Prozentsatz für die thermische Drosselung an den Prozessorleistungs-Manager (PPM). Die thermische Drosselung von Prozessoren ist ein integriertes Feature von Windows.

Prozessoraggregator

Das Prozessoraggregatorgerät ermöglicht das Parken von Kernen (Core Parking) als thermische Korrekturmaßnahme. Zonen können das Parken von Kernen als thermische Korrekturmaßnahme angeben, wenn das Prozessoraggregatorgerät Mitglied einer thermischen Zone ist. Prozessoren müssen für das Parken von Kernen nicht gedrosselt werden. Diese Implementierung funktioniert parallel mit dem Leerlauf logischer Prozessoren (LPI). Beachten Sie, dass dies den Einschränkungen beim Parken von Kernen unterliegt. Genauer gesagt führt jede Aufgabe, die einem geparkten Kern zugewiesen wird, zur Ausführung des Kerns.

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

Grafiken

Damit ein Miniport-Grafiktreiber eines Drittanbieters thermisch verwaltet werden kann, muss er mit dem Windows-Grafikporttreiber „Dxgkrnl.sys“ interagieren. „Dxgkrnl.sys“ umfasst die Schnittstelle für die thermische Kühlung und übergibt alle Drosselungsanforderungen im Stapel nach unten zum Miniporttreiber. Es liegt in der Verantwortung des Miniporttreibers, die Anforderung in eine Aktion umzuwandeln, die für das Gerät spezifisch ist.

Das folgende Blockdiagramm zeigt die Architektur der thermischen Zone, die die GPU steuert.

Hintergrundbeleuchtung

Das Dimmen der Hintergrundbeleuchtung kann die thermischen Bedingungen bei einer mobilen Plattform erheblich verbessern. Windows empfiehlt, dass die Systemanzeigehelligkeit während des Betriebs thermisch niemals auf weniger als 100 Nits begrenzt ist.

Für die Steuerung der Hintergrundbeleuchtung übermittelt der Wärme-Manager den Prozentsatz für die thermische Drosselung an den Monitortreiber (Monitor.sys). „Monitor.sys“ legt die Einstellung für die tatsächliche Hintergrundbeleuchtungsstufe unter Windows basierend auf dieser thermischen Eingabe und anderen Eingaben fest. Anschließend wendet „Monitor.sys“ die Einstellung für die Hintergrundbeleuchtungsstufe entweder über die ACPI oder den Displaytreiber an.

Beachten Sie, dass der Prozentsatz für die thermische Drosselung schließlich auf null Prozent sinken kann, wenn die Temperatur in der thermischen Zone, die die Hintergrundbeleuchtung einschließt, weiterhin steigt. Die Implementierung der Hintergrundbeleuchtungsstufe in die ACPI oder den Displaytreiber sollte sicherstellen, dass Endbenutzer*innen bei der minimalen Helligkeitsstufe, die für die Leistungssteuerung verfügbar ist, das Display nutzen können.

Hinweis: Während des Betriebs ist die Systemanzeigehelligkeit thermisch niemals auf weniger als 100 Nits begrenzt.

Akku

Eine weitere Hauptquelle für die Wärmeerzeugung im System ist die Akkuaufladung. Benutzer*innen sollten den Ladevorgang unter eingeschränkten thermischen Bedingungen reduzieren und sogar vollständig stoppen. Der Akkuladevorgang sollte unter normalen Bedingungen jedoch nicht beeinträchtigt werden.

Hinweis: Es wird empfohlen, dass der Akkuladevorgang nicht gedrosselt wird, wenn (1) sich das System im Leerlauf befindet und der Temperaturwert innerhalb des Umgebungstemperaturbereichs unter 35 ^oC liegt oder (2) die Umgebungstemperatur unter beliebigen Bedingungen unter 25 ^oC liegt.

Der Miniclasstreiber für den Windows-Steuerungsmethodenakku (Cmbatt.sys) verwendet die Schnittstelle für thermische Kühlung wie zuvor beschrieben direkt. Firmware ist beim Laden für die Berücksichtigung des aktuellen thermischen Limits verantwortlich. Eine neue ACPI-Steuermethode ist erforderlich, um das thermische Limit für den Ladevorgang festzulegen. Diese Methode wird wie in der ACPI 5.0-Spezifikation in Abschnitt 9.14.1 definiert als gerätespezifische Methode (_DSM) implementiert.

Um den Prozentsatz für die thermische Drosselung anzuwenden, wertet „Cmbatt.sys“ die Steuerungsmethode für die gerätespezifische Methode (_DSM) aus, um die ACPI-Firmware aufzufordern, das thermische Limit für den Ladevorgang festzulegen. Im Rahmen der _DSM-Steuerungsmethode wird eine GUID definiert, um das thermische Limit anzugeben.

Argumentnummer	Wert	Beschreibung
Arg0	4c2067e3-887d-475c-9720-4af1d3ed602e	UUID
Arg1	0	Revision
Arg2	1	Funktion
Arg3	Ganzzahliger Wert zwischen 0 und 100	Thermisches Limit für Akkuladevorgänge. Entspricht dem berechneten Prozentsatz für die passive Drosselung.
Rückgabewert	Nicht zutreffend	Kein Rückgabewert

Aktive Kühlung

Aus Sicht des Betriebssystems verfügt eine Plattform über zwei Strategien, die sie zum Implementieren der Lüftersteuerung verwenden kann:

• Implementieren von einer oder mehreren thermischen ACPI-Zonen mit aktiven Auslösepunkten zum Einschalten bzw. Ausschalten des Lüfters

  Das Windows-Framework für Wärmemanagement unterstützt aktive Kühlgeräte auf einer sehr grundlegenden Stufe. Die einzige von Geräten unterstützte Inbox ist ein ACPI-Lüfter, der nur mit Ein/Aus-Signalen gesteuert werden kann.

• Implementieren einer proprietären Lösung zum Steuern des Lüfters (über Treiber, einen eingebetteten Controller usw.)

  Windows steuert zwar nicht das Verhalten von proprietären Lösungen für Lüfter, unterstützt jedoch Lüfterbenachrichtigungen für Wärme-Manager für alle Implementierungen einschließlich eingebetteter Controller, sodass Diagnoseinformationen und Telemetriedaten gesammelt werden können. Daher ist das Spezifizieren von Lüftern für das Betriebssystem bei allen Modern-Standby-PCs erforderlich und wird für alle anderen dringend empfohlen.

Beachten Sie, dass die Implementierung für die aktive Kühlung vollständig von der zuvor erläuterten passiven Kühlungskorrekturmaßnahme getrennt ist.

Lüftersteuerung durch thermische ACPI-Zonen

Windows unterstützt die auf dem ACPI 1.0-D-Status basierende Lüfterdefinition. (Weitere Informationen finden Sie in der ACPI-Spezifikation.) Daher ist die Steuerung auf das Einschalten und Ausschalten des Lüfters beschränkt. Der Treiber für den Lüfter wird im Windows-ACPI-Treiber (Acpi.sys) bereitgestellt.

1. Der Temperatursensor erkennt, dass die Temperatur einen Auslösepunkt überschritten hat und gibt „Notify(0x80)“ für die zugeordnete thermische Zone aus.
2. Die thermische Zone misst die Temperatur mit der _TMP-Steuerungsmethode und vergleicht sie mit den aktiven Auslösepunkten (_ACx), um zu entscheiden, ob der Lüfter ein- oder ausgeschaltet sein soll.
3. Das Betriebssystem platziert das Lüftergerät in D0 oder D3, wodurch der Lüfter ein- oder ausgeschaltet wird.

Das folgende Blockdiagramm zeigt den Steuerungsablauf für einen Lüfter, der von einer thermischen ACPI-Zone gesteuert wird.

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

Lüfter mit mehreren Drehzahlstufen in der ACPI

Um mehrere Drehzahlstufen für einen Lüfter mit ACPI 1.0 zu erreichen, gibt es zwei Optionen:

• Die thermische Zone kann mehrere „Lüfter“ umfassen, wenn nur ein physischer Lüfter vorhanden ist. Wenn mehrere „Lüfter“ gleichzeitig eingeschaltet sind, ist die Lüfterdrehzahl höher. Weitere Informationen finden Sie im Beispiel für diese Option im Abschnitt 11.7.2 in der ACPI 5.0-Spezifikation.
• Wenn der Lüfter eingeschaltet ist, kann er die Drehzahl selbstständig bestimmen. Systeme mit eingebetteten Controllern können beispielsweise diese Option auswählen.

Proprietäre Lösung für Lüfter

Windows muss in der Lage sein, Lüfteraktivitäten mit jeder Implementierung zu erkennen. Wenn eine Plattform das ACPI-Wärmemodell verwendet, ist Windows für das Ein- und Ausschalten des Lüfters verantwortlich und weiß daher bereits, wann dieser aktiv ist. Wenn eine proprietäre Lösung zum Steuern des Lüfters verwendet wird, benötigt Windows eine Benachrichtigung, dass der Lüfter eingeschaltet ist. Um dies zu aktivieren, unterstützt Windows einen Teil der ACPI 4.0-Lüftererweiterungen, die in der folgenden Tabelle aufgeführt sind.

Funktion	Beschreibung	Unterstützt
_FST	Gibt den Status des Lüfters zurück	ja
Notify(0x80)	Gibt an, dass sich der Status des Lüfters geändert hat	ja
_FIF	Gibt Lüftergeräteinformationen zurück	Nein
_FPS	Gibt eine Liste der Lüfterleistungsstatus zurück	Nein
_FSL	Legt den Lüfterleistungsstatus fest (Drehzahl)	Nein

Windows verwendet das _FST-Objekt, um festzustellen, ob der Lüfter eingeschaltet (Steuerfeld entspricht nicht null) oder ausgeschaltet (Steuerfeld entspricht null) ist. Windows unterstützt auch „Notify(0x80)“ für das Lüftergerät als Hinweis, dass sich der „_FST“ geändert hat und neu bewertet werden muss.

Ein Lüfter, der das _FST-Objekt implementiert, muss nicht in der _ALx-Geräteliste für eine thermische Zone aufgeführt sein, kann jedoch als Option darin enthalten sein. Diese Option ermöglicht eine Hybridlösung, bei der ein Lüfter in der Regel von einem Drittanbietertreiber gesteuert wird, jedoch auch von der thermischen Zone des Betriebssystems gesteuert werden kann, wenn der Drittanbietertreiber nicht installiert ist. Wenn ein Lüfter in einer _ALx-Geräteliste enthalten ist und von der thermischen Zone eingeschaltet wird (platziert in D0), muss das _FST-Objekt einen Steuerungswert angeben, der nicht null entspricht.

Windows verwendet für alle Lüfter den folgenden Algorithmus, um deren Status zu bestimmen:

1. Bei D0 ist der Lüfter (aufgrund der Überschreitung des _ACx-Auslösepunkts einer thermischen Zone) eingeschaltet.
2. Wenn ein Lüfter D3 aufweist und die ACPI 4.0-Erweiterungen nicht unterstützt, ist er ausgeschaltet.
3. Wenn ein Lüfter D3 aufweist und die ACPI 4.0-Erweiterungen unterstützt, überprüft das Betriebssystem das _FST-Steuerungsfeld auf einen Wert, der nicht null entspricht, um festzustellen, ob der Lüfter eingeschaltet ist.

Beispiel 1: Hardwarelüftersteuerung

In diesem Beispiel wird ein Lüfter von einem eingebetteten Controller gesteuert.

1. Der eingebettete Controller entscheidet basierend auf dem eigenen internen Algorithmus, ob der Lüfter ein- oder ausgeschaltet wird.
2. Nach dem Ein- oder Ausschalten des Lüfters gibt der eingebettete Controller „Notify(0x80)“ auf dem Lüftergerät aus.
3. Das Betriebssystem wertet „_FST“ aus und ermittelt den neuen Status des Lüfters.

Das folgende Blockdiagramm zeigt den Steuerungsablauf für einen Lüfter, der von einem eingebetteten Controller gesteuert wird.

Im folgenden ASL-Beispiel wird ein Lüftergerät („FAN“) definiert, das das Betriebssystem über Änderungen des Lüfterstatus informieren kann:

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
}

Beispiel 2: Treiberlüftersteuerung

In diesem Beispiel steuert ein Drittanbietertreiber den Lüfter.

1. Der Treiber entscheidet basierend auf dem eigenen internen Algorithmus, ob der Lüfter ein- oder ausgeschaltet wird.
2. Der Treiber ändert den Status des Lüfters und wertet eine benutzerdefinierte Steuerungsmethode (SFST) auf dem Wärmegerät aus.
3. Die Steuerungsmethode für das Wärmegerät aktualisiert die _FST-Inhalte des Lüftergeräts und gibt „Notify(0x80)“ auf dem Lüftergerät aus.
4. Das Betriebssystem wertet „_FST“ aus und ermittelt den neuen Status des Lüfters.

Das folgende Blockdiagramm zeigt den Steuerungsablauf für einen Lüfter, der von einem Drittanbietertreiber gesteuert wird.

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

Vorhandensein von Lüftern

Eine Plattform gibt an, dass ein Lüfter im System vorhanden ist, indem ein Lüftergerät (PnP ID PNP0C0B) im ACPI-Namespace eingeschlossen wird. Wenn dieses Gerät vorhanden ist, geht Windows davon aus, dass das System über einen Lüfter verfügt. Wenn es nicht vorhanden ist, wird angenommen, dass kein Lüfter integriert ist.

Anleitungen spezifisch für Modern Standby

Das Windows-Framework für Wärmemanagement ist Teil des Kernels und ist in alle Windows-Systemen integriert. Daher gilt das oben genannte Material für alle Computer. Verschiedene Typen von Computern erfordern jedoch zusätzliche Anleitungen, die spezifisch für Modern Standby sind.

Mit Modern Standby wird das Leistungsmodell von Smartphones auf PCs übertragen. Dies ermöglicht eine Nutzung, bei der die Oberfläche sofort ein- bzw. ausgeschaltet werden kann, die Benutzer*innen bei ihren Smartphones erwarten. Durch Modern Standby ist das System wie bei Smartphones immer aktuell und nutzbar, wenn ein geeignetes Netzwerk verfügbar ist. Windows 10 unterstützt Modern Standby auf Low-Power-Plattformen, die bestimmte Windows-Zertifizierungsanforderungen erfüllen.

Modern-Standby-PCs sind hochgradig mobile Geräte mit dünnem und hellem Formfaktor. Darüber hinaus sind Modern-Standby-PCs immer betriebsbereit und im ACPI-S0-Zustand verfügbar. Für eine robuste und zuverlässige Nutzung muss beim gesamten System, also vom mechanischen Design bis hin zur Firmware- und Softwareimplementierung, besonders auf thermische Merkmale geachtet werden. Daher müssen alle Modern-Standby-PCs thermische Anforderungen erfüllen.

Modern-Standby-Anforderungen

Alle Modern-Standby-PCs müssen die folgenden HCK-Tests bestehen:

• Alle Modern-Standby-PCs müssen über mindestens eine thermische Zone verfügen, für die eine kritische Herunterfahrtemperatur (_CRT) definiert ist. Für x86-Systeme wird das Definieren einer kritischen Ruhezustandstemperatur (_HOT) empfohlen, um die Speicherung von Benutzerdaten auszulösen. „_HOT“ muss niedriger sein als „_CRT“, und „_CRT“ sollte niedriger sein als der thermische Fail-Safe-Auslösepunkt der Firmware.
• Jede thermische Zone muss die tatsächliche Temperatur am Sensor übermitteln (_TMP). Beim Test wird eine variierende Workload auf dem PC ausgeführt, und die Temperatur muss sich ändern.

Darüber hinaus wird empfohlen, dass jeder PC mindestens einen Temperatursensor für SoC umfasst.

Anforderungen für die aktive Kühlung

Modern-Standby-PCs, die Lüfter verwenden, müssen die folgenden zusätzlichen Anforderungen erfüllen, die im HCK getestet werden.

• Das Betriebssystem muss wissen, dass ein Lüfter vorhanden ist. Weitere Informationen finden Sie unter Vorhandensein von Lüftern.
• Das Betriebssystem muss jederzeit wissen, ob der Lüfter ein- oder ausgeschaltet ist. Auch während der Leerlaufresilienz im Modern-Standby-Modus muss jede Änderung hinsichtlich der Lüfteraktivität dafür sorgen, dass SoC den Status aktualisiert. Weitere Informationen zum Implementieren von Lüfterbenachrichtigungen finden Sie unter Lüftersteuerung durch thermische ACPI-Zonen.
• Der Lüfter darf nicht eingeschaltet werden, während sich der PC im Modern-Standby-Modus befindet. Bei einer realistischen Workload im Modern-Standby-Modus (also immer wenn der Bildschirm ausgeschaltet ist) darf der Lüfter nicht eingeschaltet werden.

Aus Sicht der Benutzer*innen scheint der PC im Modern-Standby-Modus ausgeschaltet zu sein. Sie erwarten von einem PC im Modern-Standby-Modus, dass sich dieser verhält wie im Energiesparmodus. Dementsprechend nehmen Benutzer*innen an, dass der Lüfter wie bei herkömmlichen PCs während des Energiesparmodus nie eingeschaltet ist. Wenn der Lüfter dann eingeschaltet wird, hören die Benutzer*innen das und/oder spüren die heiße zirkulierende Luft, sodass der Gedanke aufkommt, dass der Computer nicht ordnungsgemäß funktioniert. Daher sollte der Lüfter im Modern-Standby-Modus nicht eingeschaltet werden. Weitere Informationen zum erforderlichen Verhalten finden Sie unter HCK-Testanforderungen für Modern-Standby-PCs.

Diese Anforderungen implizieren, dass die Kühlungsrichtlinie bei eingeschaltetem Bildschirm anders sein muss als bei ausgeschaltetem Bildschirm. Der PC kann die aktive Kühlung verwenden, während der Bildschirm eingeschaltet ist, aber bei ausgeschaltetem Bildschirm darf nur die passive Kühlung genutzt werden. Der aktive Auslösepunkt für den Lüfter ist bei eingeschaltetem Bildschirm möglicherweise viel niedriger als bei ausgeschaltetem Bildschirm. Für die ACPI-Implementierung müsste „_ACx“ beim Aktivieren des Modern-Standby-Modus aktualisiert werden. Stellen Sie bei proprietären Lösungen sicher, dass Sie die Richtlinie im eingebetteten Controller aktualisieren.

Prozessordrosselung

Das PPM kommuniziert die maximale, gewünschte und minimale Leistungsstufe an das PEP. Unter thermischen Drosselungsbedingungen sollte die maximale Leistungsstufe der vom Wärme-Manager angeforderten Drosselungsleistung entsprechen. Das PEP legt dann die elektrische Spannung und Frequenz der CPU basierend auf den PPM-Leistungsstufenanforderungen fest.

Lüftergeräuschsignal

Ab Windows 11 können Geräte ein Lüftergeräuschsignal für die Verwendung bei Ressourcenverwaltungsentscheidungen an das Betriebssystem senden, mit dem Ziel, Benutzer*innen eine leise und nicht durch Wärmegenerierung beeinträchtige Nutzung zu ermöglichen. Mit dieser aktivierbaren Schnittstelle kann die Firmware Lüfterdrehzahlinformationen als Wert zwischen 0 (Lüfter ausgeschaltet) und der maximalen Drehzahl an das Betriebssystem senden, das diese Informationen bei Ressourcenverwaltungsentscheidungen verwenden kann, um das Gerät bei Bedarf herunterzukühlen. Dies bietet zwei wichtige Vorteile:

1. Geräuscharme Nutzung: Lüftergeräusche und heiße ausströmende Luft sind eine wichtige Ursache für die Unzufriedenheit von Benutzer*innen. Dies gilt insbesondere, wenn Benutzer*innen keine starke Lüfteraktivität erwarten (z. B. bei einer geringen Workload auf dem Gerät oder nur im Hintergrund ausgeführten Prozessen).
2. Verbesserte Akkulebensdauer: Höhere Lüfterdrehzahlen führen zu einem höheren Stromverbrauch, was bei Gleichstrom eine schnellere Akkuentladung und bei Wechselstrom einen langsameren Ladevorgang verursacht.

Derzeit kann dieses Signal zum Verwalten von Suchindexaufgaben für die Suche verwendet werden, und es gibt Pläne, zusätzliche Hintergrundaufgaben zu aktivieren, um dieses Signal ebenfalls zu nutzen.

Das folgende Diagramm fasst zusammen, wie das Lüftergeräuschsignal in den Ebenen von der Firmware an die Software gesendet wird.

Funktionsweise von Lüftergeräuschsignalen

ACPI-Schnittstellendetails

Nachfolgend finden Sie die vier Funktionen der gerätespezifischen Methode (Device Specific Method, „_DSM“; UUID: A7611840-99FE-41ae-A488-35C75926C8EB), die zur Unterstützung dieses Features verwendet wird. Informationen zu „_FST“ (Lüfterstatus) finden Sie in Abschnitt 11.3.1.4 der ACPI-Spezifikation und unter Beispiel 1: Hardwarelüftersteuerung im Abschnitt Thermisch verwaltete Geräte.

Das folgende Diagramm fasst den Ablauf der Verwendung dieser Funktionen zusammen.

Das folgende Blockdiagramm zeigt den Steuerungsablauf für einen Lüfter, der von einem eingebetteten Controller gesteuert wird (einschließlich der Notify(0x80)-Steuermethode).

Hinweis

Das Lüftergeräuschsignal steuert nicht die Lüfterdrehzahl, sondern benachrichtigt das Betriebssystem, dass Lüftergeräusche vorhanden sind, sodass CPU-Ressourcen aus Hintergrundaufgaben entfernt werden müssen, um die priorisierten Aufgaben abzuschließen.

Enumerate Functions (Funktion 0)

Damit das Betriebssystem mit der Plattform interagieren kann, muss ein ACPI-Gerät über den Namespace verfügbar gemacht werden. Dieses Gerät muss ein _CID-Objekt umfassen, das „EISAID("PNP0C0B")“ enthält. Der Bereich dieses Geräts muss die folgende _DSM-Definition enthalten, die angibt, welche „_DSMs“ das Gerät unterstützt.

UUID	Revision	Funktion	Beschreibung
A7611840-99FE-41ae-A488-35C75926C8EB	0	0	Aufzählen von Funktionen

Rückgabe: Um die Unterstützung für die oben aufgeführten Funktionen 0 bis 3 anzugeben, sollte die „Enumerate Functions“-Funktion (Funktion 0) den Wert „0xF“ zurückgeben. Weitere Informationen finden Sie in Abschnitt 9.1.1 der ACPI-Spezifikation.

Get Fan Trip Point Support Function (Funktion 1)

Die Hardware teilt dem Betriebssystem mit, welche Drehzahl unterstützt wird.

UUID	Revision	Funktion	Beschreibung
A7611840-99FE-41ae-A488-35C75926C8EB	0	1	Unterstützung im Zusammenhang mit Lüfterauslösepunkten

Argumente

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

Arg1: Revision: 0

Arg2: Funktion: 1

Arg3: Ein leeres Paket

Rückgabe: Ein ganzzahliger Wert, der die für Lüfterauslösepunkte unterstützte Granularität enthält (U/min). Wenn der Wert nicht null entspricht, kann das Betriebssystem Auslösepunkte auswählen, die ein Vielfaches der Benachrichtigungsgranularität sind. Bei einer Granularität von 200 kann das OSPM Auslösepunkte bei 0, 200, 400, 600 usw. U/min auswählen. Der Wert 0 gibt an, dass Auslösepunkte nicht unterstützt werden.

Set Fan Trip Points Function (Funktion 2)

Das Betriebssystem teilt der Hardware den nächsten Benachrichtigungsauslösepunkt mit. Die Hardware benachrichtigt das Betriebssystem, wann dieser erreicht wird.

UUID	Revision	Funktion	Beschreibung
A7611840-99FE-41ae-A488-35C75926C8EB	0	2	Abrufen von Lüfterauslösepunkten

Argumente

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

Arg1: Revision: 0

Arg2: Funktion: 2

Arg3: Ein Paket, das die unteren und oberen Auslösepunkte enthält. (2 Element ganzzahlig; unterer Auslösepunkt bei Index 0 und oberer Auslösepunkt bei Index 1)

Das OSPM wählt nur Auslösepunkte aus, die ein Vielfaches der in Funktion 1 angegebenen Auslösepunktgranularität sind. Wenn die tatsächliche Drehzahl des Lüfters über oder unter den oberen bzw. unteren Auslösepunkten liegt, sollte die Plattform „Notify(0x80)“ auf dem Lüftergerät ausgeben. Das OSPM wertet dann den Lüfterstatus (_FST) aus, um die aktuelle Lüfterdrehzahl zu ermitteln. Wenn sich die Lüfterdrehzahl bei festgelegten Auslösepunkten bereits außerhalb der angegebenen Auslösepunkte befindet, sollte die Plattform sofort „Notify(0x80)“ ausgeben.

Der obere Auslösepunkt ist ein Vielfaches der Granularität. Der untere Auslösepunkt lautet wie folgt: (Vielfaches der Granularität) + 1 (unterer Auslösepunkt < oberer Auslösepunkt). Wenn der Wert für die Drehzahl 0 entspricht, legt das Betriebssystem den unteren Auslösepunkt auf 0 und den oberen Auslösepunkt auf 1 fest.

Rückgabe: Keine Rückgabe.

Get Fan Operating Ranges Function (Funktion 3)

Zuordnung zwischen Drehzahl und Auswirkung. Beachten Sie, dass nur ein Lüfter (Lüfter, der SoC am nächsten ist) diese Schnittstelle implementieren kann. Er muss alle drei Funktionen plus Funktion 0 aus Abschnitt 9.1.1 der ACPI-Spezifikation implementieren.

UUID	Revision	Funktion	Beschreibung
A7611840-99FE-41ae-A488-35C75926C8EB	0	3	Abrufen der Lüfterbetriebsbereiche

Argumente

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

Arg1: Revision: 0

Arg2: Funktion: 3

Arg3: Ein leeres Paket

Rückgabe: Ein Paket mit dem folgenden Format:

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

Feld	Format	Beschreibung
Impact1MaxRPM	Integer (DWORD)	Maximale Drehzahl für Lüfterwirkungsbereich 1
Impact2MaxRPM	Integer (DWORD)	Maximale Drehzahl für Lüfterwirkungsbereich 2. Muss >= „Impact1MaxRPM“ sein.
Impact3MaxRPM	Integer (DWORD)	Maximale Drehzahl für Lüfterwirkungsbereich 3. Muss >= „Impact2MaxRPM“ sein.
MaxRPM	Integer (DWORD)	Maximale Drehzahl, mit der der Lüfter betrieben werden kann. Muss >= „Impact3MaxRPM“ sein.

Diese Tabelle wird verwendet, um den Drehzahlbereich für die einzelnen Lüfterwirkungsstufen abzuleiten:

Wirkungsgrad	Unterer Drehzahlwert	Oberer Drehzahlwert
1	1	Impact1MaxRPM
2	Impact1MaxRPM + 1	Impact2MaxRPM
3	Impact2MaxRPM + 1	Impact3MaxRPM
4	Impact3MaxRPM + 1	MaxRPM

Wenn ein Wirkungsbereich von einer Plattform nicht verwendet wird (beispielsweise wenn der Lüfter direkt von Wirkungsbereich 2 zu Wirkungsbereich 4 übergeht), kann dies angegeben werden, indem die Maximaldrehzahl für den nicht verwendeten Wirkungsbereich der Maximaldrehzahl für den unteren Wirkungsbereich gleichgesetzt wird.

Beispielzuordnung

An Betriebssystem gesendeter Wert	Lüfterdrehzahl	Benutzererfahrung	Drehzahlobergrenze
0 – Niedrig	1–4000 U/min (<= 25 dBA)	Lüfter nicht eingeschaltet oder eingeschaltet mit niedrigem Geräuschpegel	Impact1MaxRPM = 4000
1 – Mittel	4001–5000 U/min (25–30 dBA)	Lüfter eingeschaltet mit mittelmäßigem Geräuschpegel	Impact2MaxRPM = 5000
2 – Mittel bis Hoch	5001–6000 U/min (30–36 dBA)	Lüfter eingeschaltet mit mittlerem bis hohem Geräuschpegel	Impact3MaxRPM = 6000
3 – Hoch	6001+ U/min (36+ dBA)	Lüfter eingeschaltet mit hohem Geräuschpegel	MaxRPM = 9000

ASL-Beispielcode

    ...
 
    // _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
}

Testen und Ablaufverfolgung

Führen Sie die folgenden Schritte aus, um ein Protokoll zu erstellen und in Windows Performance Analyzer anzuzeigen:

1. Navigieren Sie zu „Windows Search-Einstellungen“ > „Windows durchsuchen“ > „Erweiterte Suchindexeinstellungen“ > „Erweitert“ > Löschen und Neuerstellung des Index („Neu erstellen“).
2. wpr -boottrace -addboot AcpiFanNoiseImpact.wprp –filemode
3. Führen Sie einen Neustart des Systems durch.
4. Überprüfen Sie den Indizierungsstatus der Einstellungen, und navigieren Sie zu „Windows durchsuchen“ (dabei Netzbetrieb sicherstellen).
5. Wenn die Indizierung abgeschlossen ist, beenden Sie die Ablaufverfolgung: wpr -boottrace -stopboot AcpiFanNoiseImpact.etl (Abbrechen der Ablaufverfolgung ohne Speichern: wpr -boottrace –cancel).
6. Öffnen Sie „AcpiFanNoiseImpact.etl“ über Windows Performance Analyzer (WPA).

Laden Sie die Datei unter AcpiFanNoiseImpact.zip herunter, oder kopieren Sie Folgendes, und speichern Sie die Datei unter 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>

Die folgende Abbildung zeigt einen WPA-Beispielgraphen, der veranschaulicht, wie die Suchindexprozesse abnehmen, wenn der Lüfter laut ist.

Es gibt eine Lüfterstufe, bei der die Suchindexprozesse vollständig ausgesetzt werden (höchste Stufe, also Wirkungsgrad 4). Bei allen anderen Lüfterstufen sollte die Aktivität nur reduziert und nicht vollständig ausgesetzt werden. Wenn die ACPI in Funktion 3 (Get Fan Operating Ranges Function) beispielsweise Impact3MaxRPM = 4000 U/min deklariert hat und die Lüfterdrehzahl > 4000 (4100 U/min, 4500 U/min) entspricht, wird die CPU-Nutzung für „SearchIndexer.exe“ und „SearchProtocolHost.exe“ ausgesetzt.

Hinweis

Wenn Sie die CPU-Auslastung ermitteln möchten, können Sie wpr -start power -filemode verwenden, um Daten zur Laufzeitnutzung zu sammeln. Verwenden Sie wpr -stop fan_noise.etl, um das Erfassen von Protokolldateien zu beenden.

Die folgende Abbildung zeigt einen WPA-Beispielgraphen, der die Aussetzung von „SearchIndexer.exe“ und „SearchProtocolHost.exe“ veranschaulicht.