Профилирование энергопотребления виртуальных машин

Размещено на http://www.allbest.ru//

Размещено на http://www.allbest.ru//

Министерство образования и науки Российской Федерации

МОСКОВСКИЙ ФИЗИКО-ТЕХНИЧЕСКИЙ ИНСТИТУТ

(государственный университет)

ФАКУЛЬТЕТ УПРАВЛЕНИЯ И ПРИКЛАДНОЙ МАТЕМАТИКИ

КАФЕДРА ТЕОРЕТИЧЕСКОЙ И ПРИКЛАДНОЙ ИНФОРМАТИКИ

Специализация 010956 «Математические и информационные технологии»

Магистерская диссертация

Профилирование энергопотребления виртуальных машин

студента 873 группы

Карпова Дмитрия Викторовича

Научный руководитель

Мелехова А.Л.

г. Долгопрудный 2014

Глоссарий

Понятие	Сокращение	Определение понятия
Виртуальное окружение		изолированная среда для исполнения системного программного обеспечения и прикладного программного обеспечения клиента
Хостинг		предоставление аппаратных и системных ресурсов клиенту
Гостевая операционная система	гостевая ОС	системное программное обеспечение запущенное внутри виртуального окружения
Ядро операционной системы	ядро ОС	центральная программа операционной системы (ОС), обеспечивающая приложениям координированный доступ к ресурсам
Модуль ядра операционной системы	модуль ядра ОС	программа, содержащая код, расширяющий возможности ядра операционной системы, исполняемая, как и ядро ОС, в привелегированном режиме
Хостовая операционная система	хостовая ОС	системное программное обеспечение, в котором работает программное обеспечение виртуализации
Монитор виртуальных машин		Программное обеспечение, непосредственно создающее изолированные среды, запускающее виртуальное окружение и обеспечивающее получение ресурсов для виртуального окружения от гипервизора (хостовой ОС)
Гипервизор		Программное обеспечение, позволяющее одновременное исполнение нескольких виртуальных окружений на одной и той же физической машине (является выделенной частью хостовой ОС)
Миграция		перенос ИПР или виртуального окружения с ИПР с одного физического сервера на другой
Живая миграция		перенос ИПР или виртуального окружения с ИПР с одного физического сервера на другой без остановки работы ИПР
Горячая миграция		см. живая миграция
Архитектура микропроцессора		аппаратная организация и логическая структура микропроцессора, регистры, управляющие схемы, арифметико-логические устройства, запоминающие устройства и связывающие их информационные магистрали
Микроархитектура		способ, которым набор команд (инструкций) реализован в микропроцессоре
Ядро микропроцессора		часть микропроцессора, осуществляющая выполнение одного потока команд. Многоядерные микропроцессоры имеют несколько ядер и поэтому способны осуществлять независимое параллельное выполнение нескольких потоков команд одновременно
Архитектура микропроцессоров семейства x86	Архитектура x86, семейство микропроцессоров х86	архитектура микропроцессоров c одноимённым набором команд и правилами их исполнения, впервые реализованная вмикропроцессорах компании Intel
Платформа х86		аппаратная модель вычислительной системы на основе семейства микропроцессоров х86
Module Specific Register	MSR	Паравиртуализованные моделеспецифичные регистры
Регистры микропроцессора		специальные ячейки памяти, образующие сверхбыструю оперативную память внутри микропроцессора и расположенные физически внутри него
ACPI		усовершенствованный интерфейс управления конфигурацией и питанием платформы х86
Running Average Power Limit	RAPL	Скользящее среднее предельное значение мощности
RAPL - итерфейс		это специальный способ предоставления доступа к внутрипроцессорным датчикам мощности, включающий в себя определенный набор моделезависимых регистров микропроцессора, механизм доступа к ним и обработки их значений
Контекст исполнения программного модуля	Контекст исполнения	Каждый программный модуль связан с остальной частью программных модулей, выполняющих определенный круг задач и имеющих определенные уровни привелегий. Эта связь называется контекстом исполнения программного модуля.
Контекст процесса		состояние исполняемой программы (или программ), определяемое информационными структурами, значениями используемых регистров микропроцессора, значениями, хранимыми в специальных таблицах параметров процесса, текущими значениями переменных, а также содержимым стэков (специальной памяти) задачи и операционной системы, относящихся к данному процессу.
Переключение контекста		прекращения выполнения микропроцессором одной задачи (процесса) или контекста исполнения с сохранением всей необходимой информации и состояния, необходимых для последующего продолжения с прерванного места, и восстановления состояния другой задачи или контекста исполнения, к выполнению которой переходит микропроцессор.

Введение

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

1.Постановка задачи

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

Задача нахождения оптимального управления энергопотреблением виртуального окружения включала в себя следующие этапы:

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

1.1 Структура энергопотребления

В работе [30] было показано, что энергопотребление платформы можно структурировать, разделив его на две части:

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

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

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

1.2 Обзор средств и методик профилирования энергопотребления

Во многих работах [24] описывается использование Hardware Performance Counter для построения энергозатратной модели и расчета потребления энергии в системе. Там установлено, что целочисленные операции, операции с плавающей точкой, строб адреса и операции обращения к памяти сильно связаны с расходом энергии процессором. Также, в других работах [25] используются иные HPC для построения модели энергопотребления - число выполненных инструкции, промахи кэша и промахи tlb. Там также установлено, что IPC (instructions per cycle) сильно коррелирует с энергозатратами. Некоторые части ОС работают с постоянными энергозатратами, а затраты на другие части, например на планировщик и операции ввода-вывода, сильно зависят от IPC.

В [26] установлен метод вычисления энергопотребления отдельных задач. Для низкоуровневого анализа мощности и расхода энергии используются довольно точные средства, такие как Wattch и SimplePower.

Из высокоуровневого анализа есть средство pTopW (Process-Level Power Profiling Tool) для профилирования энергопотребления в Windows (на ее основе сделаны средства контроля энергопотребления - EnergyGuard и BatteryLife). pTopp - в Linux. pTopp и pTopW представляют информацию в реальном времени по потреблению энергии каждым процессом. Также они предоставляют API, с помощью которого любой процесс может определить, сколько энергии он потратил в предыдущий период времени. Там построена модель для измерения энергопотребления CPU, памяти, диска и сетевой карты. После измерения энергопотребления CPU, они делят его на каждый процесс, основываясь на отношении процессорного времени.

Есть средство CloudMonitor, которое также представляет информацию по энергопотреблению софта. Там строится модель оценки мощности, используя линейную регрессию.

В довольно большой работе [27] рассматривается майкрософтовское средство Joulemeter (http://research.microsoft.com/en-us/projects/joulemeter/) для измерения потребления энергии виртуальными машинами (и не только ими). Так как использование мощности процессором зависит от множества факторов, в качестве альтернативы они следят за активным и неактивным состоянием процессора, т.е. за загруженностью процессора U. Далее строят модель энергопотребления процессора как E_cpu = A * U + B, где A и B - постоянные параметры данной модели. Далее используют обучающий метод, основанный на линейной регрессии для оценки этих параметров. Для составления уравнений регрессии каждый ресурс (процессор, память и диск ) загружаются под контролируемой нагрузкой (workload). То есть когда загружается новая ВМ, использование ею ресурсов прослеживается в течение 200 секунд, и полученные данные используются в модели регрессии. Эта модель обучения хороша, когда энергозатраты есть линейная функция загруженности процессора. Но есть и другие случаи, поэтому в работе представлена улучшенная модель обучения с немного откорректированными уравнениями модели энергопотребления. В их подходе, они следят, когда виртуальная машина активна на процессоре. И количество используемой энергии вычисляется по формуле выше, во время периодов активности ВМ. Они пользуются тем фактом, что, например, гипервизор Hyper-V создает виртуальные процессоры, которые могут охватывать целый или дробную часть логического ядра, и передает специальные значения соответствующие этому, каждой ВМ. Также Hyper-V позволяет следить за использованием виртуальных процессоров из корневой ВМ с помощью его performance counters - Hyper-V Hypervisor Virtual Processor и Hyper-V Hypervisor Root Virtual Processor. Используя настройки гипервизора, которые соотносят виртуальные ядра с логическими, использование энергозатрат виртуальных процессоров может маппироваться (отображаться) на загруженность физических процессоров. Такие же данные доступны и для гипервизора Xen через Xentrace. Для данной конкретной загрузки процессора реальная используемая мощность может варьироваться в зависимости от типа используемой нагрузки (Workload). И различия могут быть довольно большими. Чтобы посмотреть на точность оценки используемой виртуальной машиной энергии, как мера точность используется разница между фактической мощностью физического сервера и суммой мощностей всех ВМ и idle server power usage. В этой работе для оценки параметров модели используется метод линейной регрессии, а в работе [28] используется метод построения модели, основанный на многомерных распределениях гаусса, превосходящий регрессионную модель, основанную на загруженности процессора, по точности более чем в 5 раз (как утверждают авторы). В данной работе представлен онлайн (в режиме реального времени) механизм предсказания энергопотребления в виртуализованной среде. Их система основана на модели, которая соотносит потребление мощности с системными метриками (IPC, частота доступа к памяти и д.р.) нагрузок, запущенных в ВМ. Эти метрики динамически собираются на уровне ВМ и пересылаются в модуль предсказания энергозатрат. Модель основана на Gaussian Mixture Models, использующей алгоритм обучения на небольшом количестве бенчмарков из SPEC_CPU2000. Они реализовали собственный performance counter manager внутри планировщика Xen для измерения IPC, MPC (memory accesses per cycle), CTPC (cache transactions per cycle) запущенных ВМ. Т.е. они динамически снимают эти метрики с каждого VCPU, когда они рассщедуливаются на физических cpu. Вся эта информация собирается приложением, сидящим в dom-0, группируется в метрические векторы и анализируется методом Gaussian Mixture Models (GMM), который состоит из набора распределений гаусса, используемых для нахождения всех возможных взаимодействий между собранными метриками. Далее у них представлен механизм, как эти метрики отображаются на реальное энергопотребление: идет тренировочная фаза, когда GMM работает на типичных бенчмарках, показывающих разные уровни взаимодействия метрик. Как только GMM сформирован, он используется для прогноза мощности в режиме реального времени.

В [29] приводится характеристика всех известных методов power profiling. Перечислено большое количество софтварных и хардварных методов. Но для виртуализации там ничего нового нет, кроме того что уже перечислено выше.

1.3 Устройство техник профилирования энергопотребления

Известно, что наибольший вклад в энергопотребление платформы вносит процессор. В связи с этим компании Intel, Microsoft и некоторые другие представили свои средства измерения мощности. Каждое из них собирает различные данные разными способами. Для начала стоит немного сказать об основных аппаратных средствах измерения энергопотребления, предоставляемых платформой. В их число входят MSR (Model-Specific Registers) и HPC (Hardware Performance Counters). Со встроенных в оборудование датчиков и счетчиков HPC собираются данные для определения того, какие события сильно коррелируют с потреблением энергии. Далее, на основании того на сколько сильна эта взаимосвязь между данными HPC и энергопотреблением, строится модель прогнозирования будущих энергозатрат. MSR-ы используются для мониторинга производительности и контроля датчиков оборудования. Доступ к этим регистрам можно получить с помощью двух инструкций - rdmsr и wrmsr. Доступ к MSR из пространства пользователя в Linux осуществляется через модуль ядра, который называется msr. Когда этот модуль загружен, открывается доступ к интерфейсу /dev/cpu/x/msr. Этот файловый интерфейс предназначен для чтения и записи в любой MSR на данном CPU. MSR-ами программируется один из основных механизмов определения энергопотрбления - это RAPL интерфейс (Running Average Power Limit). RAPL MSR-ы предоставляют доступ к внутрипроцессорным датчикам мощности (поэтому поддерживаются процессоры Sandy Bridge, Ivy Bridge и более новые). Например, RAPL_PKG_ENERGY_STATUS MSR используется как счетчик, определяющий количество ватт, потребленное системой с момента запуска. А регистр RAPL_POWER_UNIT содержит данные, переводящие значение счетчика в реальные цифры потребляемой мощности и энергии. Помимо MSR и HPC, при замерах важно следить за частотой переключения уровней энергопотребления при помощи технологий Intel C-states и P-states, на основе которых определяется схема энергопотребления процессора с помощью стандарта Advanced Configuration and Power Interface (ACPI).

Самым простым инструментом измерения энергопотребления можно назвать Joulemeter от Microsoft. В основе его расчетов лежат данные о потреблении специфической программой или виртуальной машиной аппаратных ресурсов системы - центрального процессора, жестких дисков, памяти, дисплея и др. Эти сведения конвертируются в показатели фактического энергопотребления, что достигается за счет чтения значений некоторых MSR-ов, как например MSR_PKG_ENERGY_STATUS, MSR_FUNC_POWER, и некоторых HPC, например - CPU_CLK_UNHALTED.CORE и CPU_CLK_UNHALTED.REF (процент времени, в течение которого процессор активен за определенный интервал времени). Для оценки энергопотребления памяти используется last level cache (LLC) miss counter. Также для прогнозирования включен механизм использования P- и C-states, которые учитываются следующим образом: для данного состояния считается утилизация процессора через HPC, и тогда общее потребление за определенный промежуток времени - это произведение этой утилизации на некоторый коэффициент, для вычисления которого используется механизм обучения на основе линейной регрессии.

Joulemeter весьма неплохое средство, но оно все же уступает место следующему инструменту оценки энергопотребления - PowerTop в виду его большей информативности и открытому исходному коду. PowerTop предоставляет информацию по уровню потребления энергии каждым процессом в режиме реального времени. Это достигнуто с помощью деления общего потребления энергии в системе (берется из ACPI) по времени исполнения каждого процесса на процессоре в микросекундах за секунду. Механизм измерения построен на системных профилировщиках. PowerTop собирает информацию из различных источников ядра (таких как /proc, /sys, ACPI) и отображает результат работы системы в одном окне так, что можно увидеть насколько хорошо работает система, и какие компоненты наиболее проблемные. Одним из преимуществ PowerTop является то, что он может находить программные компоненты, которые вынуждают систему потреблять больше энергии, чем это необходимо, в то время как она находится в режиме ожидания. Также преимуществом является достаточно большая информативность: wakeups (пробуждение в секунду), информация о состоянии С- и P- states, потребляемая мощность, оценку, сколько часов работы от батареи осталось.

Самое точное и простое по устройству средство профилирования энергопотребления - это Intel PowerGadget. Для оценки используется работа с RAPL MSR-ами. Среди дополнительных функций - измерения потребляемой мощности многопроцессорными системами, а также вызываемые извне API для извлечения данных о потребляемой мощности в коде.

Далее кратко описаны еще несколько средств измерения энергопотребления, которые менее практичны из-за недоступной программной реализации. VMeter может прогнозировать общее потребление энергии, основан на Oprofile, следит за некоторыми HPC: CPU_CLK_UNHALTED, DRAM_ACCESSES, INSTRUCTION_CACHE_FETCHES, DATA_CACHE_FETCHES, которые имеют большую корреляцию с потреблением энергии, и проецирует их на реальное энергопотребление. К сожалению, вначале должен подключаться PDU (Power distribution units) и снимаются общие данные. CloudMonitor - может прогнозировать общее энергопотребление всей машины после того, как модель будет обучена на конкретной конфигурации железа. Модель потребления построена на основании использования ресурсов: CPU, память, диск, сеть.

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

уменьшение количества ресурсов приложения при использовании батареи;

использование аппаратных средств сбережения энергии: при помощи C3-state и координирования взаимодействия между ядрами одного процессора;

корректное исполнение переходов между S1 - S4 состояниями;

поддержка работы процессора на высоких P-states, когда не требуется слишком большая производительность;

поддержка работы процессора на более глубоких С-states в отсутствие частой активности процессора.

Также необходимо перечислить некоторые платформозависимые возможности оптимизации энергопотребления:

1) выключение неиспользуемых устройств.

2) При разработке network-intensive приложений, это касается переключения на LAN с WLAN при подключении обоих, пересылка данных по WLAN большими частями, чтобы Wi-Fi карточка была в более низком режиме потребления.

3) Избегать частого обращения к диску.

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

1.4 Инструменты Power-management, доступные разработчику

Чтобы исследовать этот вопрос в полной мере, согласно [30], в первую очередь стоит обратиться к спецификации стандарта ACPI [6], регламентирующего интерфейс регулирования энергопотребления операционной системой. Он объединяет ряд методик по снижению энергозатрат, опирающихся на достаточно очевидную идею: для устройства должен быть реализован набор состояний с пониженными запросами по энергии, но с урезанной в той или иной степени функциональностью. В случае, когда полная функциональность не востребована, есть резон в эти состояния переходить.

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

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

P-states. Это состояния активной работы. P-state - пара частоты процессора и напряжения. Для каждого ядра P-state может быть выбран индивидуально, но при этом нужно понимать, что в рамках одного package могут существовать аппаратные ограничения на одновременные изменения состояний разными ядрами. Так, например, вольтаж в процессоре Pentium 4 не мог опуститься ниже, чем самый высокий запрошенный [8]. Для управления этими состояниями используются Model Specific Reristers IA32_PERF_CTL\IA32_PERF_STATUS.

C-States. В эти состояния процессор входит при исполнении ассемблерных инструкций HLT/MWAIT (команды остановки активного исполнения). Каждому из них соответствуют различные уровни сна (оставляем ли напряжение на кэшах, держим ли напряжение на буферах), из более низких дольше просыпаться (от 10 до 100 микросекунд [16]). По этой причине ядро спускается в “состояние глубокого сна” не сразу, а постепенно. Так что излишне частые пробуждения процессора в связи с активностью пользовательского приложения указывают на неэффективность этого приложения с точки зрения энергопотребления.

Для любознательного системного разработчика может оказаться интересной разница между двумя упомянутыми методами остановки работы CPU. HLT останавливает процессор до первого пришедшего прерывания. Связка MONITOR/MWAIT позволяет реализовать более интеллектуальный сценарий: при помощи MONITOR устанавливается некий адрес памяти, за которым будет происходить наблюдение, а после вызова MWAIT процессор уснет, пока не будет произведена запись в указанную область памяти. Это позволяет избавиться от busy-waiting в случае реализации примитивов синхронизации на уровне ядра ОС.

Помимо того, процессоры Intel содержат в себе набор эвристических алгоритмов управления энергопотреблением, и у разработчика есть возможность повлиять на их работу записью в MSR IA32_ENERGY_PERF_BIAS. Предполагается существование 16 уровней производительности (0 - максимальная производительность, 15 - максимальное энергопотребление/минимальная производительность).

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

1.5 Инструмены энергопрофилирования, доступные разработчику

Теперь рассмотрим аппаратные инструменты энергопрофилирования. С аппаратными средствами измерения абсолютных показателей потребления энергии у процессоров Intel долгое время была проблема: их не было. Вернее говоря, такие средства были реализованы как отдельные устройства, подключаемые к материнской плате (или, например, как Watts Up, через USB [19]), что достаточно неудобно, а порой почти нереализуемо (например, если нет физического доступа к машине).

Но уже процессоры Pentium содержали в себе модуль измерения производительности (Performance Monitoring Unit), который давал возможность собирать статистику по количеству аппаратных событий, происходящих в процессоре (например, количество исполненных инструкций, промахов кешей и т.д.). На базе этой статистики долгое время и производились оценки энергопотребления. Происходило это следующим образом: строилось некоторое предположение о корреляции между измеряемыми метриками и энергопотреблением системы (энергетическая модель), и далее, когда профайлер с заложенной моделью попадал на целевую машину, запускался процесс калибровки, связывающий оригинальные метрики и реальное энергопотребление. Далее по полученным коэффециентам можно оценивать энергопотребление.

Нетрудно догадаться, что такой подход не может гарантировать безошибочный результат, и поэтому в архитектуру Sandy Bridge был заложен RAPL интерфейс (Running Average Power Limit). После этого через набор msr'ов стало возможно получить информацию о количестве энергии, потребленной системой с момента запуска. Естественно, после этого обсуждать профилировщики, работающие на базе счетчиков производительности, кажется бессмысленным, но это не совсем так, ведь встретить машину, не оснащенную процессором на архитектуре Sandy Bridge и старше, все еще очень несложно, и RAPL позволяет оценивать только энергопотребление CPU, чего в некоторых случаях может быть недостаточно.

1.6 Утилиты измерения энергопотребления

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

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

PowerTop[10] (Linux) - эта утилита предоставляет информацию по энергопотреблению процессов системы в режиме реального времени. В своих выводах опирается на энергетическую модель, учитывающую потребление CPU, Network-devices, GPU и HDD [11]. Вносит overhead порядка 3%, что соответствует среднему значению для профилировщиков производительности. Среди безусловных плюсов стоит отметить то, что эта утилита сможет работать на большинстве существующих CPU от Intel (начиная с Core 2 Duo). Помимо того, инструмент предоставляет простой доступ к ряду параметров управления энергопотреблением системы, а также показывает, какие компоненты наиболее проблемные и приводит конкретные предложения по настройке с целью уменьшения потребления энергии. Примерами таких рекомендаций могут служить - включение энергосбережения Wi-Fi, перевод AC97 в режим энергосбережения, выключение звука, включение режима энергосбережения PCI Express и SATA-устройств, выключение опроса CDROM с помощью HAL, включение экономии энергии в настройках звукового чипа HDA и т.д. Также PowerTop может посоветовать изменения некоторых конфигураций ядра, например - dirty ratio, dirty background ratio, sched_mc_power_savings и т.п. Но стоит понимать, что утилита может выдавать статистику только по процессам, что значит, что профилирование конкретного приложения при помощи PowerTop является нетривиальной задачей, так как нет никакой привязки полученной статистики к исходному коду. В качестве источники данных PowerTop полагается на данные от PMU, которые по некоторым коэффициентам ставит в соответствие потребляемой электроэнергии.

Joulemeter[14] (Windows) - профилировщик, использующий, как и PowerTop, метрики производительности для оценки затраченной энергии [15]. Учитывает затраты CPU, HDD, GPU, сетевых устройств и экрана. Так же, как и PowerTop, не дает возможности связывать статистику с исходным кодом приложения, хотя и является удобным инструментом для анализа энергопотребления системы в целом. Так же как и PowerTop, Joulemeter полагается на статистику от PMU

Далее рассмотрим утилиты, которые помимо метрик производительности используют RAPL-интерфейс (прямые измерения энергопотребления CPU).

Intel Power Gadget [12] (Linux, Windows, OS X) - профилировщик, предоставляющий статистику по энергопотреблению выбранного пользователем приложения на машинах с CPU на базе Sandy Bridge и новее. Предоставляет также Power Gadget API, позволяющий пользовательским приложениям получать метрики энергопотребления. Так же, как и PowerTop, не может связывать статистику с исходным кодом.

Intel VTune Amplifier 2013 Update 13 [13] (Linux, Windows) - многофункциональный профилировщик производительности, позволяющий также измерять энергопотребление. Может связывать собранную статистику с исходным кодом, собирать стек вызовов и визуализировать полученную информацию. В режиме Advanced Hotspots + collection stack + estimate call counts также дает информацию по количеству потребленной энергии (метрики: Energy Core, Energy GFX, Energy Package). Позволяет получить статистику с точностью до инструкции, что дает очень широкие возможности по анализу для дальнейшей оптимизации.

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

Activity Monitor [17] (OS X) - монитор производительности, выдающий помимо прочего метрику, характеризующую энергоэффективность работающих приложений. Не дает очень детальной статистики, но позволяет оценить, есть ли смысл подключать более информативные инструменты для получения развернутой статистики.

XCode 5 [18] (OS X). В состав IDE от Apple был включен мощный инструментарий по анализу энергопотребления приложения. Он предоставляет агрегированные метрики, которые могут оказаться даже более информативными, чем абсолютные значения потребления энергии. Среди них можно выделить WakesPerSecond - количество “пробуждений” CPU в связи с активностью приложения (например, из-за таймеров и ряда других событий). В дополнение к этой метрике данный инструмент выстраивает CPU-usage трассу, на которой выделен CPU Wake Overhead. Такие трассы строятся отдельно для каждого из потоков, что упрощает анализ приложения. В отличие от Intel VTune Amplifier, инструмент от Apple не связывает напрямую измеряемые метрики и код приложения. Но, имея на руках информацию о проблемной тенденции, в большинстве случаев можно детализировать информацию при помощи других инструментов (например, причину частых пробуждений можно искать при помощи утилиты timerfires, а неоправданно высокий уровень утилизации CPU - профилировщиком Instruments).

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

Профилировщик	ОС	Модели процессора	Измерение CPU Energy Usage	Измерение Devices Energy Usage	Привязка к исходному коду
PowetTop	Linux, Solaris	Core2Duo и новее	Моделируется на базе PMU	Моделируется на базе PMU	Нет
Joulemeter	Windows	Core2Duo и новее	Моделируется на базе PMU	Моделируется на базе PMU	Нет
Intel Power Gadget	Linux, OS X, Windows,	Sandy Bridge и новее	Прямые измерения через RAPL	Нет	Нет
Intel VTune Amplifier	Linux, Windows	Поддержка измерения энергопотребления только на Sandy Bridge и новее	Прямые измерения через RAPL	Нет	Да
XCode 5 Power Profiler	OS X	Sandy Bridge и новее	Сбор агрегированных метрик от ОС	Нет	Раздельная статистика по потокам.

1.7 Ряд техник по улучшению энергоэффективности

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

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

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

Использование APP NAP API в OS X Maverics [9]. Разработчики OS X уделили пристальное внимание проблемам энергопотребления и добавили API, позволяющий разработчикам эффективно взаимодействовать с рядом политик ОС по сбережению энергии без ущерба производительности.

Уменьшения частоты обращений к устройствам. Так же, как высокочастотные вычисления не дают CPU долго находиться в состоянии “сна”, частые обращения к оборудованию не дают им находиться в состоянии пониженного энергопотребления.

2. Разработка алгоритма мониторинга энергопотребления

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

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

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

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

2.1Критерии эффективности алгоритма

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

Требования, предъявляемые к алгоритмам.

Высокая точность измерений (с учетом отсутствия доступа к отдельным аппаратным средствам).

Отсутствие влияния алгоритма на производительность и защищенность измеряемого виртуального окружения.

Поддержка алгоритма архитектуры целевых компьютерных систем с использованием микропроцессоров семейства x86.

2.2 Составные части энергопотребления

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

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

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

2.3 Методы, регулирующие объем энергопотребления

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

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

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

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

P-states - состояния активной работы. P-state - пара параметров: частота микропроцессора и напряжение. Для каждого ядра микропроцессора P-state можно выбрать индивидуально, но при этом необходимо учитывать, что для микропроцессора с несколькими ядрами могут существовать аппаратные ограничения на индивидуальные по отношению к каждому ядру изменения P-state. Например, питающее напряжение для микропроцессора Pentium 4 не может быть ниже максимального значения, запрашиваемого одним из его ядер [24]. Для управления этими состояниями используются регистры MSR, именуемые IA32_PERF_CTL и IA32_PERF_STATUS [22].

C-states. В этих состояниях микропроцессор находится в момент исполнении ассемблерных инструкций HLT/MWAIT (команды остановки активного исполнения). Каждому такому состоянию соответствуют различные уровни «сна». Чем ниже уровень «сна», тем больше требуется времени для перехода микропроцессора в состояние активной работы (так называемого времени «пробуждения», составляющего от 10 до 100 мкс). По этой причине ядро переключается в «состояние глубокого сна» не сразу, а постепенно. Поэтому излишняя активность исполнения алгоритма мониторинга, приводящая к частым «пробуждениям» процессора, может снизить его эффективность с точки зрения энергопотребления.

2.4 Основные инструменты измерения и профилирования энергопотребления

Измерению энергопотребления на платформе x86 посвящено большое количество работ. Это обусловлено тем, что достаточно длительное время для разработчиков не было возможности получать данные о затратах энергии без использования дополнительного оборудования. В результате был создан ряд математических моделей, связывающих показатели производительности и энергопотребление системы. Большинство методов базировалось на обработке получаемых данных по аппаратному интерфейсу ACPI или данных, поступающих от внешних устройств, измеряющих энергопотребления [229, 230], что не могло гарантировать безошибочный результат. С применением технологии RAPL в микропроцессорах компании Intel [25] стало возможным получать информацию о количестве потребляемой системой энергии с момента ее запуска.

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

2.5 Анализ существующих алгоритмов мониторинга энергопотребления

"PowerTop" (Linux) [19] опирается на энергетическую модель, связывающую метрики производительности и энергопотребление системы. Данный алгоритм работает только после процесса «обучения» на целевой машине, требующего данных об энеогопотреблении. В случае мобильного устройства стандарт ACPI предусматривает возможность получения информации о текущем заряде батареи. Для остальных вычислительных устройств необходимо дополнительное оборудование, снимающее информацию об энергопотреблении системы. Последнее делает непригодным использование данного алгоритма для облачного хостинга.

"Joulemeter" (Windows) [28] - профилировщик, использующий, как и "PowerTop", метрики производительности для оценки затраченной энергии. "Joulemeter" имеет более развитую модель построения профиля энергопотребления, учитывающую энергозатраты от различных устройств. Недостаток данного метода в том, что он также требует процесс «обучения», что делает его непригодным для использования как обощенного.

Ряд приложений от компании Intel использует аппаратный интерфейс RAPL, позволяющий получать точную информацию об энергопотреблении системы. Одним из недостатков этого подхода является то, что для работы алгоритма, базирующегося на RAPL, необходима облачная инфраструктура, построенная на базе процессоров с микроархитектурой Sandy Bridge и выше. Поскольку в ближайшее время ожидается появление аналогичных интерфейсов в большинстве серверных микропроцессоров семейства х86, этот подход является самым приемлемым решением при разработке алгоритма. Более того, в отличие от предыдущих он не требует калибровку модели с участием человека.

3. Описание алгоритма

3.1 Контексты исполнения

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

хостовый контекст (или контекст хостовой ОС) - контекст исполнения программных модулей, осуществляющих работу с оборудованием и обеспечивающих общий контроль над инфраструктурой;

контекст монитора виртуальных машин - контекст исполнения программных модулей монитора виртуальных машин;

гостевой контекст - контекст исполнения виртуального окружения (контекст исполнения гостевой ОС и ИПР пользователя).

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

Далее описан каждый из сценариев размещения приложения.

3.2 Размещение в контексте хостовой ОС

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

3.3 Размещение в гостевом контексте и в гостевой ОС

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

3.4Размещение в контексте монитора виртуальных машин

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

3.5 Переключение контекста

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

Переключение контекстов будет управляться перечисленными ниже функциями (программными модулями).

Таблица 1

Операция переключения	Наименование функции
Переключение из контекста монитора виртуальных машин в хостовый контекст	MonRetToHostSwitch
Переключение из хостового контекста в контекст монитора виртуальных машин	MonRetToHostSwitch
Переключение из монитора виртуальных машин в контекст гостевой ОС	OnGuestEnter
Переключение из контекста гостевой ОС в контекст монитора виртуальных машин	OnGuestExit

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

3.6 Обработка прерываний

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

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

3.7 Описание механизма подсчета

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

Таблица 2

Вид доступа	Наименование инструкции
чтение из MSR	rdmsr
запись в MSR	wrmsr

Алгоритм измерения энергопотребления включает следующие этапы.

В момент инициализации монитора виртуальных машин считывается начальное значение энергии из MSR MSR_RAPL_PKG_ENERGY_STATUS.

Считанное начальное значение заносится в переменную-счетчик структуры EnergyStat.

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

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

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

4. Тестирование алгоритма

4.1 Описание тестового стенда

Получение данных об энергозатратах с использованием разрабатываемого алгоритма проводилось на оборудовании, включающем:

процессор Intel Core i7-3770 Ivy Bridge: 3400МГц (8 ядер) , 8 Гб DDR3 SDRAM;

Ubuntu 13.04 - (хостовая ОС);

Windows 7 (гостевая ОС);

Parallels Desktop (В качестве гипервизора).

4.2 Тестовые сценарии и результаты тестирования

Тестирование алгоритма включало в себя проверку правильности работы механизма подсчета энергопотребления. Для этого на гостевой ОС запускались задачи с высокой энергонагрузкой (использовались нагрузочные тесты из пакета Linpack benchmark [23], одновременная работа с несколькими офисными приложениями, редактирование изображений и другие). Одновременно с исполнением задач в мониторе запускалось приложение, использующее разрабатываемый алгоритм определения общего количества потребленной энергии с момента запуска гостевой ОС. Количество запусков каждой задачи было 10.

Результаты теста сравнивались с результатами, полученными от доступных профилировщиков энергопотребления, таких как PowerTop [26] и Intel Power Gadget [22]. Сравнение результатов подтверждало работоспособность алгоритма.

4.3 График отклонения измерений

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

Метод тестирования включал в себя следующие действия:

С помощью тестового приложения активно загружалось CPU в течении 10 минут;

Тестовое приложение также исполнялось на хостовой ОС под контролем Intel VTune Amplifier, собирающего информацию о количестве потребляемой энергии;

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

Полученные данные отображались в виде графика с двумя функциями в соответствии с рисунком 39. Линия графика P1(t) отображает замеры в хостовой ОС и P2(t) - в виртуальном окружении соответственно. Так как тестовое приложение в основном загружало процессор (без вызова монитора виртуальных машин в течение долгого времени), то результаты замеров должны были совпадать в пределах незначительной погрешности.

Измерения энергопотребления в виртуальном окружении P2(t) проведены согласно программной реализации алгоритма. Замеры энергопотребления в хостовой ОС P1(t) проводились с помощью профилировщика энергопотребления PowerTop. Единицами измерений энергопотребления в обоих случаях служили Джоули.

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

Рисунок 1.

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

P2(t), Дж	Нагрузка (тесты из пакета Intel Linpack benchmark)
81,6	zgeco
37,8	zchdc
132,5	schdd
19,0	zgesl
339,1	cgesl
335,7	zgtsl
220,1	spbco
173,8	spbdi
598,6	zpbdi
154,0	cpbsl
105,5	dposl
757,5	cposl
109,7	dsico

Результаты первичных измерений энергопотребления в хостовой ОС с помощью профилировщика энергопотребления PowerTop:



P1(t), Дж	Нагрузка (тесты из пакета Intel Linpack benchmark)
82,7424	zgeco ...

Подобные документы

• Интерполяция траектории движения GPS-модуля по результатам измерения координат

  Разработка алгоритма фильтрации данных, полученных с систем спутниковой навигации с помощью GNSS-модуля. Анализ работы фильтра Калмана, его программная реализация под конкретную задачу. Выбор навигационных модулей для получения данных позиционирования.
  
  дипломная работа [3,6 M], добавлен 12.01.2016
  

• Разработка устройства управления приводом часового механизма с шаговым двигателем

  Изготовление устройства управления шаговым двигателем на базе микросхем дискретной логики ТТЛ. Временные диаграммы работы устройства. Условное графическое изображение и уровни реализации структуры ПЛИС. Расчет энергопотребления с помощью утилиты xPower.
  
  курсовая работа [1,1 M], добавлен 28.12.2012
  

• Средства печатного вывода вычислительной техники

  Алфавитно-цифровые печатающие устройства. Отличие светодиодного принтера от лазерного. Принтеры трёхмерной печати, уровень энергопотребления, разрешающая способность, интерфейс подключения. Набор дополнительных функций. Тип красителей и количество цветов.
  
  реферат [986,3 K], добавлен 16.05.2014
  

• Программная реализация учета компьютеров

  Разработка программы учета занятости компьютеров в лаборатории. Анализ требований, метод решения. Разработка алгоритма в виде структурных схем. Программная реализация в среде Borland Delphi. Минимальные системные требования для ее корректной работы.
  
  дипломная работа [6,3 M], добавлен 10.06.2013
  

• Процессоры Intel

  История создания и развития компьютерных процессоров Intel. Изучение архитектурного строения процессоров Intel Core, их ядра и кэш-память. Характеристика энергопотребления, производительности и систем управления питанием процессоров модельного рядя Core.
  
  контрольная работа [7,6 M], добавлен 17.05.2013
  

• Возможности виртуальных экспозиций

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

• Преобразователь кода (ПК)

  Проектирование преобразователя кода (ПК), рассчет его энергопотребления и быстродействия. Составление таблицы истинности ПК. Написание булевых функций, минимизация и преобразование к выбранному базису. Составление структурной схемы преобразователя кода.
  
  курсовая работа [775,3 K], добавлен 09.02.2009
  

• Программная реализация алгоритма шифрования IDEA

  Исследование симметричных алгоритмов блочного шифрования. Минусы и плюсы алгоритма IDEA. Разработка программы аутентификации пользователя и сообщений на основе алгоритма IDEA. Выбор языка программирования. Тестирование и реализация программного средства.
  
  курсовая работа [314,2 K], добавлен 27.01.2015
  

• Исследование возможностей САПР Quartus

  Окно для работ с Design Assistant. Пример комбинационной логики, используемой в качестве тактового сигнала. Условия эффективного снижения энергопотребления с помощью сигнала синхронизации, полученного при помощи логической ячейки. Вкладка Fitter Settings.
  
  курсовая работа [562,7 K], добавлен 05.11.2014
  

• Лабораторный стенд на базе платформы Intel P965

  Процессоры Intel Core 2 Duo, энергопотребление. Размер кристалла Core 2 Duo и число транзисторов. Технологии управления энергопотреблением Core 2 Duo. Ultra Fine Grained Power Control. Индикация энергопотребления процессора/PSI-2. Цифровые термодатчики.
  
  курсовая работа [5,4 M], добавлен 16.01.2009
  

• Программная реализация задачи расчета коэффициента ритмичности продукции

  Создание программы, автоматизирующей расчет коэффициента ритмичности продукции с использованием электронных таблиц средствами языка программирования Си. Консолидация данных в MSExcel. Программная реализация алгоритма. Тестирование разработанного ПО.
  
  курсовая работа [3,0 M], добавлен 07.06.2014
  

• Программная реализация алгоритма Дейкстры (построение цепей минимальной длины)

  Теоретическое исследование вопроса и практическое применение. Общие сведения о графах. Алгоритм Дейкстры. Особенности работы в среде. Программная реализация. Описание алгоритма и структуры программы. Описание программных средств. Текст программы.
  
  курсовая работа [1,0 M], добавлен 27.11.2007
  

• Ручная реализация алгоритма решения задачи

  Особенности метода неопределенных множителей Лагранжа, градиентного метода и метода перебора и динамического программирования. Конструирование алгоритма решения задачи. Структурная схема алгоритма сценария диалога и описание его программной реализации.
  
  курсовая работа [1010,4 K], добавлен 10.08.2014
  

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

  Программы для обслуживания деканата, разработка и сущность ее использования. Особенности работы в среде Visual C++. Программная реализация, описание алгоритма и структуры, использованных программных средств, разработанных функций. Инструкция пользователя.
  
  курсовая работа [330,1 K], добавлен 05.03.2009
  

• Исследование методов и реализация алгоритма моделирования распространения информации в социальных сетях

  Виды социальных медиа. Критерии эффективности продвижения аккаунта в социальных сетях. Программная реализация алгоритма моделирования распространения информации в социальной сети "Twitter". Разработка клиентского приложения. Апробация интерфейса системы.
  
  дипломная работа [5,4 M], добавлен 08.02.2016
  

• Разработка системы для автоматического анализа цифровых изображений номерных знаков автомобилей

  Исследование вертикальных проекций яркости и размаха яркости. Программная реализация алгоритма автоматического анализа цифровых изображений номерных знаков с целью сегментации цифробуквенных символов. Разработка графического пользовательского интерфейса.
  
  дипломная работа [1,5 M], добавлен 12.04.2013
  

• Программная реализация алгоритма шифрования DES. Режим ECB

  Симметричные криптосистемы; алгоритмы шифрования и дешифрования данных, их применение в компьютерной технике в системах защиты конфиденциальной и коммерческой информации. Основные режимы работы алгоритма DES, разработка программной реализации ключа.
  
  курсовая работа [129,6 K], добавлен 17.02.2011
  

• Разработка web-сайта на примере Всеволожского исполнительного комитета партии "Единая Россия"

  Теоретические основы разработки web-сайтов, язык размeтки HTML, язык сцeнариeв JavaScript, web-прoграммирoваниe. Программная реализация вэб-сайта Всеволожского исполнительного комитета партии "Единая Россия", программная реализация алгоритма работы.
  
  дипломная работа [2,9 M], добавлен 21.01.2012
  

• Разработка автоматизированной технологии анализа и сегментации рынка мебели

  Слабые и сильные стороны российского сегмента мирового рынка мебели. Прогнозирование и оптимизация основных показателей деятельности компаний ООО "Ваш Быт", ООО "Столплит", ООО "Дятьково" с использованием возможностей табличного процессора Excel.
  
  курсовая работа [992,8 K], добавлен 18.06.2011
  

• Реализация алгоритма обратной трассировки лучей для моделей с большим числом полигонов

  Алгоритмы получения реалистических изображений. Применение алгоритма обратной трассировки лучей, ее математическая основа. Составление матрицы и программная реализация. Формирование отраженного и преломленного луча. Модульная структура программы.
  
  курсовая работа [219,3 K], добавлен 24.06.2009
  

• главная
• рубрики
• по алфавиту
• вернуться в начало страницы
• вернуться к началу текста
• вернуться к подобным работам