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

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

Измерение рассеиваемой мощности в реальном времени имеет решающее значение при термическом анализе новой конструкции аппаратных процессоров (ЦП), а также для программистов ОС, пишущих планировщики процессов. ^{[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]

${\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}}}$

Можно также оценить энергопотребление памяти (внешней оперативной памяти), отслеживая события производительности, если они доступны на разработанном процессоре. ^[6] Например, процессор PXA255 не имеет прямых событий производительности, учитывающих внешнюю оперативную память, но промахи кэша инструкций, промахи кэша данных и количество зависимостей данных на процессоре могут быть использованы для оценки энергопотребления памяти. Опять же, линейная модель выводится из заданной информации (уравнение 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 benchmark suits. Этот метод был разработан для анализа влияния общих ресурсов и температуры на энергопотребление для чиповых мультипроцессоров. ^[2]

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

${\displaystyle {{P}_{core}}=\left\{{\begin{matrix}{{F}_{1}}\left({{g}_{1}}\left({{r}_{1}}\right),\ldots \ldots ,{{g}_{n}}\left({{r}_{n}}\right)\right),if{\text{ }}condition\\{{F}_{2}}\left({{g}_{1}}\left({{r}_{1}}\right),\ldots \ldots ,{{g}_{n}}\left({{R}_{n}}\right)\right),else\\\end{matrix}}\right.}$(3)

Где (4) ${\displaystyle {{r}_{i}}={{\varepsilon }_{i}}/(cycle{\text{ }}count)}$ ${\displaystyle {{F}_{n}}={{P}_{0}}+{{P}_{1}}*{{g}_{1}}\left({{r}_{1}}\right)+\ldots \ldots +{{P}_{2}}*{{g}_{n}}({{r}_{n}})}$

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

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

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

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

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

Большинство моделей, подобных вышеприведенным, не имеют возможности измерять энергопотребление на уровне компонентов или подсистем. DiPART (Disaggregated Power Analysis in Real Time), разработанный профессором М. Шриваставой, Й. Саном и Л. Ваннером из Калифорнийского университета в Лос-Анджелесе, позволяет использовать эту возможность для оценки энергопотребления на основе счетчиков производительности оборудования и использования только одного датчика мощности для всей системы. ^[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{ }}of{\text{ }}CPU{\text{ }}performance{\text{ }}Counters+{{\lambda }_{constantCPU}}}$ (6) ^[4]

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

${\displaystyle {{P}_{RAM}}=\left[{\text{ }}\!\!\Delta \!\!{\text{ }},{\text{ }}\!\!\Gamma \!\!{\text{ }},\ldots {\text{ }}\!\!\Theta \!\!{\text{ }}\right]*{\text{ }}Vector{\text{ }}of{\text{ }}Performance{\text{ }}Counters+{{\lambda }_{constantRAM}}}$(7) ^[4]

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

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

${\displaystyle {{P}_{Disk}}=\left[\varphi ,\chi \right]*{\text{ }}Vector{\text{ }}of{\text{ }}Disk{\text{ }}performance{\text{ }}counter+{{\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] Существует прямая корреляция между наблюдением и изменениями температуры. Этот новый метод стал решением для замены старых технологий, таких как датчики отслеживания в режиме реального времени на чипе, такие как технология датчиков на основе КМОП, которые менее точны и требуют аппаратной реализации. ^[12]

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

${\displaystyle Gx+Cx=Bu}$(9)

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

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

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

PowerBooter и PowerTutor

Эта методика моделирования мощности была разработана в сотрудничестве между L. Zhang, B. Tiwana, Z. Qian, Z. Wang, RP Dick, Z. Mao из Мичиганского университета и L. Yang из Google Inc. для точной оценки оценки мощности в режиме онлайн для смартфонов. ^[14] PowerBooter — это автоматизированная модель мощности, которая использует встроенные датчики напряжения батареи и поведение батареи во время разряда для мониторинга энергопотребления всей системы. Этот метод не требует какого-либо специального внешнего измерительного оборудования. PowerTutor также является инструментом измерения мощности, который использует данные, сгенерированные PowerBooter, для онлайн-оценки мощности. Всегда существует ограничение в сроке службы батареи смартфонов , которое необходимо преодолеть разработчикам HW и SW. Разработчики программного обеспечения не всегда обладают наилучшими знаниями о потреблении энергии для разработки более оптимизированных по энергопотреблению приложений, поэтому конечные пользователи всегда винят срок службы батареи. Поэтому необходим инструмент, который имеет возможность измерять потребление энергии на смартфонах, которое разработчики программного обеспечения могли бы использовать для мониторинга своих приложений в режиме реального времени. Исследователи разработали специальные модели управления питанием для определенных портативных встраиваемых систем, и требуются огромные усилия, чтобы повторно использовать эти модели для огромного разнообразия современных технологий смартфонов . Поэтому решением этой проблемы является модель 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] В качестве метрики для характеристики производительности современных процессоров можно использовать команду за цикл (IPC). В статье ^[14] показано, как различные компоненты в ЦП и системах памяти вносят вклад в общую мощность подпрограммы ОС. Структура пути данных и конвейера вместе с часами потребляют больше всего энергии. Из IPC можно вывести линейную модель, которая отслеживает мощность подпрограммы ОС. Для оценки энергопотребления заданной части программного обеспечения можно использовать простое уравнение энергии, где P — средняя мощность, а T — время выполнения этой программы. ${\displaystyle E=P*T}$

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

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

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

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

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

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

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

Встроенная сенсорная система с низким энергопотреблением Energy Aware Processing

LEAP (Low Power Energy Aware Processing) была разработана D. McIntire, K. Ho, B. Yip, A. Singh, W. Wu и WJ Kaiser в Калифорнийском университете в Лос-Анджелесе, чтобы убедиться, что встроенные сетевые сенсорные системы оптимизированы по энергопотреблению для своих приложений. Система 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 также предоставляет информацию о мощности отдельных подсистем, таких как CPU, GPU и RAM, посредством прямого измерения, тем самым позволяя точно оценивать влияние программного и аппаратного обеспечения на поведение мощности отдельных компонентов. ^[21]

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

Одной из проблем для разработчиков HW или SW является проверка данных моделирования с помощью эмпирических данных. Им требуется некоторая утилита или инструмент для измерения энергопотребления и сравнения с данными моделирования. Одним из таких методов сбора данных в реальном времени для проверки моделей мощности или тепла является инфракрасная измерительная установка, разработанная FJ Mesa-Martinez, J. Nayfach-Battilana и J. Renau из Калифорнийского университета в Санта-Крузе. Их подход заключается в захвате тепловых карт с помощью инфракрасных камер с высоким пространственным разрешением и высокой частотой кадров. Затем генетический алгоритм находит уравнение мощности для каждого блока процессора, который создает тепловую карту захвата, чтобы предоставить подробную информацию о разбивке мощности (утечка и динамика). ^[22] Они также разработали фильтр обработки изображений для повышения точности теплового изображения. Самая большая проблема для этого подхода заключается в получении подробной карты мощности из тепловых измерений. Прямого сопоставления между измеренной информацией и мощностью нет. Был разработан генетический алгоритм, описанный в ссылке ^[22] , который итерирует несколько тепловых трасс и сравнивает их с результатами теплового симулятора, чтобы найти наилучшую корреляцию мощности.

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

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

Заключение

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

Ссылки

1. Mudge, T. (апрель 2001 г.). «Мощность: ограничение архитектурного дизайна первого класса». Computer . 34 (4): 52–58. CiteSeerX  10.1.1.646.2818 . doi :10.1109/2.917539.
2. Сингх, Каран; Бхадаурия, Мейджор; Макки, Салли А. (23 июля 2009 г.). «Оценка мощности в реальном времени и планирование потоков с помощью счетчиков производительности». ACM SIGARCH Computer Architecture News . 37 (2): 46. CiteSeerX 10.1.1.141.1881 . doi :10.1145/1577129.1577137. S2CID  14453831. 
3. Li, Tao; John, Lizy Kurian (10 июня 2003 г.). "Моделирование во время выполнения и оценка энергопотребления операционной системы". ACM SIGMETRICS Performance Evaluation Review . 31 (1): 160. CiteSeerX 10.1.1.14.3803 . doi :10.1145/885651.781048. 
4. Сан, Ваннер и Шривастава, Ювен, Лукас и Мани. «Малозатратная оценка мощности подсистемы» (PDF) .{{cite web}}: CS1 maint: multiple names: authors list (link)^{[ постоянная мертвая ссылка ]}
5. Чо, Юнгджин; Юнгхён Ким; Сангёнг Парк; Наехёк Чан (2008). Оценка мощности на уровне системы с использованием встроенного блока мониторинга производительности шины. Iccad '08. С. 149–154. ISBN 9781424428205.
6. Contreras, G.; Martonosi (8–10 августа 2005 г.). «Прогнозирование мощности для процессоров Intel XScale/SPL reg/ с использованием событий блока мониторинга производительности». ISLPED '05. Труды Международного симпозиума 2005 г. по маломощной электронике и проектированию, 2005 г. стр. 221–226. doi :10.1109/LPE.2005.195518. ISBN 978-1-59593-137-5.
7. Weaver, VM; McKee, SA (30 сентября 2008 г.). «Можно ли доверять счетчикам производительности оборудования?». 2008 IEEE International Symposium on Workload Characterization . стр. 141–150. CiteSeerX 10.1.1.620.9917 . doi :10.1109/IISWC.2008.4636099. ISBN  978-1-4244-2777-2. S2CID  14399141.
8. Сингх, Дигвиджай; Кайзер, В. Дж. (2010-05-26). «Платформа Atom LEAP для энергоэффективных встраиваемых вычислений». {{cite journal}}: Цитировать журнал требует |journal=( помощь )
9. "Qualcomm. Платформа разработки мобильных устройств Snapdragon MSM8660. Доступно на".
10. Ханг, Ли; Пу Лю; Чжэньюй Ци; Линлин Джин; Вэй Ву; Тан, 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 . doi :10.1109/HPCA.2001.903261. ISBN  978-0-7695-1019-4. S2CID  1054852.
13. Хуан, Вэй; Мирча Р. Стани; Кевин Скадронц; Картик Санкаранараянан (апрель 2004 г.). "Компактное тепловое моделирование для проектирования с учетом температуры" (PDF) . 2004. Архивировано из оригинала (PDF) 2012-06-16.
14. Чжан, Лидэ; Бирджодх Тивана; Чжиюнь Цянь; Чжаогуан Ван; Роберт П. Дик; Чжуоцин Морли Мао ; Лей Ян (2010). "Точная оценка мощности в режиме онлайн и автоматическое поведение батареи на основе генерации модели мощности для смартфонов". Труды восьмой международной конференции IEEE/ACM/IFIP по аппаратному и программному кодированию и синтезу систем - CODES/ISSS '10 . стр. 105. doi :10.1145/1878961.1878982. ISBN 9781605589053. S2CID  1458775.
15. Юн, Чанмин; Ким, Донвон; Чон, Вонву; Кан, Чулку; Ча, Ходжунг. «AppScope: инфраструктура измерения энергопотребления приложений для смартфонов Android с использованием мониторинга активности ядра» (PDF) .
16. Jung, Wonwoo; Kang, Chulkoo; Yoon, Chanmin; Kim, Dongwon; Cha, Hojung (2012). "DevScope: неинвазивный и онлайновый инструмент анализа мощности для аппаратных компонентов смартфона". Труды восьмой международной конференции IEEE/ACM/IFIP по аппаратному/программному кодированию и синтезу систем . стр. 353–362. doi :10.1145/2380445.2380502. ISBN 9781450314268. S2CID  18828989.
17. "Программное обеспечение Intel Power Gadget Tool". 2018-10-08.
18. Кансал, Аман; Фэн Чжао; Цзе Лю; Нупур Котари; Арка А. Бхаттачарья (2010). "Учет и обеспечение мощности виртуальных машин". Труды 1-го симпозиума ACM по облачным вычислениям - SoCC '10 . стр. 39. doi :10.1145/1807128.1807136. ISBN 9781450300360. S2CID  12234071.
19. Макинтайр, Дастин; Кей Хо; Берни Йип; Амарджит Сингх; Уинстон Ву; Уильям Дж. Кайзер (2006). "Встроенная сетевая сенсорная система с низким энергопотреблением (LEAP)". Труды пятой международной конференции по обработке информации в сенсорных сетях - IPSN '06. стр. 449. doi :10.1145/1127777.1127846. ISBN 978-1595933348. S2CID  3157391.
20. Flinn, и Satyanarayanan, J. и M. (6 августа 2002 г.). "PowerScope: инструмент для профилирования энергопотребления мобильных приложений". Труды WMCSA'99. Второй семинар IEEE по мобильным вычислительным системам и приложениям . стр. 2–10. CiteSeerX 10.1.1.46.6876 . doi :10.1109/MCSA.1999.749272. ISBN  978-0-7695-0025-6. S2CID  10256882.
21. Махсан Рофуэй, ТаСтатопулос, Риффель, Кайзер и Саррафзаде, Махсан, Танос, Уильям, Маджид (2008). «Энергосберегающие высокопроизводительные вычисления с графическими процессорами» (PDF) . {{cite journal}}: Цитировать журнал требует |journal=( помощь )CS1 maint: multiple names: authors list (link)
22. Меса-Мартинес, Франсиско Хавьер; Найфач-Баттилана, Йозеф; Ренау, Хосе (9 июня 2007 г.). «Проверка модели мощности посредством тепловых измерений». Новости компьютерной архитектуры ACM SIGARCH . 35 (2): 302. дои : 10.1145/1273440.1250700.