Оценка энергопотребления на уровне системы и подсистемы во время выполнения - Run-time estimation of system and sub-system level power consumption

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

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

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

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

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

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

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

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

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

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

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

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

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

${ displaystyle Powe {{r} _ {cpu}} = {{ propto} _ {1}} left (IFetc {{h} _ {miss}} right) + {{ propto} _ {2} } left (DataDep right) + {{ propto} _ {3}} left (DataTL {{B} _ {miss}} right) + {{ propto} _ {4}} left (InsTL {{B} _ {miss}} right) + {{ propto} _ {5}} left (InstExec right) + {{K} _ {cpu}}}$ (1)

Где, ${ displaystyle {{ propto} _ {1}}, {{ propto} _ {2}}, {{ propto} _ {3}}, {{ propto} _ {4}}, {{ propto} _ {5}}}$ силовые веса и ${ displaystyle {{K} _ {cpu}}}$ константа для энергопотребления процессора во время простоя.

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

${ displaystyle Powe {{r} _ {memory}} = {{ beta} _ {1}} left (IFetc {{h} _ {miss}} right) + {{ beta} _ {2} } left (DataDep right) + {{K} _ {memory}}}$ (2)

Где, ${ displaystyle {{ beta} _ {1}}, {{ beta} _ {2}}}$ силовые веса и ${ displaystyle {{K} _ {memory}}}$ - постоянная потребляемая мощность во время простоя.

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

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

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

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

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

В этом методе использовались 4 счетчика производительности процессора AMD Phenom. Счетчики производительности следующие: ${ displaystyle {{{ text {}} ! ! varepsilon ! ! { text {}}} _ {1}}}$: L2_CACHE_MISS: ВСЕ, ${ displaystyle {{{ text {}} ! ! varepsilon ! ! { text {}}} _ {2}}}$: RETRIED_UOPS, ${ displaystyle {{{ text {}} ! ! varepsilon ! ! { text {}}} _ {3}}}$: RETIRED_MMX_AND_FP_INSTRUCTIONS: ВСЕ, ${ displaystyle {{{ text {}} ! ! varepsilon ! ! { text {}}} _ {4}}}$: DISPATCH_STALLS. Эти счетчики производительности архитектурно специфичны для AMD Phenom и могут отличаться для других процессоров. AMD позволяет одновременно собирать данные с этих четырех HPC.^[2] Небольшая программа Microbenchmarks пытается собрать данные из выбранных выше высокопроизводительных вычислений. Собранные данные по каждому ядру процессора используются в следующем уравнении.^[2]

${ displaystyle {{P} _ {core}} = left {{ begin {matrix} {{F} _ {1}} left ({{g} _ {1}} left ({{r } _ {1}} right), ldots ldots, {{g} _ {n}} left ({{r} _ {n}} right) right), если { text {}} условие {{F} _ {2}} left ({{g} _ {1}} left ({{r} _ {1}} right), ldots ldots, {{g} _ {n}} left ({{R} _ {n}} right) right), иначе end {matrix}} right.}$ (3)

Где ${ displaystyle {{r} _ {i}} = {{ varepsilon} _ {i}} / (количество циклов { text {}})}$${ displaystyle {{F} _ {n}} = {{P} _ {0}} + {{P} _ {1}} * {{g} _ {1}} left ({{r} _ {1}} right) + ldots ldots + {{P} _ {2}} * {{g} _ {n}} ({{r} _ {n}})}$ (4)

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

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

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

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

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

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

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

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

${ displaystyle {{P} _ {system}} = {{P} _ {CPU}} + {{P} _ {RAM}} + {{P} _ {Disk}}}$ (5)^[4]

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

${ displaystyle {{P} _ {CPU}} = left [ propto, beta, ldots gamma right] * Vecor { text {}} процессора { text {}} { text {} } счетчики производительности { text {}} + {{ lambda} _ {constantCPU}}}$ (6)^[4]

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

${ displaystyle {{P} _ {RAM}} = left [{ text {}} ! ! Delta ! ! { text {}}, { text {}} ! ! Гамма ! ! { Text {}}, ldots { text {}} ! ! Theta ! ! { Text {}} right] * { text {}} Вектор { text {}} счетчиков производительности { text {}} { text {}} + {{ lambda} _ {constantRAM}}}$ (7)^[4]

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

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

${ displaystyle {{P} _ {Disk}} = left [ varphi, chi right] * { text {}} Вектор { text {}} из { text {}} диска { text { }} счетчик производительности { text {}} + {{ lambda} _ {constantDisk}}}$ (8)^[4]

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

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

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

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

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

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

Новый метод был разработан H. Li, P. Liu, Z. Qi, L. Jin, W. Wu, SXD Tan, J. Yang из Калифорнийского университета в Риверсайде, основанный на наблюдении за средней потребляемой мощностью модулей низкого уровня, работающих в типичных условиях. нагрузка.^[10] Существует прямая корреляция между наблюдением и колебаниями температуры. Этот новый метод был решением для замены старых технологий, таких как датчики онлайн-отслеживания на чипе, такие как технология датчиков на основе CMOS, которые менее точны и требуют аппаратной реализации.^[12]

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

${ displaystyle Gx + Cx = Bu}$ (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] Первая сложная идея - преобразовать показания напряжения батареи в потребляемую мощность. Это определяется изменением состояния разряда (которое представляет собой общую потребляемую батареей энергии) в пределах интервала тестирования, регистрируемого датчиками напряжения, которые в конечном итоге будут управлять следующим уравнением.

${ displaystyle P * left ({{t} _ {1}} - {{t} _ {2}} right) = E * (SOD left ({{V} _ {1}} right) -SOD left ({{V} _ {2}} right))}$ (10)

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

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

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

Appscope^[15] и DevScope^[16] похожи работы для оценки Смартфон потребляемая мощность.

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

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

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

Целевая оценка мощности во время выполнения требует линейной операции первого порядка с одним показателем мощности, что снижает накладные расходы на оценку.^[14] Instruction per Cycle (IPC) может использоваться в качестве метрики для характеристики производительности современных процессоров. В бумаге^[14] показывает, как различные компоненты ЦП и систем памяти влияют на общую производительность ОС. Канал передачи данных и структура конвейера вместе с часами потребляют больше всего энергии. Линейная модель может быть получена из IPC, которая отслеживает мощность рутинной работы ОС. Простое уравнение энергии ${ displaystyle E = P * T}$ может использоваться для оценки энергопотребления данной части программного обеспечения, где P - средняя мощность, а T - время выполнения этой программы.

Сложная часть - вычислить среднюю мощность P для каждой отдельной процедуры операционной системы. Можно использовать корреляцию между стандартной средней мощностью IPC и ОС или использовать аппаратные счетчики производительности. Метод профилирования (данные, полученные в результате тестирования производительности) также можно использовать для прогнозирования энергопотребления. Модель линейной мощности в^[14] как следует:${ displaystyle {{P} _ {OS}} = {{K} _ {1}} * { text {}} IP {{C} _ {OS}} + {{K} _ {0}}}$. Это простая линейная модель, которая показывает сильную корреляцию между мощностью IPC и операционной системой. В этом подходе профилирование также требуется для создания данных, необходимых для построения модели. После создания модели для одной системы она больше не нужна для той же системы.

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

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

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

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

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

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

Встроенная сенсорная система с обработкой данных с низким энергопотреблением

The LEAP (Low Power Energy Aware Processing) has been developed by D. McIntire, K. Ho, B. Yip, A. Singh, W. Wu, and W.J. Kaiser at University of California Los Angeles to make sure the embedded network sensor systems are energy optimized for their applications. The LEAP system as described in reference^[19] offers a detailed energy dissipation monitoring and sophisticated power control scheduling for all subsystems including the sensor systems. LEAP is a multiprocessor architecture based on hardware and software system partitioning. It is an independent energy monitoring and power control method for each individual subsystem. The goal of LEAP is to control microprocessors to achieve the lowest per task operating energy. Many modern embedded networked sensors are required to do many things like image processing, statistical high performance computing and communication. To make sure all of these applications are working efficiently a real-time energy monitoring and scheduling feature is required and LEAP can offer this feature for those systems.

LEAP (ENS) system was designed to offer high accuracy and low overhead energy measurement capability. LEAP enables energy aware applications through scheduling and energy profiling of high energy efficiency components including multiple wireless network interfaces, storage elements, and sensing capabilities.^[19] The biggest advantage of LEAP system is its Energy Management and Preprocessing (EMAP) capability. The experimental results shows that the optimal choice of sensor systems, processor, wireless interface, and memory technology is not application dependent but it could be hardware allocation issue. EMAP has the capability to partition devices into many power domains with the capability to monitor, enable or disable power to each domain, as well as to respond to trigger events or conditions that restore or remove power in each domain. EMAP collects data periodically and transfers them to the host process and power management schedule is then provided by host processor to EMAP.

Figure 1 in reference^[19] shows the LEAP architecture and EMAP architecture. The LEAP and EMAP are complex platforms which require hardware and software. All of the detailed design approaches are described in reference.^[19]

In conclusion, LEAP differs from previous methods like PowerScope^[20] because it provides both real-time power consumption information and a standard application execution environment on the same platform. As a result, LEAP eliminates the need for synchronization between the device under test and an external power measurement unit. LEAP also provides power information of individual subsystems, such as CPU, GPU and RAM, through direct measurement, thereby enabling accurate assessments of software and hardware effects on the power behavior of individual components.^[21]

Power model validation through thermal measurements

One of the challenges for HW or SW designers is to validate their simulation data with empirical data. They require some type of utility or tool to measure power consumption and compare with their simulation data. One of these methods to capture real time data to validate power or thermal models is an infrared measurement setup developed by F.J. Mesa-Martinez, J.Nayfach-Battilana and J. Renau at University of California Santa Cruz. Their approach is to capture thermal maps using infrared cameras with high spatial resolution and high frame rate. Then a genetic algorithm finds a power equation for each floorplan block of processor that produces the capture thermal map to give detailed information about power breakdown (leakage and dynamic).^[22] They also developed an image processing filter to increase the thermal image accuracy. The biggest challenge for this approach is to obtain a detailed power map from the thermal measurements. There is no direct mapping between measured information and power. A genetic algorithm was developed described in reference^[22] that iterates multiple thermal traces and compares them with the results from thermal simulator to find the best power correlation.

The first step is to measure the temperature using IR camera and within the oil coolant that flows over the top of the chip surface, the detailed setup information is described in reference.^[22] Oil is chosen because of ease in modeling and accuracy. The infrared cameras must be calibrated to compensate for different material thermal emissions, lens configurations, and other factors in reference.^[22] A second filter is also applied to compensate for the optical distortion induced by lens setup. A very accurate thermal model is required in this approach to account for effects of the liquid cooling setup accurately. The model equations are described in reference.^[22]

Designers can use this method to validate their simulation or optimize their design especially because this method provides the breakdown information about leakage and dynamic power consumption. This method is also helpful in chip packaging design, heat sink, and cooling system. This method also shows designers which part of floorplan blocks propagates heat faster or slower.

Вывод

Estimating power consumption is critical for hardware, software developers, and other computing system users like Internet companies to save energy or to optimize their HW/SW to be more energy efficient. It is also critical because one can use the available resources accordingly. Simulators are only good during design but their estimation also needs to be verified. Simulators in general have high errors due to manufacturing of hardware components. Power meters measure power consumption for the whole system but does not give detailed breakdowns about dissipated power so designers can optimize their application or hardware. This paper analyzed different methods that researchers have discovered in recent years to resolve some of the issues above.

Рекомендации