Jump to content

Оценка энергопотребления на уровне системы и подсистемы во время выполнения

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

Измерение рассеиваемой мощности в реальном времени имеет решающее значение при термическом анализе новой конструкции аппаратно-подобных процессоров (ЦП), так же как это важно для программистов ОС, пишущих планировщики процессов. [2] [3] Исследователи обнаружили, что знание энергопотребления в реальном времени на уровне подсистем, таких как процессор, жесткие диски, память и другие устройства, может помочь в оптимизации энергопотребления в таких приложениях, как шифрование хранилища, виртуализация и изолированная программная среда приложений, а также в поиске компромиссных решений для приложений. [4]

Были обнаружены различные технологии, которые позволяют измерять энергопотребление в режиме реального времени. Эти технологии можно разделить на две основные категории: прямое измерение с использованием датчиков мощности и измерителей подсистемы или косвенная оценка на основе предоставленной информации, такой как счетчики температуры или производительности. [4] В каждой категории также есть разные методы; например, были разработаны различные модели для использования счетчиков производительности для оценки мощности. Каждый из этих методов имеет свои преимущества и недостатки. Целью данной статьи является обзор различных методов в каждой категории.

Оценка энергопотребления на уровне системы и подсистемы во время выполнения

[ редактировать ]

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

Косвенное измерение мощности

[ редактировать ]

Косвенное измерение мощности, например, с использованием блока мониторинга производительности ЦП (PMU), [5] или счетчики производительности для оценки энергопотребления процессора и памяти во время выполнения [6] широко используются из-за своей низкой стоимости.

Счетчики производительности

[ редактировать ]

Аппаратные счетчики производительности (HPC) — это набор регистров специального назначения, встроенных в современные микропроцессоры для хранения счетчиков операций, связанных с оборудованием, для событий, связанных с оборудованием и программным обеспечением. [4] Различные модели процессоров имеют ограниченное количество аппаратных счетчиков с разными событиями, которые удовлетворяют требованиям ЦП. Эти счетчики производительности обычно точны и предоставляют важную подробную информацию о производительности процессора с точностью до такта. [7] Исследователи смогли создать различные модели, которые используют событие HPC для оценки энергопотребления системы в режиме реального времени.

Модель линейной оценки мощности первого порядка с использованием счетчиков производительности

[ редактировать ]

Линейная модель первого порядка была разработана Г. Контрерасом и М. Мартоноси в Принстонском университете с использованием процессора Intel PXA255 для оценки энергопотребления процессора и памяти. [6] Это отличается от предыдущей работы, в которой для оценки мощности используются HPC, поскольку требования к мощности процессора Intel PXA255 были более жесткими и предлагали меньше доступных событий производительности по сравнению с процессорами среднего и высшего класса. [6] Этот метод также не привязан к конкретной процессорной технологии и компоновке HPC для оценки мощности, а может использоваться для любого типа процессора с HPC.

В этой линейной модели мощности используются следующие пять событий производительности: выполнение инструкции, зависимости данных, промахи в кэше инструкций, промахи TLB данных и промахи TLB инструкций. Выражение линейной модели получается (уравнение 1) следующим образом, предполагая линейную корреляцию между значениями счетчиков производительности и энергопотреблением. [6]

(1)

Где, являются силовыми весами и — константа энергопотребления процессора во время простоя.

Также можно оценить энергопотребление памяти (внешнего ОЗУ), отслеживая события производительности, если они доступны на проектируемом процессоре. [6] Например, процессор PXA255 не имеет прямого учета событий производительности для внешней оперативной памяти, но для оценки энергопотребления памяти можно использовать промахи по кэшу инструкций, промахи по кэшу данных и количество зависимостей данных от процессора. Опять же, на основе полученной информации (уравнение 2) выводится линейная модель для оценки энергопотребления памяти. [6]

(2)

Где, являются силовыми весами и — постоянная потребляемая мощность во время простоя.

Основная сложность этого метода заключается в вычислении весов мощности с использованием математической модели (обычная оценка методом наименьших квадратов) в различных точках напряжения/частоты. Эти постоянные значения в уравнениях 1 и 2 зависят от напряжения и частоты, и их необходимо вычислять во время эталонного тестирования. После построения такой таблицы для параметров весов мощности ее можно реализовать программно или аппаратно для оценки мощности в реальном времени. [6] Другая проблема заключается в доступе к HPC; например, в этом случае они считываются в начале прерывания основного таймера ОС, что требует модификации программного обеспечения. Программное обеспечение можно написать с использованием уравнений 1 и 2 и расчетных весов мощности, полученных из таблицы, для оценки энергопотребления во время выполнения. Для уравнения 1 программе также необходимо 5 выборок HPC, но в этом примере процессор PXA255 может выбирать только 2 события в любой момент времени, поэтому требуется многократное выполнение кода, а также выравнивание данных. [6]

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

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

Модель кусочной линейной оценки мощности с использованием счетчиков производительности

[ редактировать ]

Кусочная модель была разработана для точной оценки энергопотребления с помощью счетчиков производительности. Этот метод был разработан К.Сингхом, М.Бхадаурией из Корнелльского университета и С.А.Мкки из Технологического университета Чалмерса независимо от поведения программы для тестовых наборов SPEC 2006, SPEC-OMP и NAS. Этот метод был разработан для анализа влияния общих ресурсов и температуры на энергопотребление мультипроцессоров. [2]

В этом методе использовались 4 счетчика производительности процессора AMD Phenom. Счетчики производительности следующие: : L2_CACHE_MISS: ВСЕ, : RETRIED_UOPS, : RETIRED_MMX_AND_FP_INSTRUCTIONS: ВСЕ, : ДИСПАТЧ_СТАЛЛС. Эти счетчики производительности архитектурно специфичны для AMD Phenom и могут отличаться для других процессоров. AMD позволяет собирать данные с этих четырех HPC одновременно. [2] Микротесты, представляющие собой небольшую программу, пытаются собрать данные с выбранных выше HPC. Собранные данные по каждому ядру процессора используются в следующем уравнении. [2]

(3)

Где (4)

Преобразование уравнения 4 может быть линейным, обратным, логарифмическим, экспоненциальным или квадратным корнем; это зависит от того, что делает определение мощности более точным. Для анализа уравнения 4 на основе собранных данных была выбрана кусочная линейная функция, поскольку она позволяет получить более подробную информацию о мощности каждого ядра процессора. Наконец, анализ собранных данных HPC с помощью кусочно-линейного метода дает подробную информацию о энергопотреблении (например, промахи в кэше L2 вносят наибольший вклад в энергопотребление по сравнению с L3).

Вышеописанный метод использовался для планирования каждого ядра процессора AMD Phenom в определенном диапазоне мощности. Ядро процессора приостанавливается, когда ядро ​​превышает доступную мощность, и снова становится доступным, когда становится доступно достаточно мощности. [2]

У этого метода есть некоторые ограничения и проблемы; например, этот метод не учитывает влияние температуры. Существует прямая зависимость между температурой и общим энергопотреблением (поскольку с ростом температуры увеличивается мощность утечки), которую эта модель не учитывает, поскольку AMD Phenom не имеет датчиков температуры для каждого ядра. Второй недостаток заключается в том, что mictobenchmarks не является полным для получения более точной оценки мощности (например, он не охватывает DISPATCH_STALLS HPC). Более полный микротест вызовет проблемы со сроками. Необходимо провести дальнейшую работу по включению тепловых данных в модель и стратегии планирования потоков, а также по снижению частоты (DVFS) каждого ядра вместо приостановки ядра. [2] Этот метод охватывает только процессоры, но есть и другие подсистемы, такие как память и диски, которые также необходимо учитывать в общей мощности.

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

Адаптивная модель оценки мощности с использованием счетчиков производительности

[ редактировать ]

Большинство моделей, подобных приведенной выше, не имеют возможности измерять энергопотребление на уровне компонентов или подсистем. DiPART (Дезагрегированный анализ мощности в режиме реального времени), разработанный профессорами М. Сриваставой, Ю. Суном и Л. Ваннером из Калифорнийского университета в Лос-Анджелесе, обеспечивает возможность оценки энергопотребления на основе аппаратных счетчиков производительности и использования только одного датчика мощности для вся система. [4] Модели необходимы для оценки энергопотребления на основе счетчиков производительности. Эти модели коррелируют данные для разных счетчиков производительности с энергопотреблением, а статические модели, подобные приведенным выше примерам (первого порядка и кусочно-линейная), имеют разные ошибки оценки из-за различий на одинаковом оборудовании. [4] DiPART — решение этой проблемы, поскольку это самоадаптирующаяся модель, которую можно один раз откалибровать и применять на разных платформах.

Для модели линейной оценки DiPART требуется датчик мощности, способный регистрировать рассеиваемую мощность и измерять ток во время работы. Существуют различные встроенные датчики, такие как система Atom-LEAP. [8] или мобильные платформы разработки Qualcomm Snapdragon. [9] это может помочь DiPART. Один единственный датчик мощности может использоваться для калибровки модели оценки уровня подсистемы DiPART. [4]

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

(5) [4]

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

(6) [4]

Вышеупомянутые счетчики производительности также можно использовать для модели энергопотребления ОЗУ и вектора коэффициентов памяти, а постоянное значение также вычисляется во время фазы обучения с использованием данных счетчика производительности и отслеживаемых данных энергопотребления.

(7) [4]

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

Для оценки коэффициента и константы мощности диска на этапе обучения используется тот же подход, что и для ЦП и ОЗУ. [4]

(8) [4]

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

Модификация модели питания ЦП, ОЗУ и диска, а также изменение на уровне системы требуется, если общая дельта составляет не менее 10%. Итерационный процесс будет продолжаться до тех пор, пока прогноз модели мощности отдельной подсистемы не приблизится к контролируемой общей мощности. После обучения модели энергопотребления подсистемы модель энергопотребления на уровне всей системы не требуется повторно обучать для той же системы.

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

Одной из основных проблем этой модели является зависимость от датчиков мощности для измерения общей мощности. Другая проблема — количество счетчиков производительности, используемых в модели DiPART. Эти счетчики производительности могут быть доступны не для всех процессоров. Этот метод также использовался для ЦП, ОЗУ и дисковой подсистемы, но есть и другие подсистемы, которые необходимо учитывать при общем энергопотреблении. Основной проблемой при добавлении большего количества подсистем будет адаптивный механизм, поскольку с увеличением количества подсистем точность и скорость обучения будут снижаться. [4] Другая проблема заключается в том, что ЦП, Диск и ОЗУ также не идеальны и имеют некоторую часть нелинейности, которая не учитывалась в этом методе.

Динамическое управление температурным режимом

[ редактировать ]

Поскольку размер технологии интегральных схем (ИС) становится меньше в нанометровом масштабе и на этой небольшой площади размещается все больше транзисторов, общая мощность и температура кристалла также увеличиваются. Высокая температура чипа, если ее не контролировать, может повредить или даже сжечь чип. Высокая температура чипа также влияет на производительность и надежность. [10] [11] Высокая температура чипа приводит к увеличению энергопотребления утечки, более высокому сопротивлению межсоединений и более медленной скорости транзисторов. [10] Поэтому динамическое управление температурой (DTM) требуется для высокопроизводительных встроенных систем или высокопроизводительных микропроцессоров. Термальные датчики также не идеальны для этой работы из-за их точности и длительной задержки измерения температуры. Идея DTM состоит в том, чтобы обнаружить и снизить температуру горячих точек в чипе, используя различные методы, такие как миграция активности, локальное переключение, динамическое масштабирование напряжения и частоты. [10]

Новый метод был разработан Х. Ли, П. Лю, З. Ци, Л. Цзинь, В. Ву, SXD Тан, Дж. Янг в Калифорнийском университете в Риверсайде, основанный на наблюдении среднего энергопотребления модулей низкого уровня, работающих в типичном режиме. рабочая нагрузка. [10] Существует прямая корреляция между наблюдением и изменениями температуры. Этот новый метод был решением для замены старых технологий, таких как датчики онлайн-слежения на кристалле, такие как сенсорная технология на основе CMOS, которые менее точны и требуют аппаратной реализации. [12]

Этот метод основан на наблюдении средней мощности за определенный промежуток времени, которая определяет изменения температуры. Эту идею можно реализовать с помощью быстрого алгоритма теплового моделирования на архитектурном уровне. [10] Этот метод также представляет новый способ расчета переходных изменений температуры на основе концепции согласования моментов в частотной области. Концепция согласования моментов в основном гласит, что переходное поведение динамической системы может быть точно описано несколькими доминирующими полюсами системы. [10] Алгоритм согласования моментов необходим для расчета реакции на изменение температуры при начальных температурных условиях и средней потребляемой мощности за заданное время. [10] Этот метод также соответствует тепловому моделированию RC на уровне схемы на архитектурном уровне, как описано в ссылке. [13] Изменение температуры блока во время работы происходит из-за нерегулярного режима питания, генерируемого каждым блоком в его архитектурных блоках. [10] Эта потребляемая мощность соответствует постоянному току и небольшим колебаниям переменного тока. Также было показано и доказано, что большая часть энергии в силовой трассе концентрируется на составляющей постоянного тока. Следовательно, среднюю мощность можно описать как постоянный вход постоянного тока в тепловую цепь. Ведь необходимо реализовать походный тепловой момент (ТММ) с исходным состоянием и входом постоянного тока. Модель ТММ выглядит следующим образом:

(9)

G и C — матрицы проводящей и емкостной цепи, а x — вектор температуры узла. [10] u — вектор независимого источника питания, а B — матрица селектора входа. Это уравнение будет решено в частотной области, и потребуется начальное условие, которым будет начальная температура в каждом узле. [10] Основная идея заключается в реализации алгоритма TMM, который обеспечивает более надежную оперативную оценку температуры для приложений DTM.

Подводя итог, можно сказать, что алгоритм TMM намного быстрее, чем предыдущая работа в этой области, позволяет оценить температурные изменения, поскольку этот метод использует метод согласования моментов в частотной области. Другая работа (например, HotSpot) использует метод интегрирования, при котором для получения температуры в определенной рабочей точке нужны все предыдущие точки. Это увеличит время моделирования.

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

PowerBooter и PowerTutor

[ редактировать ]

Эта методика степенной модели была разработана в сотрудничестве Л. Чжан, Б. Тивана, З. Цянь, З. Ван, Р. П. Дик, З. Мао из Мичиганского университета и Л. Янг из Google Inc. для точной онлайн-оценки мощности для Смартфоны. [14] PowerBooter — это автоматизированная модель питания, которая использует встроенные датчики напряжения батареи и поведение батареи во время разрядки для мониторинга энергопотребления всей системы. Этот метод не требует какого-либо специального внешнего измерительного оборудования. PowerTutor также является инструментом измерения мощности, который использует данные, сгенерированные PowerBooter, для онлайн-оценки мощности. Всегда существует ограничение на срок службы батареи смартфона , которое необходимо преодолеть разработчикам аппаратного и программного обеспечения. Разработчики программного обеспечения не всегда обладают лучшими знаниями о энергопотреблении для разработки более оптимизированных по энергопотреблению приложений, поэтому конечные пользователи всегда винят во всем срок службы батареи. Поэтому существует потребность в инструменте, способном измерять энергопотребление на смартфонах, который разработчики программного обеспечения могли бы использовать для мониторинга своих приложений в режиме реального времени. Исследователи разработали конкретные модели управления питанием для конкретных портативных встраиваемых систем, и требуется приложить огромные усилия, чтобы повторно использовать эти модели для широкого спектра современных устройств. Технология смартфона . Таким образом, решением этой проблемы является модель PowerBooter, которая может оценивать энергопотребление в реальном времени для отдельных подсистем смартфона, таких как процессор, ЖК-дисплей, GPS, аудио, Wi-Fi и компоненты связи мобильного телефона. Наряду с моделью PowerBooter онлайн-утилита PowerTutor может использовать сгенерированные данные для определения энергопотребления на уровне подсистемы. Модель и утилиту PowerTutor можно использовать на разных платформах и технологиях смартфонов .

Эта модель отличается от других обнаруженных моделей, поскольку она основана только на знании кривой напряжения разряда аккумулятора и доступе к датчику напряжения аккумулятора, который имеется во всех современных смартфонах. [14] Основная идея этой модели заключается в использовании состояния разряда батареи с запуском обучающих программ для управления питанием компонентов телефона и состояниями активности. Каждый отдельный компонент смартфона удерживается в определенном состоянии в течение значительного периода времени, а изменение состояния разряда аккумулятора фиксируется с помощью встроенных датчиков напряжения аккумулятора. [14] Первая сложная идея — преобразовать показания напряжения батареи в потребляемую мощность. Это определяется изменением состояния разряда (который представляет собой общую потребляемую батареей энергию) в течение интервала тестирования, фиксируемого датчиками напряжения, что в конечном итоге приводит к следующему уравнению.

(10)

Где E – номинальная энергоемкость аккумулятора, SOD (Vi) – состояние разряда аккумулятора при напряжении Vi, а P – среднее энергопотребление за интервал времени t1 и t2. Состояние разряда можно оценить с помощью справочной таблицы, в которой фиксируется взаимосвязь между текущим напряжением и SOD. Определение энергии также является проблемой, поскольку энергия меняется по мере старения батареи. На оборотной стороне новых батарей указана общая энергия, но это значение не может быть верным всегда. Он может оценить энергию при самой высокой и самой низкой скорости разряда, чтобы уменьшить ошибку. Внутреннее сопротивление также оказывает существенное влияние на ток разряда. Чтобы уменьшить влияние внутреннего сопротивления, все компоненты телефона можно переключить в режимы минимального энергопотребления, чтобы минимизировать ток разряда при измерении напряжения. Наконец, этот метод использует кусочно-линейную функцию для моделирования нелинейной зависимости между SOF и напряжением батареи.

Вышеупомянутая модель батареи может быть автоматизирована за 3 шага, которые описаны в разделе . [14] В заключение отметим, что этот метод выгоден, поскольку все смартфоны могут использовать этот метод, а для новых смартфонов эту модель необходимо построить только один раз, и после автоматизации процесса не будет необходимости в каком-либо дополнительном оборудовании для измерения энергопотребления. После создания модели автоматически или вручную утилита PowerTutor может использовать данные для оценки энергопотребления в режиме реального времени. Инженеры-программисты могут использовать эту утилиту для оптимизации своего проекта, а пользователи могут использовать этот инструмент для принятия решения о покупке приложений на основе энергопотребления.

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

Область применения [15] и DevScope [16] аналогичная работа по оценке смартфона энергопотребления .

Моделирование во время выполнения и оценка энергопотребления операционной системы

[ редактировать ]

Операционная система (ОС) является основным программным обеспечением , работающим на большинстве вычислительных систем, и вносит основной вклад в рассеивание энергопотребления. Поэтому модель операционной системы была разработана Т. Ли и Л. К. Джоном из Техасского университета в Остине для оценки энергопотребления ОС, что помогает управлять питанием и оценивать энергопотребление программных приложений. [3]

Было подсчитано, что выполнение программного обеспечения на аппаратных компонентах может рассеивать значительную часть потребляемой мощности. [17] Также было показано, что выбор алгоритма и другие решения программного кода более высокого уровня во время разработки программного обеспечения могут существенно повлиять на мощность системы. Многие из этих программных приложений зависят от операционной системы; поэтому игнорирование расчетного энергопотребления ОС может привести к огромной ошибке в оценке энергопотребления. Оценка энергопотребления ОС может помочь разработчикам программного обеспечения оптимизировать дизайн своего кода, чтобы сделать его более энергоэффективным. Например, инженер-программист; может наблюдать энергопотребление при использовании различных методов компиляции для обработки промахов TLB и пейджинга. [14] Хорошая модель ОС должна обладать следующими свойствами, чтобы быть достаточно хорошей для инструментов управления температурой или питанием. Модель должна быть высоконадежной, быстрой, а также иметь возможность оценки во время выполнения, которая не увеличивает накладные расходы. Модель должна быть простой и легко адаптируемой на разных платформах.

Целевая оценка мощности во время выполнения требует линейной операции первого порядка с одной метрикой мощности, что снижает накладные расходы на оценку. [14] Число инструкций за цикл (IPC) можно использовать в качестве показателя для характеристики производительности современных процессоров. В бумаге [14] показывает, как различные компоненты ЦП и систем памяти вносят вклад в общую мощность операционной системы. Путь к данным и структура конвейера, а также часы потребляют больше всего энергии. Линейную модель можно получить на основе IPC, который отслеживает рутинную мощность ОС. Простое уравнение энергии может использоваться для оценки энергопотребления данной части программного обеспечения, где P — средняя мощность, а T — время выполнения этой программы.

Самая сложная часть — вычислить среднюю мощность P для каждой отдельной процедуры операционной системы. Можно использовать корреляцию между средней мощностью IPC и ОС или использовать счетчики производительности оборудования. Метод профилирования (данные, полученные в ходе эталонного тестирования) также можно использовать для прогнозирования энергопотребления. Модель линейной мощности в [14] заключается в следующем: . Это простая линейная модель, которая показывает сильную корреляцию между производительностью IPC и операционной системой. В этом подходе профилирование также требуется для создания данных, необходимых для построения модели. После того, как модель сгенерирована для одной системы, она больше не нужна для этой же системы.

Измерение и обеспечение мощности виртуальных машин

[ редактировать ]

Джоульметр — это решение, предложенное Аманом Кансалом, Фэн Чжао и Цзе Лю из Microsoft Inc., Нупуром Котари из Университета Южной Калифорнии, Лос-Анджелес и Аркой Бхаттачарья из Индийского технологического института, для измерения мощности виртуальной машины, которую невозможно измерить непосредственно на оборудовании. . [18] Этот метод используется для управления питанием виртуализированных центров обработки данных. Сегодня большинство серверов имеют счетчики электроэнергии, а старые серверы используют блоки распределения мощности (PDU). В этом методе используются отдельные измерители мощности, что позволяет значительно снизить затраты на электроснабжение.

Этот метод использует модели электропитания в программном обеспечении для отслеживания использования энергии виртуальной машины на каждом существенном аппаратном ресурсе с использованием состояний электропитания оборудования, наблюдаемых гипервизором. [18] Джоульметр также может решить проблему ограничения энергопотребления виртуальных машин, что значительно снизит затраты на обеспечение электропитанием. Самыми энергоемкими подсистемами компьютерных серверов являются процессор, память и диск. Серверы также потребляют энергию в режиме ожидания, которая иногда может быть большой, но она статична и ее можно измерить. Модели питания представлены для каждой из подсистем ЦП, памяти и диска в справочнике. [18] подробно. Эта энергетическая модель является основным методом Джоульметра. Рисунок 4 для справки [18] показана блок-схема Джоулеметра, где модуль отслеживания системных ресурсов и мощности считывает полное использование процессора, диска и мощности сервера. Модуль отслеживания ресурсов ВМ отслеживает всю рабочую нагрузку с помощью счетчиков гипервизора. Модуль обучения базовой модели реализует методы обучения, описанные в разделе [18] а также модуль доработки. Наконец, модуль расчета энергии использует модуль обучения базовой модели и модуль уточнения модели для вывода данных об использовании энергии виртуальной машины с использованием уравнений энергии, описанных в ссылке. [18]

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

Прямое измерение мощности

[ редактировать ]

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

Встроенная сенсорная система Low Power Energy Aware Processing

[ редактировать ]

Программа LEAP (Low Power Energy Aware Processing) была разработана Д. Макинтайром, К. Хо, Б. Йипом, А. Сингхом, В. Ву и У. Дж. Кайзером в Калифорнийском университете в Лос-Анджелесе для обеспечения уверенности в том, что встроенные сетевые сенсорные системы энергетически оптимизированы для своих применений. Система LEAP, как описано в ссылке [19] предлагает подробный мониторинг рассеяния энергии и сложное планирование управления мощностью для всех подсистем, включая сенсорные системы. LEAP — это многопроцессорная архитектура, основанная на разделении аппаратной и программной системы. Это независимый метод мониторинга энергии и управления мощностью для каждой отдельной подсистемы. Целью LEAP является управление микропроцессорами для достижения минимального энергопотребления на задачу. Многим современным встроенным сетевым датчикам приходится выполнять множество задач, таких как обработка изображений, высокопроизводительные статистические вычисления и связь. Чтобы убедиться, что все эти приложения работают эффективно, требуется функция мониторинга и планирования энергопотребления в реальном времени, и LEAP может предложить эту функцию для этих систем.

Система LEAP (ENS) была разработана для обеспечения высокой точности и возможности измерения энергии с низкими издержками. LEAP позволяет использовать приложения, учитывающие энергопотребление, посредством планирования и профилирования энергопотребления компонентов с высокой энергоэффективностью, включая несколько беспроводных сетевых интерфейсов, элементы хранения и сенсорные возможности. [19] Самым большим преимуществом системы LEAP является ее возможность управления энергопотреблением и предварительной обработки (EMAP). Результаты экспериментов показывают, что оптимальный выбор сенсорных систем, процессора, беспроводного интерфейса и технологии памяти не зависит от приложения, но может быть связан с проблемой распределения оборудования. EMAP имеет возможность разделить устройства на множество доменов питания с возможностью отслеживать, включать или отключать питание в каждом домене, а также реагировать на триггерные события или условия, которые восстанавливают или отключают питание в каждом домене. EMAP периодически собирает данные и передает их хост-процессу, а затем хост-процессор передает расписание управления питанием в EMAP.

Рисунок 1 для справки [19] показывает архитектуру LEAP и архитектуру EMAP. LEAP и EMAP — это сложные платформы, требующие аппаратного и программного обеспечения. Все подробные подходы к проектированию описаны в ссылке. [19]

В заключение, LEAP отличается от предыдущих методов, таких как PowerScope. [20] поскольку он предоставляет как информацию о энергопотреблении в режиме реального времени, так и стандартную среду выполнения приложений на одной платформе. В результате LEAP устраняет необходимость синхронизации между тестируемым устройством и внешним устройством измерения мощности. LEAP также предоставляет информацию о питании отдельных подсистем, таких как ЦП, графический процессор и ОЗУ, посредством прямых измерений, что позволяет точно оценить влияние программного и аппаратного обеспечения на поведение отдельных компонентов. [21]

Проверка модели мощности посредством тепловых измерений

[ редактировать ]

Одной из задач разработчиков аппаратного и программного обеспечения является проверка данных моделирования эмпирическими данными. Им требуется какая-то утилита или инструмент для измерения энергопотребления и сравнения с данными моделирования. Одним из таких методов сбора данных в реальном времени для проверки энергетических или тепловых моделей является установка для инфракрасных измерений, разработанная Ф. Дж. Меса-Мартинесом, Дж. Найфач-Баттиланой и Дж. Ренау из Калифорнийского университета в Санта-Крус. Их подход заключается в создании тепловых карт с помощью инфракрасных камер с высоким пространственным разрешением и высокой частотой кадров. Затем генетический алгоритм находит уравнение мощности для каждого блока процессора, которое создает тепловую карту захвата, чтобы предоставить подробную информацию о пробое мощности (утечке и динамике). [22] Они также разработали фильтр обработки изображения для повышения точности теплового изображения. Самой большой проблемой при использовании этого подхода является получение подробной карты мощности на основе тепловых измерений. Между измеренной информацией и мощностью нет прямой связи. Был разработан генетический алгоритм, описанный в ссылке [22] который повторяет несколько тепловых трасс и сравнивает их с результатами теплового симулятора, чтобы найти наилучшую корреляцию мощности.

Первым шагом является измерение температуры с помощью ИК-камеры и внутри масляной охлаждающей жидкости, которая течет по верхней части поверхности чипа. Подробная информация о настройке описана в ссылке. [22] Масло выбирают из-за простоты моделирования и точности. Инфракрасные камеры должны быть откалиброваны для компенсации теплового излучения различных материалов, конфигураций объективов и других ориентировочных факторов. [22] Второй фильтр также применяется для компенсации оптических искажений, вызванных настройкой объектива. В этом подходе требуется очень точная тепловая модель для точного учета эффектов установки жидкостного охлаждения. Уравнения модели описаны в ссылке. [22]

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

Заключение

[ редактировать ]

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

  1. ^ Мадж, Т. (апрель 2001 г.). «Мощность: первоклассное ограничение архитектурного дизайна». Компьютер . 34 (4): 52–58. CiteSeerX   10.1.1.646.2818 . дои : 10.1109/2.917539 .
  2. ^ Jump up to: а б с д и ж г час Сингх, Каран; Бхадаурия, майор; Макки, Салли А. (23 июля 2009 г.). «Оценка мощности в реальном времени и планирование потоков с помощью счетчиков производительности». Новости компьютерной архитектуры ACM SIGARCH . 37 (2): 46. CiteSeerX   10.1.1.141.1881 . дои : 10.1145/1577129.1577137 . S2CID   14453831 .
  3. ^ Jump up to: а б Ли, Тао; Джон, Лизи Куриан (10 июня 2003 г.). «Моделирование во время выполнения и оценка энергопотребления операционной системы». Обзор оценки производительности ACM SIGMETRICS . 31 (1): 160. CiteSeerX   10.1.1.14.3803 . дои : 10.1145/885651.781048 .
  4. ^ Jump up to: а б с д и ж г час я дж к л м н Сан, Ваннер и Шривастава, Ювен, Лукас и Мани. «Недорогая оценка мощности подсистемы» (PDF) . {{cite web}}: CS1 maint: несколько имен: список авторов ( ссылка ) [ постоянная мертвая ссылка ]
  5. ^ Чо, Ёнджин; Ёнхён Ким; Парк Санёнг; Нэхёк Чанг (2008). Оценка мощности на уровне системы с использованием встроенного блока мониторинга производительности шины . Иккад '08. стр. 149–154. ISBN  9781424428205 .
  6. ^ Jump up to: а б с д и ж г час я Контрерас, Г.; Мартоноси (8–10 августа 2005 г.). «Прогнозирование мощности для процессоров Intel XScale/SPL reg/ с использованием событий блока мониторинга производительности». ИСЛПЕД '05. Материалы Международного симпозиума по маломощной электронике и дизайну 2005 г., 2005 г. стр. 221–226. дои : 10.1109/LPE.2005.195518 . ISBN  978-1-59593-137-5 .
  7. ^ Уивер, В.М.; Макки, ЮАР (30 сентября 2008 г.). «Можно ли доверять аппаратным счетчикам производительности?». Международный симпозиум IEEE 2008 г. по характеристикам рабочей нагрузки . стр. 141–150. CiteSeerX   10.1.1.620.9917 . дои : 10.1109/IISWC.2008.4636099 . ISBN  978-1-4244-2777-2 . S2CID   14399141 .
  8. ^ Сингх, Дигвиджай; Кайзер, У. Дж. (26 мая 2010 г.). «Платформа Atom LEAP для энергоэффективных встраиваемых вычислений» . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь )
  9. ^ «Qualcomm. Платформа разработки мобильных устройств Snapdragon MSM8660. Доступно по адресу» .
  10. ^ Jump up to: а б с д и ж г час я дж Ханг, Ли; Пу Лю; Чжэньюй Ци; Линлин Джин; Вэй Ву; Тан, SXD; Цзюнь Ян (31 октября 2005 г.). «Эффективное тепловое моделирование для отслеживания и управления температурой во время работы». 2005 Международная конференция по компьютерному дизайну . стр. 130–133. CiteSeerX   10.1.1.114.7660 . дои : 10.1109/ICCD.2005.46 . ISBN  978-0-7695-2451-1 . S2CID   10154370 .
  11. ^ Ложь, Пу; Чжэньюй Ци; Ханг Ли; Линлин Джин; Вэй Ву; СХ-Д. Затем; Цзюнь Ян (2005). Быстрое тепловое моделирование для динамического управления температурным режимом на уровне архитектуры . Иккад '05. стр. 639–644. ISBN  9780780392540 . {{cite book}}: |journal= игнорируется ( помогите )
  12. ^ Брукс, Д.; Мартоноси, М. (7 августа 2002 г.). «Динамическое управление температурным режимом для высокопроизводительных микропроцессоров». Материалы Седьмого международного симпозиума HPCA по архитектуре высокопроизводительных компьютеров . стр. 171–182. CiteSeerX   10.1.1.590.1583 . дои : 10.1109/HPCA.2001.903261 . ISBN  978-0-7695-1019-4 . S2CID   1054852 .
  13. ^ Хуан, Вэй; Мирча Р. Стани; Кевин Скадронц; Картик Шанкаранараянан (апрель 2004 г.). «Компактное тепловое моделирование для проектирования с учетом температуры» (PDF) . 2004 . Архивировано из оригинала (PDF) 16 июня 2012 г.
  14. ^ Jump up to: а б с д и ж г час Чжан, Лиде; Бирджод Тивана; Чжиюнь Цянь; Чжаогуан Ван; Роберт П. Дик; Чжуоцин Морли Мао ; Лей Ян (2010). «Точная онлайн-оценка мощности и автоматическое создание модели питания смартфонов на основе поведения батареи». Материалы восьмой международной конференции IEEE/ACM/IFIP по кодированию аппаратного и программного обеспечения и синтезу систем - CODES/ISSS '10 . п. 105. дои : 10.1145/1878961.1878982 . ISBN  9781605589053 . S2CID   1458775 .
  15. ^ Юн, Чанмин; Ким, Донвон; Юнг, Вону; Канг, Чулку; Ча, Ходжунг. «AppScope: платформа измерения энергопотребления приложений для смартфонов Android с использованием мониторинга активности ядра» (PDF) .
  16. ^ Юнг, Вону; Канг, Чулку; Юн, Чанмин; Ким, Донвон; Ча, Ходжунг (2012). «DevScope: неинтрузивный онлайн-инструмент для анализа энергопотребления аппаратных компонентов смартфона». Материалы восьмой международной конференции IEEE/ACM/IFIP по проектированию кода аппаратного и программного обеспечения и синтезу систем . стр. 353–362. дои : 10.1145/2380445.2380502 . ISBN  9781450314268 . S2CID   18828989 .
  17. ^ «Программный инструмент Intel Power Gadget» . 08.10.2018.
  18. ^ Jump up to: а б с д и ж Кансал, Аман; Фэн Чжао; Цзе Лю; Нупур Котари; Арка А. Бхаттачарья (2010). «Учет и обеспечение мощности виртуальных машин». Материалы 1-го симпозиума ACM по облачным вычислениям — SoCC '10 . п. 39. дои : 10.1145/1807128.1807136 . ISBN  9781450300360 . S2CID   12234071 .
  19. ^ Jump up to: а б с д Макинтайр, Дастин; Кей Хо; Берни Йип; Амарджит Сингх; Уинстон Ву; Уильям Дж. Кайзер (2006). «Встроенная сетевая сенсорная система обработки данных с низким энергопотреблением (LEAP)» . Материалы пятой международной конференции «Обработка информации в сенсорных сетях» - IPSN '06 . п. 449. дои : 10.1145/1127777.1127846 . ISBN  978-1595933348 . S2CID   3157391 .
  20. ^ Флинн и Сатьянараянан, Дж. и М. (6 августа 2002 г.). «PowerScope: инструмент для профилирования энергопотребления мобильных приложений». Труды WMCSA'99. Второй семинар IEEE по мобильным вычислительным системам и приложениям . стр. 2–10. CiteSeerX   10.1.1.46.6876 . дои : 10.1109/MCSA.1999.749272 . ISBN  978-0-7695-0025-6 . S2CID   10256882 .
  21. ^ Махсан Рофуэй, ТаСтатопулос, Риффель, Кайзер и Саррафзаде, Махсан, Танос, Уильям, Маджид (2008). «Высокопроизводительные вычисления с учетом энергопотребления с графическими процессорами» (PDF) . {{cite journal}}: Для цитирования журнала требуется |journal= ( помощь ) CS1 maint: несколько имен: список авторов ( ссылка )
  22. ^ Jump up to: а б с д и Меса-Мартинес, Франсиско Хавьер; Найфач-Баттилана, Йозеф; Ренау, Хосе (9 июня 2007 г.). «Проверка модели мощности посредством тепловых измерений». Новости компьютерной архитектуры ACM SIGARCH . 35 (2): 302. дои : 10.1145/1273440.1250700 .
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: a1d6384a7b2c8931cd7ee45516519d63__1706128560
URL1:https://arc.ask3.ru/arc/aa/a1/63/a1d6384a7b2c8931cd7ee45516519d63.html
Заголовок, (Title) документа по адресу, URL1:
Run-time estimation of system and sub-system level power consumption - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)