Диссертация (1148255), страница 16
Текст из файла (страница 16)
Таким образом, время задержки в данном решении задачи– величина не константная, что, однако, не противоречит изначально сформулированным условиям решения.Несмотря на то, что полученные результаты полностью соответствуют поставленной задаче, может возникнуть вопрос – какое именно устройство измена блокировку, обеспечиваемой ролью Сервер и упомянутых выше.1Данный эффект – следствие использования конструкции MDSM_ACCESS_ON.
Иная реализация, скажем через постоянный опрос наблюдаемой переменной с некоторой задержкой, неминуемо привёл бы к визуально рассинхронизованному поведению устройств.94няет значение счётчика? Исходя из реализации очередей блокировок можноожидать, что устройства будут захватывать счетчик по очереди. Для проверкиданной гипотезы расширим экспериментальную программу до представленнойна рис.
3.5.1 MDSM_DECLARE(X)2int c o u n t e r ;3COLOR c o l o r ;4 MDSM_DECLARE_END56// Поток №17while ( true )8{9MDSM_ACCESS_RW(X)10++ MDSM_ITEM( c o u n t e r ) ;11MDSM_ITEM( c o l o r ) = MY_COLOR;12Task : : Delay ( 1 SEC ) ;1314MDSM_ACCESS_END}1516// Поток №217while ( true )18{19MDSM_ACCESS_ON(X)20Show (MDSM_ITEM( c o u n t e r ) , MDSM_ITEM( c o l o r ) ) ;2122MDSM_ACCESS_END}Рисунок 3.5 – МАКС DSM программа «цветной счётчик»Группа распределённых переменных пополнилась новой переменнойcolor (строка 3), содержащей код цвета устройства, которое последним произвело увеличение распределённого счётчика. Для достижения данного функционала в первый поток программы добавлена инструкция на строке 11, в которой используется определение MY_COLOR, представляющее собой определениекода цвета устройства в зависимости от его идентификатора1 .
Соответственно,1Инициализация/вычисление MY_COLOR в листинге не приводится как не существенное.95функция Show была расширена параметром, определяющим код цвета, которыйпередается в неё во втором потоке на строке 20.Описанное усовершенствование позволило наблюдать смену цвета выводимого значения счётчика при каждом его изменении, что подтвердило вышеописанную гипотезу.3.7. Производительность3.7.1. Производительность для двух узловДля проведения измерений был создан программно-аппаратный стенд, состоящий из двух плат STM32F429I-Discovery с подсоединенными к ним радиомодулями nRF24L01. Данные модули обеспечивают приём и передачу данныхна частоте 2.4 ГГц с заявленной скоростью до 2 Мбит/сек.
Однако достигнутаяна практике скорость оказалась существенно ниже, так как, во-первых, данныепередаются аппаратными пакетами длиной до 32 байт, причём время передачипакета сложным образом зависит от его длины, а, во-вторых, существенное время занимает переключение между режимами приём/передача.
Таким образом,для получения надежных результатов следует начать с определения реальнойскорости передачи на нижнем уровне. Измерения скорости производились дляпередачи данных, представленных в виде пакетов различной длины. Скоростьопределялась как в виде пропускной способности (bps – от англ. bytes per second,байт в секунду), так и количества пакетов в секунду (pps – от англ. packets persecond). Каких-либо попыток оптимизации по скорости не производилось, таккак задача заключается не в достижении максимальных показателей, а в проведении сравнительного анализа различных способов взаимодействия в радиоэфире. Результаты измерений представлены в виде графиков ниже. Исходныеданные в виде таблицы вынесены в приложение А.Эксперимент состоит из четырёх этапов – измерения скорости передачиданных на разных логических уровнях:961.
«Сырая» скорость канала.2. Контроль целостности данных.3. Гарантированная доставка.4. Показатели DSM уровня.Рассмотрим каждый из этапов подробнее.«Сырая» скорость каналаЦель этапа — определить максимально возможную «сырую» скорость передачи данных на данном оборудовании.Достаточно большое количество пакетов1 различной длины отправлялосьсериями2 с одной платы на другую, при этом на приемной плате определялоськоличество принятых пакетов и время передачи. Зная количество отправленных пакетов, можно было убедиться в наличии связи между платами и надежности канала (с точки зрения потерь3 ), которая оказалась достаточно высокой(потери на уровне нескольких процентов).
Результаты замеров представленына рис. 3.6.Как можно видеть (в данном случае точную величину определить по графику затруднительно, однако точные величины приводятся в приложении А),скорость изменяется от 1,8004 bps для пакетов длиной 1 байт до 36,500 bps длядостигнутых максимумов. Как и можно было предположить, максимумы оказались ярко выраженными и достигаются при размерах пакета кратных 32 байтам1На данном уровне понятие программного пакета ещё отсутствует (оно вводится позже), и пакет имеетсяв виду «аппаратный».
После отправки определённого количества байт выполняется вызов функции flushдрайвера радиомодуля, что вызывает немедленную отправку накопленных данных невзирая на аппаратнуюбуферизацию.2Использовались серии из не менее чем 100 пакетов и не менее чем 10 килобайт – опытным путёмбыло обнаружено, что данные условия позволяют добиться достаточного уровня повторяемости результатовс отклонением между двумя замерами около 2%.3Так как контроль целостности на данном уровне ещё отсутствует, процент потерь определялся черезобъем принятой информации и его соответствие объему отправленной.4Здесь и далее, для удобства восприятия, величины скорости приводятся в округленном до 100 bps виде.97Скорость, байт в секунду (bps)40,00030,00020,00010,0000020406080100120140160180200220240Длина пакета, байт (bytes)Рисунок 3.6 – «Сырая» скорость канала– наблюдаемые на графике изломы соответствуют необходимости использоватьбольшее количество аппаратных пакетов.
При этом достигнутый при размерепакета в 32 байта максимум далее не превышается. Средняя скорость составилаприблизительно 32,000 bps. Если же учитывать только пакеты размером болеечем 16 байт, средняя скорость составит 33,400 bps. По мере увеличения длины пакета разброс между минимальной и максимальной скоростью ожидаемосокращается.На графике наблюдается падение скорости на отметке 165 байт, а также,гораздо менее заметное, при длине пакета 177 байт (точные величины можнонайти в приложении А). Данные «отклонения», по всей видимости, обусловленывозникновением помех в эфире при передаче соответствующих серий (повторные эксперименты выявляют аналогичные «всплески», возникающие на разныхучастках графика без видимой закономерности).Контроль целостности данныхНа данном этапе к пакетам была добавлена служебная информация, позволяющая контролировать целостность данных (на основе CRC32), а также опре98делять начало пакета в потоке данных и его размер1 .
Результаты измерений1,60040,0001,4001,20030,0001,00020,00080060010,0004002000020406080100120140160180200220Скорость, пакетов в секунду (pps)Скорость, байт в секунду (bps)отражены на рис. 3.7.240Длина пакета, байт (bytes)Рисунок 3.7 – Cкорость с контролем целостности данныхОбъем указанной выше служебной информации составил 7 байт. Таким образом, передача пакета длиной 1 байт эквивалентна 8 байтам нижнего уровня(рассмотренного выше). Например, пакет в 5 байт соответствует пакету 5+7=12байт «сырых» данных. Для пакетов 12 байт на первом этапе эксперимента определена скорость 17,900 bps.
Следовательно, для полезной нагрузки остаетсяполоса в 5*(17,900/12)=7,500 bps. Это хорошо соответствует результатам измерений: 7,100 bps для пакетов 5 байт2 .Однако максимально достижимая на данном логическом уровне скоростьнеожиданно оказалась несколько выше максимальной скорости предыдущегоуровня. Дополнительное исследование показало, что причина заключается в1Соответственно, начиная с данного этапа, замеряется не количество байт, а количество пакетов.
Количество же байт выводится простым перемножением количества принятых пакетов на размер пакета в текущемэксперименте.2Можно заметить, что размер пакета в эксперименте варьируется от 1 до 255 байт – верхняя граница неуменьшена на объем системной информации. Это связано с тем, что поле «размер пакета» (как и остальныеполя текущего уровня) входит в данную системную информацию, и, соответственно, под «полезные» данныеостаётся именно 255 байт в максимуме. Последующие уровни протоколов уже потребуют снижения верхнейграницы, так как размещают свои служебные данные в составе «пользовательских» данных текущего уровня.99накладных расходах на обращение к функции выборки поступающих данныхиз драйвера радио-модуля.
На предыдущем этапе у нас не было возможностиопределить количество ожидаемых байт, и байты извлекались по одному. Натекущем этапе среди служебной информации имеется и поле размера пакета,что позволяет выполнить выборку нужного количества байт за один раз. Соответственно, чем размер пакета больше, тем обнаруженный эффект становитсяболее заметен.В целом эксперимент подтвердил результаты предыдущего этапа, а также позволил исследовать канал на надежность в смысле искажения данных,которая также оказалась на уровне двух процентов.Поскольку на данном этапе мы уже работаем с реальными программнымипакетами, то скорость в байтах можно отразить и в виде скорости в пакетах– соответствующий график для наглядности также представлен на рис.
3.7 (ввиде пунктирной линии). Очевидно, чем меньше по размеру пакет, тем быстрееон должен передаваться, но и тем меньшую полезную нагрузку нести – данноеожидание воплощается в предсказуемом убывании пунктирного графика.Примечательным является возникновение небольших периодических колебаний скорости передачи, особенно хорошо заметных в районе длины пакета 100байт. Подобные волны наблюдаются и далее, хотя их частота и регулярностьпостепенно сходят на нет. Если проанализировать самое яркое проявление эффекта в диапазоне 100-120 байт, то хорошо заметна четкая последовательностьминимумов и максимумов, которые отстоят друг от друга на расстоянии 2 байта.
Это можно объяснить, например, особенностями работы аппаратуры илидрайвера нижнего уровня при разном выравнивании длины пакета относительно машинного слова. Возможны и другие причины, вопрос, очевидно, требуетдополнительных исследований, однако, ввиду несущественного влияния данной«аномалии», её исследование вынесено за рамки данной работы.100Гарантированная доставкаДанный этап посвящён измерению производительности системы гарантированной доставки пакетов (аналог протокола TCP для широковещательногорежима). В дополнение к возможностям второго этапа, обеспечивающего целостность данных, в данном случае осуществлялась отправка подтвержденийо получении очередного пакета, а потерянные пакеты отправлялись повторно.35025,00030020,00025015,00020010,0001505,0001000020406080100120140160180200220Скорость, пакетов в секунду (pps)Скорость, байт в секунду (bps)Результаты измерений представлены на рис.
3.8.240Длина пакета, байт (bytes)Рисунок 3.8 – Cкорость с гарантированной доставкойВ связи с существенным ростом нагрузки на канал показатели ожидаемоснизились – примерно до 20,000 bps, с максимумом в районе 25,000 bps. Заметно, что график теряет стабильность по мере увеличения длины пакета. Предположительно это вызвано возрастанием вероятности его потери/поврежденияи, соответственно, необходимостю его повторной передачи. Данную гипотезуможно проверить, наложив график скорости на график количества повторныхпосылок, однако в рамках текущего исследования данный эффект также оставим без внимания как несущественный.101Показатели DSM уровняПоследним этапом стало измерение показателей системы МАКС DSM.Уровнем ниже располагались механизмы, рассмотренные на предыдущих этапах. В соответствии с общей схемой эксперимента, проверялась работа на данных разного размера.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
