Руководство по проектированию

В этом руководстве по проектированию управления температурой компьютеров содержатся сведения о том, как определить значения температуры компьютера, которые являются "слишком горячими" и "слишком холодными".

Принятие этих решений является ключевым требованием для проектирования, который обеспечивает хороший пользовательский интерфейс компьютера. Кроме того, эти пороговые значения помогают выбрать первое действие по устранению рисков для компонентов КОМПЬЮТЕРА, которые находятся в нескольких тепловых зонах.

Проектирование пороговых значений температуры

Переменные и предположения

На температурное поведение компьютера влияют следующие факторы:

• Проектирование оборудования

  Важность хорошего проектирования оборудования нельзя переоценить. Дополнительные сведения см. в разделе Аппаратное тепловое моделирование и оценка.

• Среда

  Это внешние факторы, влияющие на тепловое поведение системы. Программное обеспечение может влиять на среду, только уведомив пользователя о проблеме с тепловыми ограничениями, например, отображая логотип "Сбой при загрузке". Пользователь должен перейти в другую среду, чтобы изменить следующие факторы:

  • Солнечное излучение

    Интенсивность и угол солнечного света, влияющего на экран или любую часть системы.

  • температура окружающей среды;

    Температура среды.

  • Воздушный поток

    С циркуляцией воздуха или без нее. Ветреный или в компьютерном корпусе.

  • влажность.

    Сухой или влажный.

• Рабочая нагрузка и энергопотребление

  Предполагается, что рабочая нагрузка и энергопотребление пропорциональны друг другу. Другими словами, чем больше работы выполняет компьютер или компонент, тем больше энергии он потребляет и тем больше тепла он генерирует. Хотя это может быть не так во всех случаях, упрощенная модель здесь более или менее достаточна. Именно здесь можно идти по устранению рисков программного обеспечения. Уменьшая рабочую нагрузку, уменьшается тепло, и компьютер продолжает работать.

При проектировании и моделировании оборудования учитывайте параметры, упомянутые в предыдущем списке. Используйте значения в наихудшем регистре для среды. Единственным параметром, который может напрямую управляться программным обеспечением, является рабочая нагрузка.

Основы температуры

Учитывайте тепловое поведение компьютера при выполнении постоянной рабочей нагрузки. При запуске рабочей нагрузки аппаратные компоненты компьютера, такие как ЦП и GPU, генерируют тепло и повышают температуру. По мере увеличения температуры относительно температуры окружающей среды компьютер начинает быстрее рассеивать тепло до тех пор, пока в конечном итоге теплогенерация не будет равна рассеяние тепла, и температура не достигнет устойчивого состояния. В течение всего периода этой постоянной рабочей нагрузки, так как регулирование не применяется, производительность и пропускная способность являются постоянными.

На следующей схеме показана связь между выработкой тепла, температурой и производительностью при отсутствии регулирования. Обратите внимание, что температура компьютера остается в пределах тепловой оболочки, ограниченной температурой окружающей среды и температурой регулирования.

Теперь рассмотрим температурное поведение компьютера при выполнении другой рабочей нагрузки, которая также является постоянной, но более ресурсоемкой. По мере выполнения этой рабочей нагрузки генерируемое тепло гораздо выше, чем то, что система способна рассеивать в окружающую среду, и в результате температура постоянно повышается. Без пассивного охлаждения температура будет продолжать расти, пока в конечном итоге система не станет слишком горячей и негативно повлияет на комфорт и безопасность конечных пользователей. Оборудование также может быть повреждено при высоких температурах. Тепловое регулирование помогает гарантировать, что компьютер не достигнет этих высоких температур. При повышении температуры над предварительно определенной точкой поездки температуры регулирования система начинает регулирование производительности. В результате тепловая выработка уменьшается и постепенно — после выравнивание тепла и рассеяния — температура системы достигает устойчивого состояния.

На следующей схеме показана связь между генерацией тепла, температурой и производительностью при регулировании производительности для уменьшения генерации тепла.

В обоих случаях, показанных на предыдущих схемах, рабочие нагрузки должны работать в рамках тепловой оболочки, чтобы гарантировать, что температура системы не превышает безопасные пределы. Конверт начинается с температуры окружающей среды и заканчивается температурой регулирования. Кроме того, в обоих случаях теплогенерация и рассеяние в конечном итоге достигают сбалансированного состояния, а температура системы стабилизируется.

Определение теплового конверта

Хорошо спроектированный компьютер должен иметь как можно большую тепловую оболочку, обеспечивая пользователям длительный и свободный от устранения рисков интерфейс. Как показано на предыдущих схемах, тепловая оболочка имеет нижнюю границу, определяемую температурой окружающей среды. Он ограничен выше температурой регулирования. Хотя температура окружающей среды не является переменной, которую могут контролировать разработчики систем, верхняя граница может быть выше благодаря хорошей конструкции оборудования. Дополнительные сведения см. в разделе Аппаратное тепловое моделирование и оценка. Но даже при условии, что оборудование не является основным ограничением, при определении тепловой оболочки необходимо учитывать и другие важные факторы.

Требуемый рабочий диапазон должен быть как можно больше без ущерба для этих ограничивающих факторов:

• Безопасность

  Температура системы должна сначала убедиться, что пользователи не пострадали от использования системы. Это требование относится в основном к датчику температуры кожи.

• Защита оборудования

  Температура должна предотвращать "таяние" компонентов системы или иным образом причинять ущерб из-за тепла. Это требование относится в основном к датчикам температуры компонентов, например датчику, который находится поверх процессора.

• Государственное регулирование

  Все системы должны соответствовать применимым отраслевым стандартам (например, IEC 62368) в отношении безопасности бытовой электроники.

Аппаратное тепловое моделирование и оценка

Программное обеспечение в качестве дополнения к проектированию оборудования

При проектировании оборудования важно учитывать управление температурой. Выбор маломощных деталей, размещение горячих компонентов далеко друг от друга и включение теплой изоляции — лишь несколько примеров того, как оборудование может значительно улучшить тепловую работу. Эти методы не могут быть заменены в программном обеспечении. Таким образом, программное решение служит только дополнением к проектированию оборудования в общей тепловой среде.

Цель оборудования

Для выполнения типичных рабочих нагрузок не требуется какая-либо форма защиты от температуры программного обеспечения. Аппаратная тепловая конструкция должна самостоятельно распределять тепло для этих рабочих нагрузок.

Моделирование

Моделирование — это итеративный процесс для достижения ранее описанной цели оборудования. В этом процессе не следует учитывать какие-либо меры по устранению рисков программного обеспечения. Полагайтесь исключительно на аппаратные возможности и при необходимости настраивайте их.

1. Определите типичную рабочую нагрузку. В зависимости от платформы системы ( от телефона до сервера) каждая система должна иметь стандартный набор типичных рабочих нагрузок. Это не должны быть интенсивные рабочие нагрузки, такие как видеоконференция в формате HD, а более средняя нагрузка, например просмотр веб-страниц или прослушивание музыки.

2. Модель системы и отдельных компонентов энергопотребление для типичных рабочих нагрузок, так как тепло не будет равномерно распределяться по корпусу. Обратите особое внимание на компоненты, которые потребляют большую часть энергии, например процессор.

3. На основе оценки энергопотребления рабочей нагрузки смоделируют рост температуры компонентов и кожи с течением времени.

4. Настройте механическую конструкцию системы, чтобы убедиться, что температура компонентов находится в пределах предела безопасности оборудования и предела комфорта пользователя по сравнению со всеми температурами окружающей среды. Ниже приведены некоторые методы решения проблем с механическим проектированием.

   1. Улучшайте возможности теплоотдачи, добавляя более качественные теплопроводящие материалы.
   2. Увеличьте разностную температуру между кожей и внутренней температурой, добавив слои изоляции.

5. Повторяйте шаги 1–4, пока не будет выполнено.

6. Создайте оборудование и оцените его.

Ознакомительная версия

Для каждой редакции оборудования необходимо выполнить измерение температуры и мощности для репрезентативных рабочих нагрузок, чтобы оценить тепловое поведение, и механический дизайн должен быть изменен по мере необходимости.

Для выполнения такой тепловой оценки рекомендуется выполнить следующие действия.

1. Определите матрицу тестового измерения температуры:

   1. Матрица должна охватывать как нормальную, так и максимальную температуру окружающей среды.
   2. Матрица должна включать все типичные рабочие нагрузки, определенные как часть теплового моделирования, и для каждой рабочей нагрузки данные должны собираться не менее одного часа.
   3. Матрица должна выполняться на нескольких компьютерах несколько раз, чтобы получить согласованные результаты.

2. Для каждой рабочей нагрузки, определенной в тестовой матрице, запишите следующие данные:

   1. Данные о энергопотреблении системы и компонентов.
   2. Данные о температуре окружающей среды, внутренних компонентов и кожи.
   3. Программные трассировки для обнаружения теплового регулирования, метрик производительности и использования процессора.

Данные температуры кожи и компонентов напрямую указывают максимальную температуру кожи, которую может достичь система, и является ли эта температура приемлемой. Подумайте, сколько теплового запаса может иметь система до критического завершения работы. Данные метрик производительности помогут определить, обеспечивает ли система необходимую производительность. Данные трассировки, записанные программным обеспечением для регулирования температуры, показывают процент теплового регулирования. Данные о энергопотреблении и данные об использовании ЦП могут помочь определить, какие факторы влияют на изменение температуры.

В следующей таблице приведен пример такого сбора данных для компьютера со следующей конфигурацией:

Конфигурация

• Имя компьютера: Thermal-Test-1
• Средняя температура окружающей среды: 23^oC
• Точка поездки в тепловой зоне (_PSV): 80^oC

Платформа управления температурой Windows

Платформа управления температурой Windows предоставляет комплексное решение для программного управления температурой. В следующих примерах показано, как реализовать управление температурой. При надлежащем тепловом моделировании, проверке и эффективном тепловом механическом проектировании все системы должны обеспечить бесперебойную работу пользователей на большинстве рабочих нагрузок при наиболее целевых температурах окружающей среды. Если требуется устранение температуры, Windows предоставляет эффективную и расширяемую архитектуру управления температурой.

Управление температурой Windows поддерживает активное и пассивное охлаждение. При активном охлаждении вентиляторы активируются для циркуляции воздуха и помогают охладить систему. Благодаря пассивному охлаждению устройства снижают производительность устройства в ответ на чрезмерные температурные условия. Снижение производительности снижает энергопотребление и, таким образом, генерирует меньше тепла.

Платформа управления температурой Windows использует политики, заданные конструкторами систем, для применения управления температурой в системе. На высоком уровне разработчики должны указать, как на показания, полученные с каждого теплового датчика, влияет каждый компонент. Без этих спецификаций Windows не может управлять системой с температурой. Таким образом, каждый конструктор системы обязан характеризовать свою систему теплительно для достижения хорошего теплового дизайна.

Хотя системам не требуется использовать платформу управления температурой Windows, это рекомендуемое решение из-за тесной интеграции с операционной системой. Однако независимо от используемого решения по управлению температурой все современные резервные компьютеры должны соответствовать требованиям HCK для целей диагностики.

Архитектура управления температурой

Архитектура управления температурой Windows основана на концепции ACPI тепловых зон. Модель тепловой зоны ACPI требует взаимодействия между встроенным ПО, операционной системой и драйверами. Эта модель абстрагирует датчики и устройства охлаждения от центрального компонента управления температурой с помощью четко определенных интерфейсов. Усовершенствования управления температурой основаны на главе 11 спецификации ACPI 5.0. Платформа управления температурой Windows реализует подмножество возможностей, описанных в этой главе.

Ниже перечислены основные компоненты модели.

• Определения тепловой зоны платформы, описанные в Windows через встроенное ПО. Тепловая зона — это абстрактная сущность, которая имеет связанное значение температуры. Операционная система отслеживает эту температуру, чтобы она ей можно было применять термозащиту к устройствам в зоне. Зона содержит набор функциональных устройств, которые генерируют тепло, и подмножество устройств, выработкой тепла которых можно управлять путем настройки производительности.
• Датчик температуры, представляющий температуру региона. Датчик должен реализовать интерфейс "Температура чтения" для получения температуры зоны из встроенного ПО или драйвера температуры Windows.
• Интерфейс теплового охлаждения, позволяющий драйверам устройств в тепловых зонах реализовывать действия пассивного охлаждения. Каждый управляемый драйвер должен иметь интерфейс охлаждения для участия в тепловой инфраструктуре Windows.
• Централизованный диспетчер температуры , который управляет охлаждением путем интерпретации определений тепловой зоны и вызова интерфейсов в требуемое время. Диспетчер температуры реализован в ядре Windows и не требует работы со стороны разработчиков систем.

На следующей блок-схеме представлен обзор архитектуры управления температурой Windows. Main компонентами являются тепловой диспетчер, тепловая зона, управляемые драйверы и датчик температуры. Тепловая зона определяет поведение регулирования управляемых устройств на основе ограничений, предоставляемых диспетчером температуры. Алгоритм, используемый диспетчером температуры, использует показания температуры датчика для тепловой зоны в качестве входного параметра.

Тепловые зоны в системе должны быть описаны в встроенном ПО ACPI и предоставляться диспетчеру температуры через ACPI. Используя сведения о конфигурации, диспетчер температуры знает, сколько тепловых зон необходимо управлять, когда начинать регулирование каждой тепловой зоны и какие устройства являются частью зоны. Для мониторинга температуры конструктор систем обеспечивает поддержку в встроенном ПО ACPI для уведомлений о температуре.

Когда диспетчер температуры получает уведомление о тепловом событии в перечисляемой зоне, он начинает периодически оценивать температуру зоны и определять процент производительности теплового регулирования, применяемый к устройствам в тепловой зоне. Эта оценка выполняется с помощью алгоритма теплового регулирования, который описан в спецификации ACPI. Затем диспетчер температуры уведомляет все устройства в зоне о регулировании производительности на определенный процент, а драйверы устройств преобразуют процент регулирования в действие конкретного класса устройства, чтобы снизить производительность. Периодическая оценка и регулирование прекратятся, когда температура тепловой зоны падает ниже пороговой температуры регулирования и больше регулирование не требуется.

Цикл обратной связи

Еще один способ думать об архитектуре управления температурой — с точки зрения входных данных, директора политики и управляемых устройств. На следующей блок-схеме входными данными для цикла обратной связи являются температура и электрический ток. Эти входные данные используются для определения реализуемой политики температуры. Диспетчер температуры зависит исключительно от входных данных температуры, и драйвер политики может использовать любые входные данные. Затем тепловая зона применяет политику к управляемым драйверам. После применения политики датчики обновят свои значения и закроют цикл.

На следующей блок-схеме показаны три этапа модели теплового отклика. Входные данные от датчиков температуры и электрического тока предоставляют сведения, помогающие определить, какую тепловую политику следует применить. Эта политика применяется к управляемым драйверам, что затем влияет на показания датчиков. Процесс повторяется в цикле обратной связи.

Обязанности разработчиков системы

Как упоминалось выше, для полноценного теплового решения Windows требуется ряд компонентов. Архитектура тепловой платформы специально разработана таким образом, чтобы можно было разделить обязанности поставщика оборудования и системного интегратора.

Для реализации партнерами необходимы следующие компоненты:

• Датчики

  Драйверы датчика температуры должны предоставляться поставщиком оборудования. Учитывая, что датчики температуры не нуждаются в знаниях о тепловых зонах, которые от них зависят, их функциональные возможности должны быть стандартными для различных конструкций платформ. За пользовательские датчики для драйверов политик, например текущие датчики, также отвечает поставщик оборудования.

• Тепловые зоны

  Тепловые зоны могут быть определены поставщиком оборудования и /или системным интегратором. Все системы должны иметь по крайней мере одну тепловую зону, которая реализует критическую температуру выключения (и температуру гибернации, если она поддерживается), что может сделать поставщик оборудования или системный интегратор. Однако для других тепловых зон, которые отслеживают определенные устройства или температуру кожи для устранения рисков, системный интегратор обычно имеет более конкретные знания о тепловом поведении системы. Таким образом, эти тепловые зоны обычно реализуются системным интегратором.

• Интерфейс теплового охлаждения для драйверов устройств

  Разработчик, который создает драйвер для устройства, которое должно управляться тепликом, также должен реализовать интерфейс охлаждения. Драйвер устройства использует этот интерфейс для включения в платформу управления температурой. Драйверы устройств обладают специальными знаниями о возможностях своих устройств. Эти же драйверы должны реализовать интерфейс теплового охлаждения, чтобы он смог правильно интерпретировать действия, запрашиваемые тепловой зоной.

Датчики

Датчики предоставляют входные данные для определения того, какой должна быть тепловая политика. Windows поддерживает только датчики температуры в качестве входных данных для диспетчера температуры. Однако драйвер политики может дополнительно принимать входные данные от пользовательских драйверов, таких как текущий драйвер датчика.

Датчик температуры

Датчик температуры предоставляет следующие режимы функциональности:

• Непрерывно отслеживает изменения температуры без участия теплового диспетчера или тепловой зоны.
• Уведомляет диспетчер температуры, когда температура превышает пороговое значение, определенное _PSV, _HOT или _CRT.
• Отвечает на запросы температуры и возвращает текущее значение температуры.

На следующей схеме показано, как работает мониторинг температуры во время регулирования. Встроенное ПО ACPI или драйвер датчика температуры должны уведомлять диспетчер температуры, когда температура достигает предопределенного порогового значения, например _PSV, _HOT или _CRT, а затем отвечать на периодические запросы от диспетчера температуры для текущей температуры. Период запроса температуры определяется _TSP.

Чтобы диспетчер температуры всегда уведомлялся о превышении порогового значения температуры, прерывание датчика температуры должно всегда поддерживать пробуждение (даже если система находится в режиме современного режима ожидания и soC находится в низком энергопотреблении). Если прерывание датчика температуры не всегда поддерживает пробуждение, то, по крайней мере, прерывание должно быть настроено как триггер уровня, чтобы избежать потенциальных прерываний.

Датчик температуры может использоваться несколькими тепловыми зонами, хотя в тепловой зоне может быть не более одного датчика.

Рекомендуется, чтобы оборудование датчика было точным до +/- 2^oC.

Температура, сообщаемая _TMP или драйвером датчика температуры, может быть фактическим значением датчика или экстраполированным значением на основе нескольких датчиков.

Обычно это предоставляется поставщиком оборудования. Windows поддерживает две реализации мониторинга температуры:

• Драйвер датчика температуры
• На основе ACPI

Реализация 1. Драйвер датчика температуры

Драйвер датчика температуры просто сообщает температуру датчика. Водитель ACPI выдаст один неоплаченный IOCTL с драйвером датчика, чтобы обнаружить пересечение одной из точек поездки. Кроме того, ACPI может выдать один IOCTL без времени ожидания для чтения текущей температуры. Драйвер датчика должен обрабатывать отмену прочитанного IOCTL, если он отменен во время ожидания истечения времени ожидания. Датчик температуры должен реализовать следующий интерфейс:

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)

В следующей таблице описаны входные и выходные параметры для интерфейса чтения температуры.

Один датчик температуры может использоваться для одной тепловой зоны или нескольких тепловых зон. Чтобы указать, какой датчик температуры следует использовать для тепловой зоны, необходимо указать тепловой _DSM в тепловой зоне и реализовать функцию 2. (Для обратной совместимости драйвер датчика температуры можно загрузить поверх стека тепловой зоны. Однако предпочтительнее реализовать драйвер датчика отдельно от стека тепловой зоны.) Этот _DSM определяется следующим образом:

АргументыArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 2 Arg3: A empty package Return A single Reference to the device that will return the temperature of the thermal zone.

Тепловая зона также должна указывать зависимость от устройства датчика температуры с _DEP. Ниже приведен простой пример _DSM реализации устройства датчика.

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.

}

Дополнительные сведения см. в разделе Метод для тепловых расширений Майкрософт для конкретного устройства.

Реализация 2. На основе ACPI

Встроенное ПО ACPI должно поддерживать _TMP и уведомлять 0x80, как определено в спецификации ACPI. Преимущество этого подхода заключается в том, что для него не требуется устанавливать в системе дополнительные драйверы. Однако этот подход ограничивается взаимодействием с ресурсами, доступными через регионы операций ACPI.

Управление политикой температуры

Тепловая зона

Тепловая зона — это отдельный объект терморегулирования. Он имеет собственные характеристики теплового регулирования, такие как точки поездки, регулирование частоты выборки и константы уравнения регулирования. Одна тепловая зона может включать несколько устройств регулирования температуры, каждое из которых может способствовать повышению температуры в тепловой зоне. Все устройства в одной тепловой зоне должны следовать тем же ограничениям, которые применяются к тепловой зоне.

Чтобы обеспечить точное определение тепловых зон и их параметров, разработчики систем должны:

• Определите горячие точки в корпусе системы и определите, как эти горячие точки рассеивают тепло на датчики температуры. (В идеале, тепловые датчики сидят в горячих точках системы, за исключением датчиков температуры кожи.)
• Охарактеризуйте отношение температуры системы. Сопоставьте показания датчика температуры с температурой компонента и температурой кожи.

Порог превышения

Начиная с Windows 10, в управление температурой Windows была введена новая функция, называемая состоянием тепловой зоны, а также одно состояние: overthrottled. Если тепловая зона превышает уровень регулирования устройства, диспетчер температуры уведомит компоненты операционной системы о том, что система перегружена. Это уведомление позволяет системе уменьшить рабочую нагрузку для улучшения теплового состояния.

Диспетчер температуры поддерживает глобальное количество тепловых зон, которые находятся в состоянии превышения скорости. Когда счетчик увеличивается выше нуля (0), диспетчер температуры отправляет системе уведомление windows Notification Facility (WNF), указывающее, что оно перегружено. Когда число зон с превышением скорости возвращается к нулю (0), диспетчер температуры отправляет системе еще одно уведомление WNF, указывая на отсутствие перегруженных зон.

Чтобы указать порог превышения скорости для тепловой зоны, в тепловой зоне необходимо указать тепловой _DSM с реализацией функции 3. Этот _DSM определяется следующим образом:

АргументыArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 3 Arg3: Пустой пакет Возвращает целочисленное значение с текущим пороговым значением превышения, выраженным в процентах.

Ниже приведен пример _DSM, который указывает, что зона перегружена на уровнях регулирования от 0% до 49 %.

 ThermalZone (TZ4) {
    Name (_HID, "QCOM24AE")
    Name (_UID, 0)
    Name(_TZD, Package (){\_SB.CPU4, \_SB.CPU5, \_SB.CPU6, \_SB.CPU7})
    Method(_PSV) { Return (3530) }
       Name(_TC1, 1)
       Name(_TC2, 1)
       Name(_TSP, 1)
       Name(_TZP, 0)
       // _DSM - Device Specific Method
       // Arg0: UUID Unique function identifier
       // Arg1: Integer Revision Level
       // Arg2: Integer Function Index (0 = Return Supported Functions)
       // Arg3: Package Parameters
       Method(_DSM, 0x4, NotSerialized) {
          Switch (ToBuffer(Arg0)) {
             Case (ToUUID("14d399cd-7a27-4b18-8fb4-7cb7b9f4e500")) {
                Switch (ToInteger(Arg2)) {
                   Case(0) {
                      // _DSM functions 0 and 3 (bits 0 and 3) are supported
                      Return (Buffer() {0x9})
                   }
                   Case (3) {
                      Return (50)  // overthrottled below 50%
                   }
                }
             }
          }
       }
 } // end of TZ4

Порог превышения будет повторно считываться при получении уведомления (0x81) в ссылке на температурную зону.

Реализация объектов ACPI

В следующей таблице перечислены все объекты ACPI, которые необходимо реализовать в встроенном ПО ACPI для определения тепловой зоны.

Минимальное ограничение регулирования

Минимальное ограничение регулирования — это метод _DSM расширения температуры Майкрософт, который создает нижнюю границу для _PSV, запрошенных для регулируемых устройств. Другими словами, он определяет, насколько тепловая зона ограничивает производительность устройств, которые она контролирует. При наличии минимальное _DSM регулирования будет считываться при загрузке и каждый раз, когда тепловая зона получает уведомление ACPI (0x81). При каждой итерации пассивного алгоритма охлаждения для вычисления изменения предела производительности (DP), применяемого диспетчером температуры к устройствам в зоне, используется следующее:

DP [%] = _TC1 × (Tn – Tn₋₁) + _TC2 × (Tn – Tt). Затем для вычисления фактического предела производительности используется следующее:

Pn = Pn₋₁ – DP При реализации минимального ограничения регулирования (MTL) это второе уравнение изменяется на:

Pn = max(Pn₋₁ – DP, MTL) Чтобы указать минимальное ограничение регулирования для тепловой зоны, необходимо указать тепловой _DSM в тепловой зоне с реализацией функции 1. Этот _DSM определяется следующим образом:

АргументыArg0: UUID = 14d399cd-7a27-4b18-8fb4-7cb7b9f4e500 Arg1: Revision = 0 Arg2: Function = 1 Arg3: Пустой пакет Возвращает целочисленное значение с текущим минимальным ограничением регулирования, выраженным в процентах.

Ниже приведен простой пример для _DSM ограничения регулирования не менее 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)
                    }
                }
            }
        }
    }

Диспетчер температуры в ядре

Диспетчер температуры Windows реализуется как часть ядра Windows. Он отслеживает температуру всех тепловых зон и применяет тепловое регулирование соответствующим образом.

Каждый раз, когда диспетчер температуры запрашивает у драйвера ACPI текущую температуру, он будет выполнять вычисление того, какой процент производительности теплового регулирования должен применяться ко всем устройствам теплового регулирования в тепловой зоне. Тепловой предел вычисляется и применяется при превышении порогового значения пассивного охлаждения (_PSV) и при каждом интервале выборки температуры (_TSP) до тех пор, пока температура не будет охладится ниже нее, а тепловой предел не вернется к 100 процентам. Оборудование должно обнаруживать превышение _PSV и сообщать об этом с помощью уведомления о событии ACPI оборудования.

Алгоритм теплового регулирования

Алгоритм теплового регулирования использует следующее уравнение, определенное в спецификации ACPI:

DP [%] = _TC1 × ( Tn – Tn₋₁ ) + _TC2 × (Tn – Tt), где

Tn = текущее показания температуры датчика температуры в тепловой зоне в десятых градуса Кельвина. Tn₋₁ = температура из предыдущего считывания. Tt = целевая температура в десятых градуса Кельвина (_PSV). DP = требуется изменение производительности. Это линейное значение в диапазоне от 0 (полностью отрегулированное) до 100 процентов (без регулирования), которое применяется к каждому устройству охлаждения в зоне. Это уравнение описывает цикл обратной связи между изменениями температуры и производительностью регулирования. В каждой итерации цикла разница температуры между текущим и предыдущим показаниями температуры требует снижения производительности P на процент DP. Значение DP — это величина применяемого теплового регулирования . Многие устройства охлаждения не имеют линейной тепловой реакции на устранение рисков охлаждения. На этих устройствах предел температуры является подсказкой для устройства, указывающей, сколько требуется охлаждения. Каждое устройство охлаждения будет иметь собственное сопоставление этого линейного значения с определенными для устройства тепловыми меры. Производительность устройства регулирования снижает энергопотребление и выработку тепла, что приводит к снижению температуры.

Две константы, _TC1 и _TC2, управляют тем, как интенсивно применяется тепловое регулирование в этом цикле обратной связи. Чем больше _TC1, тем более агрессивное тепловое регулирование используется для поддержания стабильной температуры. Чем больше _TC2, тем более агрессивное тепловое регулирование используется для подталкивания температуры вблизи точки поездки.

В следующей таблице приведен пример того, как диспетчер температуры вычисляет и применяет dp. В этом примере используются следующие значения параметров:

Конфигурация

• _PSV = 325^{o K}
• _TC1 = 2
• _TC2 = 3
• _TSP = 5000 миллисекунда
• Предположим, что температура постоянно повышается на 1 градус каждые 5 секунд.

Самый правый столбец в следующей таблице (с меткой P) указывает на регулируемый уровень производительности, который является результатом применения ограничений, заданных этими параметрами.

Драйвер политики

По умолчанию алгоритм, используемый для определения процента регулирования в зависимости от спецификаций ACPI, используется для всех тепловых зон. Как описано ранее, этот алгоритм основан исключительно на датчике температуры, подключенном к тепловой зоне, который может быть ограничивающим.

Если предпочтителен другой алгоритм, конструктор системы может реализовать драйвер политики для реализации предпочтительного алгоритма. Драйвер политики находится поверх стека тепловой зоны для зоны, которая он контролирует. Для этой зоны вместо алгоритма ACPI в тепловом диспетчере можно использовать алгоритм драйвера политики. Алгоритм драйвера политики может рассматривать любые сведения, к ним доступные в качестве входных данных. Решения политики, принятые водителем, передаются в диспетчер температуры, который регистрирует информацию и передает их в тепловую зону для выполнения.

Использование драйвера политики для тепловой зоны означает, что драйвер политики, а не ACPI и не операционная система, несет полную ответственность за принятие решения о том, когда и сколько следует регулировать зону.

Если драйвер политики присутствует, все точки следования, все тепловые константы, минимальное ограничение регулирования и т. д. полностью игнорируются. Операционная система не имеет представления о том, почему для тепловой зоны задан текущий уровень регулирования. Некоторые преимущества предоставляются благодаря использованию драйвера политики вместо собственного решения. Драйвер политики использует встроенный процесс регулирования устройств. Все, что может сделать тепловая зона для обеспечения тепловой защиты, может выполняться драйвером политики. Кроме того, автоматически наследуются диагностика для управления температурой Windows.

Интерфейс политики температуры обновлен, включив новый параметр, указывающий, является ли зона перегруженной. Этот параметр инициализируется значением FALSE. Старые драйверы политики не будут знать о новом параметре, а новые драйверы будут знать, что новый параметр поддерживается при обнаружении версии политики "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;

Драйвер политики может указать, что тепловая зона перегружена, выполнив политику IOCTL с параметром OverThrottled значение TRUE. При улучшении температурных условий драйвер тепловой политики может завершить IOCTL с overThrottled сбросом до FALSE, чтобы указать, что тепловая зона восстановлена. Windows не требует регулирования драйвера политики при установке флага overthrottle.

Устройства с тепловым управлением

Тепловые зоны управляют тепловым поведением управляемых устройств с помощью драйверов режима ядра. Одно устройство регулирования температуры может находиться в нескольких тепловых зонах. Если несколько тепловых зон запрашивают разные проценты производительности теплового регулирования, диспетчер температур выбирает минимальный процент производительности теплового регулирования для применения к устройству теплового регулирования.

Многие устройства охлаждения не имеют линейной тепловой реакции на устранение рисков охлаждения. В таких случаях тепловой предел является указанием для устройства требуемой степени охлаждения. Каждое устройство охлаждения будет иметь собственное сопоставление этого линейного значения с определенными параметров тепловой защиты.

При загрузке каждого драйвера устройства ACPI запрашивает интерфейс теплового охлаждения и регистрирует каждое отвечающее устройство в качестве устройства охлаждения. Позже, когда выполняется пассивное охлаждение и изменяется ограничение температуры для зоны, ACPI вызовет этот интерфейс на каждом устройстве охлаждения в зоне. Затем устройство охлаждения сопоставляет предоставленный предел температуры с конкретными характеристиками охлаждения и реализует соответствующие меры по устранению рисков охлаждения. Обратите внимание, что если устройство охлаждения отображается в нескольких тепловых зонах, то тепловой предел, ограничивающий устройство больше всего (то есть наименьший процент), передается устройству.

Примечание Windows предоставляет встроенные реализации теплового регулирования для процессоров, подсветки и метода управления ACPI.

Интерфейс теплового охлаждения

Windows предоставляет точки расширения для регистрации драйверов устройств в качестве устройств теплового регулирования и получения запроса на процентное регулирование температуры. Затем устройство отвечает за преобразование этого процента в действие, которое имеет смысл для себя.

Устройства, которые должны быть добавлены в качестве устройства регулирования температуры, должны сначала добавить _HIDs в список тепловых устройств в тепловой зоне, а затем реализовать следующий набор интерфейсов. При загрузке каждого драйвера устройства ACPI будет запрашивать этот интерфейс и регистрировать каждое отвечающее устройство в качестве устройства охлаждения. Позже, когда выполняется пассивное охлаждение и изменяется ограничение температуры для зоны, ACPI вызовет этот интерфейс на каждом устройстве охлаждения в зоне. Затем устройство охлаждения сопоставляет предоставленный предел температуры с конкретными характеристиками охлаждения и реализует соответствующие меры по устранению рисков охлаждения. Обратите внимание, что если устройство охлаждения отображается в нескольких тепловых зонах, то тепловой предел, ограничивающий устройство больше всего (то есть наименьший процент), передается устройству.

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

Процессор

Для процессора диспетчер температуры передает процент теплового регулирования диспетчеру питания процессора (PPM). Тепловое регулирование процессоров — это встроенная функция Windows.

Агрегатор процессора

Устройство агрегатора процессора позволяет припарковки ядра в качестве тепловой защиты. Зоны могут указывать парковку ядра в качестве тепловой защиты, если устройство агрегатора процессора является членом тепловой зоны. Для возникновения парковки ядер не требуется регулировать процессоры. Эта реализация работает параллельно с логическим процессом простоя процессора (LPI). Обратите внимание, что это по-прежнему зависит от основных предостережений парковки. В частности, любая работа, сопоставленная с припаркованным ядром, приведет к запуску ядра.

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

Графика

Чтобы сторонний драйвер графического минипорта можно было управлять температурой, он должен взаимодействовать с драйвером графического порта Windows, Dxgkrnl.sys. Dxgkrnl.sys имеет интерфейс теплового охлаждения и передает все запросы регулирования вниз по стеку драйверу мини-порта. Драйвер минипорта несет ответственность за преобразование запроса в действие, относяющееся к его устройству.

На следующей блок-схеме показана архитектура тепловой зоны, которая управляет GPU.

Подсветка

Уменьшение подсветки может значительно улучшить тепловые условия на мобильной платформе. Windows рекомендует, чтобы во время работы яркость системного дисплея никогда не ограничивалась температурой менее 100 нит.

Для управления подсветкой диспетчер температуры передает процент регулирования температуры драйверу монитора, Monitor.sys. Monitor.sys будет определять фактический уровень подсветки на основе этого теплового и других входных данных в Windows. Затем Monitor.sys применит параметр уровня подсветки через ACPI или драйвер дисплея.

Обратите внимание, что если температура тепловой зоны, включающая подсветку, продолжает расти, запрошенный процент теплового регулирования может в конечном итоге упасть до нуля. Реализация уровня подсветки в ACPI или драйвере дисплея должна гарантировать, что минимальный уровень яркости, доступный для элементов управления производительностью, по-прежнему виден конечным пользователям.

Примечание Во время работы яркость дисплея системы никогда не ограничивается температурой менее 100 нит.

Батарея

Еще одним main источником тепла в системе является зарядка батареи. С точки зрения пользователя, зарядка должна быть сокращена и даже полностью остановлена при ограниченном тепловом режиме. Однако при обычных вариантах использования не следует препятствовать зарядке батареи.

Примечание Мы рекомендуем не регулировать зарядку батареи, когда система (1) простаит и находится в диапазоне температур окружающей среды ниже 35^oC или (2) при любых условиях, когда температура окружающей среды ниже 25^oC.

Драйвер миникласса для метода управления Windows, Cmbatt.sys, напрямую использует интерфейс теплового охлаждения, как описано выше. Встроенное ПО отвечает за учет текущего ограничения температуры при зарядке. Чтобы задать тепловой предел для зарядки, необходим новый метод управления ACPI. Этот метод реализуется как метод для конкретного устройства (_DSM), как определено в спецификации ACPI 5.0, раздел 9.14.1.

Чтобы применить процент регулирования температуры, Cmbatt.sys оцените метод управления для конкретного устройства (_DSM), чтобы запросить встроенное ПО ACPI для установки теплового ограничения для зарядки. В методе управления _DSM определяется GUID для указания ограничения температуры.

Активное охлаждение

С точки зрения операционной системы платформа имеет две стратегии, которые она может использовать для реализации управления вентилятором:

• Реализуйте одну или несколько тепловых зон ACPI с активными точками поездки для задействования или отключения вентилятора.

  Тепловая платформа Windows поддерживает активные устройства охлаждения на очень простом уровне. Единственным поддерживаемым устройством является вентилятор ACPI, и управлять им можно только с помощью сигнала включения и выключения.

• Реализуйте собственное решение для управления вентилятором (с помощью драйверов, встроенного контроллера и т. д.).

  Хотя Windows не контролирует поведение собственных решений для вентиляторов, Windows поддерживает уведомления вентиляторов для диспетчера температуры для всех реализаций, включая встроенные контроллеры, чтобы можно было собирать диагностические сведения и данные телеметрии. Таким образом, воздействие вентилятора на операционную систему требуется для всех современных резервных компьютеров и настоятельно рекомендуется для всех остальных.

Обратите внимание, что реализация активного охлаждения полностью отделена от ранее рассмотренных мер пассивного охлаждения.

Управление вентилятором с помощью тепловой зоны ACPI

Windows поддерживает определение вентилятора на основе состояния D ACPI 1.0. (Дополнительные сведения см . в спецификации ACPI.) Таким образом, управление ограничивается включением и выключением вентилятора. Драйвер для вентилятора предоставляется в драйвере Windows ACPI Acpi.sys.

1. Датчик температуры считывает, что температура пересекла точку поездки, и выдает уведомление (0x80) о связанной тепловой зоне.
2. Тепловая зона считывает температуру с помощью метода управления _TMP и сравнивает температуру с активными точками следования (_ACx), чтобы решить, должен ли вентилятор быть включен или выключен.
3. Операционная система помещает устройство вентилятора в D0 или D3, что приводит к включению или отключению вентилятора.

На следующей блок-схеме показан поток управления для вентилятора, управляемого тепловой зоной 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})
    }
}

Многоскоростной вентилятор в ACPI

Чтобы достичь нескольких скоростей для вентилятора с помощью ACPI 1.0, существует два варианта:

• Тепловая зона может содержать несколько "вентиляторов", если существует только один физический вентилятор. Наличие большего "вентилятора" в одно время переводит на более высокую скорость вентилятора. Дополнительные сведения см. в примере этого параметра в разделе 11.7.2 спецификации ACPI 5.0.
• Когда вентилятор включен, он может решить для себя, как быстро вращаться. Например, этот вариант можно выбрать в системах со встроенными контроллерами.

Собственное решение для вентиляторов

Windows должна быть в состоянии обнаруживать активность вентилятора с помощью любой из реализаций. Когда платформа использует тепловую модель ACPI, Windows отвечает за включение и отключение вентилятора и, следовательно, уже знает, когда он активен. Если для управления вентилятором используется собственное решение, Windows требуется уведомление о том, что вентилятор работает. Для этого Windows будет поддерживать частичное подмножество расширений вентилятора ACPI 4.0, которые перечислены в следующей таблице.

Windows будет использовать объект _FST, чтобы определить, работает ли вентилятор (поле управления не равно нулю) или выключено (поле управления равно нулю). Windows также будет поддерживать уведомление (0x80) на устройстве вентилятора, что указывает на то, что _FST изменилась и нуждается в повторной оценки.

Вентилятор, реализующий объект _FST, не обязательно должен находиться в списке устройств _ALx тепловой зоны, но он может, как вариант, быть в этом списке. Этот параметр включает гибридное решение, в котором вентилятор обычно управляется сторонним драйвером, но может управляться тепловой зоной ОС, если сторонний драйвер не установлен. Если вентилятор находится в списке устройств _ALx и участвует в тепловой зоне (размещенной в D0), объект _FST должен указывать ненулевое значение элемента управления.

Для всех вентиляторов Windows будет использовать следующий алгоритм, определяющий состояние вентилятора:

1. Если вентилятор находится в D0 (в результате пересечения _ACx точки поездки тепловой зоны), он выполняется.
2. Если вентилятор находится в D3 и не поддерживает расширения ACPI 4.0, он отключается.
3. Если вентилятор находится в D3 и поддерживает расширения ACPI 4.0, операционная система будет проверка _FST поле Control для ненулевого значения, чтобы узнать, включен ли вентилятор.

Пример 1. Аппаратное управление вентилятором

В этом примере вентилятор управляется встроенным контроллером.

1. Встроенный контроллер решает запустить или остановить вентилятор на основе собственного внутреннего алгоритма.
2. После запуска или остановки вентилятора встроенный контроллер выдает уведомление (0x80) на устройстве вентилятора.
3. Операционная система оценивает _FST и считывает новое состояние вентилятора.

На следующей блок-схеме показан поток управления для вентилятора, управляемого встроенным контроллером.

В следующем примере ASL определяется устройство FAN, которое может уведомлять операционную систему об изменениях в состоянии вентилятора:

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
}

Пример 2. Управление вентилятором драйвера

В этом примере сторонний драйвер управляет вентилятором.

1. Драйвер решает запустить или остановить вентилятор на основе собственного внутреннего алгоритма.
2. Драйвер изменяет состояние вентилятора и оценивает пользовательский метод управления (SFST) на его тепловом устройстве.
3. Метод управления тепловым устройством обновляет содержимое _FST вентилятора и выдает уведомление (0x80) на устройстве вентилятора.
4. Операционная система оценивает _FST и считывает новое состояние вентилятора.

На следующей блок-схеме показан поток управления для вентилятора, управляемого сторонним драйвером.

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

Присутствие вентилятора

Платформа указывает, что в системе есть вентилятор, включив устройство вентилятора (идентификатор PnP PNP0C0B) в пространство имен ACPI. Windows будет принимать наличие этого устройства как указание на то, что система имеет вентилятор, а отсутствие этого устройства — как указание на отсутствие вентилятора в системе.

Руководство по современному резервному режиму

Платформа управления температурой Windows является частью ядра и поставляется со всеми системами Windows. Таким образом, указанный выше материал применяется ко всем машинам. Однако для различных типов компьютеров требуется дополнительное руководство, более конкретное в отношении современного режима ожидания.

Современный режим ожидания переносит модель питания смарт-телефона на компьютер. Он обеспечивает мгновенное включение, мгновенное отключение пользовательского интерфейса, которое пользователи стали ожидать на своем телефоне. Как и в случае с телефоном, современный режим ожидания позволяет системе оставаться актуальной, актуальной и доступной при наличии подходящей сети. Windows 10 поддерживает современный режим ожидания на маломощных платформах, соответствующих определенным требованиям сертификации Windows.

Современные резервные компьютеры — это мобильные устройства с тонким и легким форм-фактором. Кроме того, современные резервные компьютеры всегда включены и находятся в состоянии ACPI S0. Чтобы обеспечить надежное и надежное взаимодействие с клиентами, вся система — от механической конструкции до реализации встроенного ПО и программного обеспечения — должна быть разработана с критическим вниманием к тепловым характеристикам. Таким образом, все современные резервные компьютеры должны соответствовать требованиям к температуре.

Требования к современному режиму ожидания

Все современные резервные компьютеры должны пройти следующие тесты HCK:

• Все современные резервные компьютеры должны иметь по крайней мере одну тепловую зону, для которой определена критическая температура завершения работы (_CRT). Для систем x86 рекомендуется определить критичную температуру гибернации (_HOT), чтобы активировать сохранение пользовательских данных. _HOT должно быть ниже _CRT, а _CRT — ниже, чем у отказоустойчивой температурной точки встроенного ПО.
• Каждая тепловая зона должна сообщать о фактической температуре на датчике (_TMP). Тест выполняет на компьютере переменную рабочую нагрузку, и ожидается, что температура изменится.

Кроме того, рекомендуется, чтобы каждый компьютер был по крайней мере один датчик температуры для SoC.

Требования к активному охлаждению

Современные резервные компьютеры, использующие вентиляторы, должны соответствовать следующим дополнительным требованиям, которые тестируются в HCK:

• Вентилятор должен быть предоставлен операционной системе. Дополнительные сведения см. в разделе Присутствие вентилятора.
• Операционная система должна всегда знать, включен или выключен вентилятор. Даже в режиме устойчивости в режиме бездействия в современном режиме ожидания любые изменения в активности вентилятора должны разбудить SoC, чтобы обновить состояние. Дополнительные сведения о реализации уведомлений вентилятора см. в разделе Управление вентилятором с помощью тепловой зоны ACPI.
• Вентилятор не должен включаться, пока компьютер находится в режиме современного режима ожидания. При реалистичной рабочей нагрузке во время современного режима ожидания, которая происходит при выключении экрана, вентилятор не должен включаться.

С точки зрения пользователя компьютер, как представляется, отключен, когда он находится в режиме современного режима ожидания. Пользователи ожидают, что компьютер в режиме современного режима ожидания будет вести себя так, как будто он находится в системном состоянии спящего режима. Таким образом, пользователи ожидают, что вентилятор никогда не придет, так же, как на традиционных компьютерах во время сна. Если вентилятор включен, пользователи могут услышать его и/или почувствовать, что горячий воздух циркулирует и думать, что компьютер работает неправильно. Поэтому вентилятор не должен включаться в режиме современного режима ожидания. Дополнительные сведения о требуемом поведении см. в разделе Требования к тестированию HCK для современных резервных компьютеров.

Эти требования подразумевают, что политика охлаждения при включении экрана может отличаться от политики при выключении экрана. Компьютер может использовать активное охлаждение, когда экран включен, но он должен полагаться только на пассивное охлаждение, когда экран выключен. Активная точка поездки для вентилятора может быть гораздо ниже, когда экран включен, чем когда он выключен. Для реализации ACPI _ACx необходимо обновить при входе в современный резервный режим. Для собственных решений обязательно обновите политику во встроенном контроллере.

Регулирование процессора

PPM передает в PEP максимальный, требуемый и минимальный уровни производительности. В условиях теплового регулирования максимальный уровень производительности должен совпадать с производительностью регулирования, запрошенной диспетчером температуры. Затем PEP задает физическое напряжение и частоту ЦП на основе требований к уровню производительности PPM.

Сигнал шума вентилятора

Начиная с Windows 11, устройства могут отправлять сигнал шума вентилятора в ОС для использования в решениях по управлению ресурсами с целью предоставления пользователям прохладного и спокойного взаимодействия. Этот интерфейс согласия позволяет встроенному ПО отправлять сведения об rpm вентилятора в ОС в виде значения от 0 (выключенного вентилятора) до максимального значения RPM, которое ОС может использовать в решениях по управлению ресурсами для охлаждения устройства по мере необходимости. Это дает два основных преимущества:

1. Тихий пользовательский интерфейс. Шум вентилятора и дует горячим воздухом являются значительным источником неудовлетворенности клиентов. Это особенно верно, когда пользователь не ожидает интенсивной активности вентилятора, например, когда устройство выполняет небольшой объем работы или не работает на переднем плане.
2. Улучшенное время работы батареи: Более высокая скорость вентилятора приводит к большему энергопотреблению, что приводит к более быстрому разряду батареи при работе с постоянного тока и более медленной зарядке при работе с переменным тоном.

В настоящее время этот сигнал можно использовать для управления задачами индексатора поиска, и планируется включить дополнительные фоновые задачи для использования этого сигнала.

На следующей схеме показано, как сигнал шума вентилятора передается на уровнях от встроенного ПО к программному обеспечению.

Как работает сигнал шума вентилятора

Сведения об интерфейсе ACPI

Ниже приведены четыре функции метода для конкретного устройства (_DSM, UUID: A7611840-99FE-41ae-A488-35C75926C8EB), которые используются для поддержки этой функции. Сведения о _FST (состояние вентилятора) можно найти в разделе 11.3.1.4 спецификации ACPI и в примере 1. Управление вентилятором оборудованиядля устройств, управляемых теплом.

На следующей схеме представлена сводка по использованию этих функций.

На следующей блок-схеме показан поток управления для вентилятора, управляемого встроенным контроллером, включая метод управления Notify(0x80).

Функции перечисления (функция 0)

Чтобы операционная система взаимодействовала с платформой, устройство ACPI должно быть предоставлено через пространство имен. Это устройство должно содержать объект _CID, содержащий EISAID("PNP0C0B"). Этот область устройства должен содержать следующее определение _DSM, указывающее, какие _DSMs поддерживает устройство.

Вернуться: Чтобы указать поддержку функций от 0 до 3, перечисленных выше, функция Перечисление функций (функция 0) должна возвращать 0xF. Дополнительные сведения см. в разделе 9.1.1 спецификации ACPI.

Получить функцию поддержки точки поездки вентилятора (функция 1)

Оборудование сообщает ОС, что поддерживается с точки зрения RMS.

Аргументы

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

Arg1: редакция: 0

Arg2: Функция: 1

Arg3: Пустой пакет

Вернуться: Целочисленное значение, содержащее степень детализации, поддерживаемую для точек поездки вентилятора, в RMS. Если значение не равно нулю, ОС может выбрать точки поездки, которые кратны степени детализации уведомления. Например, с степенью детализации 200 OSPM будет разрешено выбирать точки поездки 0, 200, 400, 600 и т. д. Rpm. Значение 0 указывает, что точки поездки не поддерживаются.

Функция Set Fan Trip Points (Function 2)

ОС сообщает оборудованию, что такое следующая точка поездки уведомления; оборудование уведомляет ОС, когда это происходит.

Аргументы

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

Arg1: Редакция: 0

Arg2: Функция: 2

Arg3: Пакет, содержащий нижнюю и верхнюю точки поездки. (2 элемента int. Lower at index 0, Upper at index 1)

OSPM выбирает только точки поездки, которые являются кратными степени детализации точки поездки, указанной в функции 1. Когда фактическая скорость вентилятора выходит выше или ниже верхних или нижних точек поездки, платформа должна выдать уведомление (0x80) на устройстве вентилятора. Затем OSPM оценит _FST (состояние вентилятора), чтобы определить текущую скорость вентилятора. Если скорость вентилятора уже выходит за пределы указанных точек поездки при установке точек поездки, платформа должна немедленно выдать уведомление (0x80).

Верхняя точка поездки будет кратна степени детализации. Нижняя точка поездки будет иметь значение (кратное степени детализации) + 1 (нижняя точка < поездки верхняя точка поездки). Если значение RPM равно 0, ОС установит для нижней точки поездки значение 0, а для верхней точки — значение 1.

Вернуться: Ни один.

Функция получения операционных диапазонов вентилятора (функция 3)

Сопоставление между RPM —> влияние. Обратите внимание, что только один вентилятор (ближайший к SoC) может реализовать этот интерфейс. Он должен реализовывать все 3 функции плюс функцию 0 из раздела 9.1.1 спецификации ACPI.

Аргументы

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

Arg1: Редакция: 0

Arg2: Функция: 3

Arg3: Пустой пакет.

Вернуться: Пакет, содержащий следующий формат:

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

Эта таблица используется для получения диапазона RPM для каждого из уровней влияния вентилятора:

Если диапазон влияния не используется платформой (например, если вентилятор переходит непосредственно из диапазона удара 2 в диапазон 4), это можно указать, задав значение max RPM для неиспользуемого диапазона удара, равное максимальному значению RPM для нижнего диапазона удара.

Пример сопоставления

Пример кода ASL

    ...
 
    // _DSM - Device Specific Method
    // Arg0: UUID Unique function identifier
    // Arg1: Integer Revision Level
    // Arg2: Integer Function Index (0 = Return Supported Functions)
    // Arg3: Package Parameters
    Method(_DSM, 0x4, NotSerialized) {
            If(LEqual(Arg0, ToUUID("A7611840-99FE-41ae-A488-35C75926C8EB"))) {
                Switch (ToInteger(Arg2)) {
                    Case(0) {
                        // _DSM functions 0 through 3 are supported
                        Return (Buffer() {0xf})
                    }
                    Case(1) {
                        // Report 200 RPM granularity for trip points
                        Return (\_SB.FAN0.GRAN)
                    }
                    Case(2) {
                        // Save lower RPM trip point
                        Store(DeRefOf(Index(Arg3, 0)), \_SB.FAN0.LRPM)
                        // Save upper RPM trip point
                        Store(DeRefOf(Index(Arg3, 1)), \_SB.FAN0.URPM)
                        // Configure hardware for the trip points, Tell EC to set fan speed trip point.
                        \_SB.FAN0.CRNF()
                        Return (0)
                    }
                    Case(3) {
                        Return (Package(4) { 
                            4000, // 1-4000 RPM is impact score 1
                            5000, // 4001-5000 RPM is impact score 2
                            6000, // 5001-6000 RPM is impact score 3
                            9000})// 6001-9000 RPM is impact score 4
                    }
                    Default {
                        Return(Buffer(One) { 0x00 }) // Guid mismatch
                    }
                }
            }
            Else {
                Return(Buffer(One) { 0x00 }) // Guid mismatch
            }
    }  
 
} // end of FAN0
}

Тестирование и трассировка

Ознакомьтесь со следующими инструкциями по сбору журналов и просмотру в Windows Анализатор производительности (WPA):

1. Параметры —> Поиск в Windows —> Параметры индексатора расширенного поиска —> Дополнительно —> Удаление и перестроение индекса (перестроение)
2. wpr -boottrace -addboot AcpiFanNoiseImpact.wprp –filemode
3. Перезагрузите систему
4. Проверьте состояние индекса параметров —> поиск в Windows (убедитесь, что устройство подключено к источнику питания переменного тока).
5. По завершении индексирования остановите трассировку: wpr -boottrace -stopboot AcpiFanNoiseImpact.etl (отмена трассировки без сохранения: wpr -boottrace –cancel)
6. Откройте AcpiFanNoiseImpact.etl через Windows Анализатор производительности (WPA).

Скачайте файл на страницеAcpiFanNoiseImpact.zip Or, скопируйте следующее и сохраните файл как 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>

На приведенном ниже рисунке показан пример диаграммы WPA , на которой индексатор поиска отключается, когда вентилятор громко.

Существует один уровень вентилятора, который бы поисковый индекс откатил в полном объеме (самый высокий, это должно быть влияние оценка 4), но все остальные уровни вентилятора должны быть снижены активность, а не подвеска. Например, если ACPI объявил Impact3MaxRPM = 4000 об/мин в функции 3 (функция получения рабочих диапазонов вентилятора), при частоте вращения > вентилятора 4000 (4100RPM, 4500RPM) мы увидим, SearchIndexer.exe и SearchProtocalHost.exe загрузка ЦП будет приостановлена.

На рисунке ниже показан пример диаграммы WPA с приостановкой SearchIndexer.exe и SearchProtocolHost.