Исследование временных характеристик многопоточного приложения в ОСРВ QNX во время обработки информации от периферийных устройств

Содержание

Расчетно-графическая  работа. Исследование временных характеристик  многопоточного приложения в ОСРВ QNX во время обработки информации от периферийных устройств

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

Общие положения

Целью работы является исследование времени реакции сервера на сетевые запросы клиентов, формируемые в реальном масштабе времени.

Для достижения цели необходимо решить следующие задачи:

• Разработать серверное приложение, которое получает запросы по протоколу TCP|UDP от некоторого количества клиентов и выполняет обработку этих запросов.
• Разработать консольное клиентское приложение, которое производит подключение к заданному серверу и через некоторые промежутки времени формирует запрос к нему по протоколу TCP|UDP.
• Исследовать время передачи и обработки пакетов серверным приложением.

Объект исследования является процесс обработки пакетов сервером, полученных от удаленных клиентов.

Введение

Общие положения

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

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

Другими словами, ОС РВ умеют прерывать  текущую операцию для немедленной  обработки прерывания. Как следствие, ОС РВ гарантируют обработку события в течение определенного временного интервала.

Встроенные приложения

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

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

Процессы в реальном времени

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

Управление в реальном времени

Занимаясь управлением в реальном времени, непрерывно отслеживается  или моделируется состояние физической системы. Управляющая программа  циклически выполняет некоторую определенную пользователем процедуру, работа которой разделяется на временные отрезки, рис. 1. Человека окружает множество управляющих систем реального времени, таких как системы управления движением машины или термостатическая система управления климатом в доме. Есть несколько параметров, которыми можно охарактеризовать приложение реального времени:

• продолжительность управляющего цикла;
• предсказуемость;
• разброс (jitter).

Рис. 1. Управление в реальном времени

Продолжительность управляющего цикла

Большинство АСУ РВ взаимодействуют  с физической системой путем сравнения  ее текущего состояния с ожидаемым  состоянием и дальнейшим предсказанием  поведения системы на основе результата этого сравнения. Интервал времени  между двумя такими сравнениями и есть продолжительность управляющего цикла. Необходимая продолжительность этого цикла зависит от системы. Например, продолжительность цикла в системе управления температурой в духовке довольно велика. Эта система измеряет температуру, сравнивает ее с желаемой температурой и включает/выключает нагревательные горелки. В этом случае вполне достаточен цикл продолжительностью 1 сек. С другой стороны, печи, используемые в промышленности, требуют очень точно выдержанного температурного режима, например, при выращивании кристаллов. В этом случае продолжительность управляющего цикла должны быть существенно меньше, чтобы удовлетворить жестким температурным ограничениям. В общем случае управление в режиме реального времени соответствует рис. 2.

Рис. 2. Типичное управляющее приложение реального времени

Предсказуемость

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

Разброс

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

Рис. 3. Расчет разброса в допустимом интервале ±30 мс

Обработка сигналов в режиме реального  времени

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

Процедуры поточечного анализа

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

Рис. 4. Поточечный анализ

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

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

Улучшенное принятие решений

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

Наивысшая производительность

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

Реагирование на события в реальном времени

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

Латентный период

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

Сети в системах реального  времени

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

В системах, построенных на основе ОС РВ OS QNX получили распространение несколько типов сетей:

• Ethernet.
• QNET.

О сетях Ethernet сказано достаточно много, отметим лишь, что для целей АСУ РВ они не совсем подходят. В связи с этим и были разработаны сети QNET. Остановимся более детально на сетях QNET.

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

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

Пользователи могут иметь доступ к файлам по всей сети, использовать любое периферийное устройство, запускать программы на любом компьютере сети (при условии, что они имеют надлежащие полномочия). Связь между процессами осуществляется единообразно, независимо от их местоположения в сети. В основе такой прозрачной поддержки сети в QNX лежит всеобъемлющая концепция Inter Process Communication (IPC) — взаимодействие между отдельными процессами на основе передачи сообщений.

Модель единого компьютера

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

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

Гибкая поддержка сети

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

Такая степень прозрачности является еще одним примером больших возможностей архитектуры QNX, основанной на передаче сообщений (IPC). Во многих ОС такие важные функции как поддержка сети и IPC выполнены в виде надстроек над ОС, а не интегрированы непосредственно в ее сердцевину. Результатом такого подхода является неуклюжий и неэффективный интерфейс с «двойным стандартом», когда связь между процессами — это одно дело, в то время как проникновение в скрытый интерфейс таинственного монолитного ядра — совершенно другое дело!

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

Структуры сети QNX.

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

Преимущества такой архитектуры:

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

• различные типы сетевых протоколов, такие как QNET и TCP/IP могут сосуществовать в системе одновременно;

В QNX Neutrino сетевая подсистема делится на три основные составляющие:

• менеджер сети (io-net), исполняемый модуль.
• интерфейс сетевого протокола (npm-qnet.so, npm-tcpip.so и т.д.) — разделяемые библиотеки.
• интерфейс драйвера сетевого оборудования (devn-ne2000.so) — разделяемые библиотеки.

Примерно так выглядит схема  взаимодействия приложения с аппаратным обеспечением. Компонент io-net может одновременно поддерживать несколько сетевых протоколов и несколько драйверов.

Менеджер сети io-net

Менеджер сети io-net выполняет ключевую функцию «моста» между интерфейсами сетевых протоколов и интерфейсами сетевых драйверов. Наибольшей гибкости удается достичь за счет независимости менеджера сети от используемых типов протоколов или аппаратной реализации сети. io-net подгружает протоколы и драйверы как динамические библиотеки, которые в свою очередь осуществляют взаимодействие с программой клиента через соответствующий API протокола и с железом через соответствующий API драйвера.

Интерфейс протокола передачи данных

Интерфейс протокола отвечает за реализацию того или иного протокола передачи данных, например таких как QNET, TCP/IP и др. Каждый интерфейс протокола поставляется в виде разделяемой библиотеки, например npm-qnet.so, протокол QNET, он же Native Neurino Networking. Одновременно в системе могут быть запущены один и более протоколов.

Например, следующая команда запускает  менеджер сети с двумя протоколами: io-net -d ne2000 -p ttcpip -p qnet

В комплект поставки QNX 6 входит четыре основных интерфейса сетевых протоколов:

• QNET - «родной» протокол ОС QNX,
• TTcpIp - «tiny» (крошечный) tcp/ip стек для встраиваемых приложений (только базовые функции tcp/ip),
• TcpIp - полная реализация TCP/IP стека от BSD 4.4 (BSD sockets API),
• Pppmgr - Point-to-Point протокол.

Интерфейс сетевого драйвера

Через сетевой драйвер осуществляется взаимодействие менеджера сети с  конкретным типом сетевого адаптера. Каждый драйвер поставляется в виде разделяемой библиотеки и подключается при старте менеджера сети. Например, команда:

io-net -d ne2000

запускает менеджер сети, который  в свою очередь подгружает интерфейс  драйвера сетевой платы NE2000, размещенный в виде динамической библиотеки devn-ne2000.so. Между драйвером и менеджером сети устанавливается двустороннее взаимодействие. Драйвер может обрабатывать вызовы от менеджера сети при приеме пакетов и, наоборот, менеджер сети, в свою очередь, обращается к драйверу при попытке осуществить передачу пакетов.

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

Протокол QNET

Native Neutrino Networking — это, прежде всего, высокоскоростной сетевой протокол. Уникальность QNET заключается в том, что он превращает объединенные в сеть компьютеры в один виртуальный суперкомпьютер (кластер), создавая единый однородный набор ресурсов, доступ к которым возможен из любого места сети. Следует заметить, что QNET предусматривает возможность наличия нескольких параллельных физических сетей. Для этого следует поместить в каждый компьютер несколько сетевых плат соединенных отдельными кабелями.

• FLEET расшифровывается как:
• Fault-tolerant — отказоустойчивость;
• Load-balancing on the fly — регулировка нагрузки на лету;
• Efficient performance — эффективное действие;
• Extensible architecture — расширяемая архитектура;
• Transparent distributed processing — прозрачная распределенная обработка.

Отказоустойчивость

При выходе из строя сети, например в результате неисправности сетевой  платы или обрыва кабеля, FLEET автоматически перенаправляет данные по другой сети. Это происходит на лету, незаметно для прикладных программ.

Регулировка нагрузки на лету

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

Эффективное действие

Сетевые драйверы FLEET позволяют буквально «выжать» все возможное из сетевого оборудования. Например, при передаче больших блоков данных между двумя процессами по сети Ethernet достигает высокой пропускной способностью, см. таблица 1.

Таблица 1. Пропускная способность  по сети Ethernet через драйверы FLEET

Расширяемая архитектура

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

Рис. 5. Пример объединения нескольких разнородных сетей в единую логическую сеть

Распределенная обработка данных

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

Соглашения об именах узлов

Чтобы понять, как работает QNET, рассмотрим пример взаимодействия "клиент-сервер". В случае единственного узла (процессы клиента и сервера работают в рамках одного компьютера), клиент просто создает связь с сервером, используя функцию ConnectAttach(). Затем посылается сообщение, например, через MsgSend().

Теперь рассмотрим случай простой  сети с двумя машинами — одна содержит процесс- клиент, другая — процесс-сервер. Соглашение о связи клиент-сервер идентично соглашению в случае единственного узла. Клиент создает связь с сервером и посылает серверу сообщение. Единственное различие в случае сети — то, что клиент определяет другой дескриптор узла для запроса функции ConnectAttach ().

Как клиент узнает, какой именно дескриптор узла использовать для связи с  сервером?

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

И в том и в другом случаях, при соединении клиента с сервером, клиент получает идентификатор из ConnectAttach(). Этот идентификатор используется в дальнейшем при отправке/приеме сетевых сообщений.

Давайте рассмотрим, что произойдет в системе после выполнения функции open ().

Предположим, что клиент на одном  узле (magenta) желает использовать последовательный порт (/dev/ser1) на другом узле (wintermute). Клиент выполняет open(), указывая путь /net/wintermute/ dev/ser1.

Рассмотрим, что при этом произойдет:

1. Передача сообщения от клиента к местному менеджеру процессов. Осуществляется запрос, с кем войти в контакт, чтобы выполнить распознавание сетевого пути /net/wintermute/ dev/ser1. Т.к. менеджер сети работает через пространство имен "/net", менеджер процессов вернет сообщение о перенаправлении, указывающее, что клиент должен соединиться с локальным менеджером сети для получения дополнительной информации.
2. Клиент передает сообщение локальному менеджеру сети, заново запрашивая информацию о том, с кем он должен соединиться, в соответствии с именем сетевого пути. Локальный менеджер сети отвечает другим сообщением перенаправления, возвращая дескриптор узла, идентификаторы процесса и канала от менеджера процессов на узле wintermute.
3. Клиент создает связь с менеджером процессов на узле wintermute, еще раз запрашивая с кем нужно войти в контакт, согласно сетевому пути. Менеджер процессов на узле wintermute возвращает переадресацию, на сей раз с описателем узла, идентификаторами канала и процесса драйвера последовательного порта на его собственном узле.
4. Клиент создает связь с драйвером последовательного порта на узле wintermute, и, наконец, получает идентификатор, который можно использовать впоследствие для посылки/приема сообщений.

Теперь все сообщения клиент-сервер являются прямыми и проходят аналогично локальному случаю.

Терминология

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

Доменное имя узла - Последовательность, присоединяемая npm-qnet к имени узла. Вместе имя узла и доменное имя должны образовывать единую последовательность. Доменное имя является уникальным для всех узлов, которые общаются друг с другом.

Полное сетевое имя узла (FQNN) - Полная последовательность, объединяющая вместе имя узла и доменное имя. Например, имя узла — wintermute, и доменное имя — qnx.com.ru, то полное сетевое имя будет: wintermute. qnx.com.ru.

Сетевой каталог - Каталог, имя которого определяется через npm-qnet. Каждый сетевой каталог (их может быть на одном узле больше одного) имеет предопределенное имя. По умолчанию — /net.

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

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

Политика обслуживания (QoS)

Способ взаимодействия между двумя  узлами. По умолчанию QoS — loadbalance. Варианты преобразования имен:

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

• NDP — Node Discovery Protocol — посылает широковещательный запрос в сеть.
• DNS — к имени узла добавляется точка, результат передается функции TCP/IP gethostbyname ().
• File — ищет полное сетевое имя в статическом файле.

Качество обслуживания (QoS)

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

Сеть Neutrino предполагает следующие варианты QoS:

• Балансировка нагрузки (loadbalance). На уровне протокола npm-qnet принимаются решения, какие соединения использовать для передачи пакетов, в зависимости от текущей нагрузки и скорости передачи данных, определяемой io- net. Осуществляется попытка доставить пакеты, накопившиеся в очереди, как можно быстрее к удаленному узлу, используя все доступные и возможные физические соединения. Если возникает обрыв связи, периодически посылаются служебные пакеты с целью обнаружить восстановление соединения. Если соединение восстанавливается, оно включается в работу. Используется по умолчанию.

Рис. 6. Пример сети предприятия, с удаленным  компьютером

• Последовательный (sequential). Используется первое доступное соединение, до возникновения ошибки, тогда используется следующее доступное соединение, и так далее. Приоритеты соединений определяются пользователем. Как и с loadbalance QoS, вышедшие из строя соединения периодически проверяются на восстановление и, если соединение восстановлено, оно помещается в пул доступных соединений. Если используется соединение с меньшим приоритетом, и восстанавливается соединение с большим, то предпочтение отдается использованию соединения с большим приоритетом.
• Привилегированный (preferred). Аналогичен последовательному, с некоторыми отличиями. Когда последнее из списка доступных соединений, выходит из строя, включается политика loadbalance.
• Избыточный (redundant). Пакеты пересылаются по всем возможным соединениям одновременно. Если хотя бы одно соединение выходит из строя, то передача возобновляется только при восстановлении.