Форум: Техническая поддержка

16-ти позиционный крейт заполнен LTR-27 и LTR-114 модулями.

Обмен идет по Ethernet-интерфейсу через сервер ltrd в ОС реального времени QNX6.

1-й модуль настроен на измерения с частотой 100Гц по всем каналам.

Остальные модули - с частотой 50Гц.

Наблюдается период поступления данных с 1-го модуля в миллисекундах:

...
10.5
10.5
10.5
8.5
10.5
10.5
10.5
8.5
...

Иногда есть отклонения, но закономерность просматривается довольно отчетливо...

Полученная ранее рекомендация выдать команду

#sysctl -w net.inet.tcp.ack-on-push=1

исполнена.

Какие еще могут быть способы улучшить ритмичность поступающих данных с измерениями?

Спасибо.

Леонид, а из каких предпосылок следует, что крейт LTR-EU должен ритмичнее отдавать  данные в Ehernet при существующем штатном низкоуровневом ПО с протоколом TCP/IP?

Возможно, есть "тонкая" настройка ПО крейта через ltrctl ( заставить FIFO - буфер крейта побыстрее отрпавлять на выход поступающие пакеты от модулей ).

М.б. новые возможности появились в обновленной прошивке...

Будем признательны за любой совет.

Леонид, Ваш первый пост противоречит второму. Чтобы обеспечить "ритмичность" получения данных, нужно данные накопить в буфере (т.е. данные задержать), а потом (по каким-то признакам синхронизации) синхронно выдавать их из буфера. А чтобы "побыстрее отправлять", нужно наоборот:  отправлять по первой возможности, а значит, "ритмичность" отправки отходит на второй план, поскольку возможности для отправки у процессора Blackfin возникают не синхронно (процессор несёт накладные расходы по обслуживанию протокола TCP/IP, по обслуживанию пересылок данных по DMA и на другие фоновые задачи). При этом, сам протокол TCP/IP (и его обслуживание) не предполагает ни строго синхронную передачу данных, ни гарантированную малую задержку передачи данных.

В нашем случае роль синхронизатора вроде бы выполняет модуль: модуль программно настраивается на заданную частоту опроса.

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

Далее нужно чтобы ПО контроллера крейта, без накопления данных от других модулей, "как можно быстрее" отправило пакет в ltrd-сервер, а ltrd-сервер - в программу-клиент модуля.

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

Т.е. вопрос о гарантиях не ставится, вопрос об использовании всех возможностей.

Cо совей стороны мы повысили приоритет ltrd-сервера и клиентов модулей по отношению к другим процессам проекта.

Леонид, в таком случае, "ритмичность приёма измеренных данных" не имеет прямого отношения к параметру, который Вам требуется оптимизировать, а именно: время задержки всего тракта преобразования - передачи - приёма данных (от аналогового входа АЦП до получения данных в прикладном ПО верхнего уровня).  Но в таком случае:

1.  Почему же выбраны АЦП LTR27 и LTR114, имеющие немалые задержки преобразования-обработки данных, а не LTR11? Например, LTR27 на частоте сбора 100 Гц имеет суммарную цифровую задержку данных (алгоритмы ЦОС) 6 мс + задержка аналогового ФНЧ (порядка 5 мс) с частотой среза 100 Гц + задержка  1-1,5 мс передачи самого LTR27 и преобразователя ПНЧ в cубмодулях H-27x  - итого, не менее 12 мс.  В отличие от LTR27, LTR11 имеет задержку порядка единиц мкс на преобразование и передачу данных + коммутационную задержку, зависящую от количества каналов и частоты АЦП, и, при соответствующих параметрах, задержки LTR11 будут кардинально меньше, чем у LTR27.

2. Задержка отправки данных крейта LTR напрямую зависит от оперативности откачки данных из крейта, т.е. в конечном итоге, - от эффективности ПО верхнего уровня, откачивающего данные.

3. Задержка TCP/IP будет минимальная при условиях:  режим передачи 100 Mb/s full-duplex, при соединении "точка - точка" (а не в общую сеть), при хорошей связи, не вызывающей переповторы передачи данных.

4. Задержка будет значительно расти при приближении суммарного трафика к максимальной пропускной способности системы.

Дополню, что задержка также может определятся логикой работы процессора в крейте. Т.е. штатная прошивка не оптимизирована для минимизации времени отправки относительно времени прихода данных (т.к. не специализирована для работы в ОС реального времени) и вполне может проверять наличие данных на отправку раз в какой-то период. кроме того, вторым источником задержки может служить определенные алгоритмы TCP, если они не отключены. Желаемое вами поведение может быть неприемлемо для штатной работы, т.к. быстрая отправка мелкими пакетами увеличивает нагрузку на сеть и снижает максимальную скорость. Все же штатная версия прошивки ориентирована на работу из ОС общего назначения, где задержки таких порядков могут (и даже больших) быть в самой ОС. Таким образом, не уверен что в штатной прошивке можно добиться большего (можно конечно проверить ради интереса на всех трех версиях 1.0.0.1, 2.0.0.0 и 3.0.0.x, но не уверен что это имеет большой смысл).

А у Вас только 2 или 8/16 местные крейты? одноместные не используете?

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

Вместо LTR11 в качестве опорного канала  можно использовать и вход метки синхронизации крейта LTR-EU или LTR43, если сигнал - TTL-совместимый.
Возможно также метки синхронизации привязать к системе единого времени, как это сообщено в http://www.lcard.ru/node/803 .

Мы тестируем два 16-ти позиционных крейта.

Модули LTR27, LTR114 прошу рассматривать  как тестовые поставщики данных через заданное для них время измерения.

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

Рекомендацию подключить каждый крейт отдельным кабелем выполнили.

Видимо у нас приоритет в передаче данных от крейта к ПК именно мелкими пакетами и ритмично, т.к. объем данных заведомо меньше ограничений сети.

В среднем мы получаем ритмичность -+2 мс при периоде 10мс, с которой можно примириться...

Просьба к Алексею подробнее написать об "определенных алгоритмах TCP", если возможно - мы их отключим.

Спасибо за внимание к вопросу.

...Уже появилось два крейта... Абсолютная задержка в трактах измерения, значит, не играет роли (это второй поворот в постановке задачи с начала темы).  А как не технический критерий "ритмичность -+2 мс при периоде 10мс" употребить к случаю получения данных от двух крейтов в ситуации, когда частоты преобразования (и выдачи данных) не когерентны в этих крейтах?  Частота опорного генератора каждого крейта  может отличаться на +-50*10^-6 от номинальной частоты. 
Но если всё-таки речь идёт о синхронизации отсчётов от двух крейтов на верхнем программном уровне с точностью +-1 мс относительно периодических меток синхронизации, то это алгоритмически возможно на верхнем программном уровне (если аппаратно один крейт транслирует синхрометки другому и если в каждом из крейтов имеется хотя бы один модуль, работающий на частоте преобразования не менее 1 кГц, а желательно, больше), но тогда ЭТО нужно обсуждать, а не "равномерность" выдачи по Ethernet. Поскольку, если на верхнем уровне решить задачу синхронизации отчётов обоих крейтов, то задача "ритмично выдавать для последующей раздачи другим программам проекта" станет возможной.

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

У нас 2 крейта, но один крейт подключен к одному ПК, второй - к другому. Проверяется точность соблюдения периода поступления результатов измерения от 1-го крейта.

М.б. более полно постановка проверки описана здесь:

http://forum.kpda.ru/index.php/topic,14 … l#msg11843

Извините, если повторюсь, для лучшего взаимопонимания:

В проекте несколько ПК ( под ОС реального времени ) объединены в сеть.

К ПК подключены LTR-крейты ( сейчас к 2-м ПК по одному 16-ти поз. крейту ).

На данных ПК работает по одному экземпляру ltrd-сервера и по 16-ть экземпляров ltr-клиентов ( к каждому модулю свой клиент ).

Каждый клиент настраивает соотв. модуль на нужную частоту опроса, обычно 50Гц или 100Гц.

После настройки, клиент в бесконечном цикле "повисает" на вызове
LTRNNN_Recv ( ) и ждет очередного результата измерений по задействованным каналам модуля. Здесь NNN - цифровок обозначение модуля.

Клиент "надеется", что из ф-ции LTR..._Recv() он будет выходить с частотой, на которую настроен обслуживаемый модуль.

После получения порции измерений, клиент преобразует результат в физ. величину и отправляет ( как и все остальные клиенты ) в общий сервер данных проекта и вновь "повисает" на LTR..._Recv().

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

Пока мы видим, что клиенты получают данные с периодом 20-+2мс или 10-+2мс.

Основную проблему сейчас составляют редкие задержки в 30-40мс ( что подробно описано в ссылке предыдущего сообщения).

Леонид, у Вас планируется большая система, где много ПК, много сетей и много оборудования. Это значит, что идеальной связи по Ethernet точно не будет, и следует ждать (хотя бы редких) перезапросов TCP/IP, и значит, редкие задержки (десятки мс) передачи данных вполне возможны. Без введения синхронизации в такой большой системе задачу не решите. Кроме  синхронизации, о которой я говорил выше, возможно развитие ПО крейтов LTR-EU в сторону протоколов Ethernet, обеспечивающих синхронизацию, в рамках договорной работы с L-Card.

По поводу алгоритмов TCP, то думаю со стороны ПК тут уже вряд ли что отключишь, кроме того, что уже делали до этого. Есть алгоритм  Нейгла  со стороны крейта, который если включен, может приводить к дополнительным задержкам, если одна передача будет разбита на две из-за того, что в момент передачи пришла лишь часть кадра от модуля, но он включается в самом крейте (т.е. он влияет именно на отправку, поэтому настройка ПК тут не поможет). Если я правильно помню этот алгоритм включен в пошивке 2.0.0.0 и выключен в 1.0.0.1... Поэтому в прниципе можно сравнить работу этих прошивок на всякий случай. Но отличия в 2 мс может быть и из-за самого алгоритма крейта проверки наличия данных на отправку, что может быть более вероятнее.

Правда я не до конца понял, вначлае речь шла именно о отклонениниях на 2 мс, а в последних постах Вы ссылаетесь уже на проблему редкого отклонения в 30-40 мс, о чем раньше вообще не упоминалось... Какую проблемы Вы все же решаете или обе? Более того в ссылке это выглядит не очень реально, т.к. если сети разделены физически, то как они могут друг на друга влять. Либо что-то там не досказано и обмен по этим интерфейсам приводит к обмену между двумя ПК, который уже влият... ведь если ПК не будут соеденены по второму интерфейсу, они же никак не будут оказывать друг на друга влияния?

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

Кстати интересно, а есть в qnx программы захвата трафика, типа wirshark, tcpdump и т.п.

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

Мне известен реальный курьёзный случай (по моему старому месту работы), когда при многочасовых госиспытаниях большого вычислительного комплекса исполнитель (под придуманным наспех предлогом) вынужден был закрыть туалеты в здании, поскольку в последний момент было обнаружено, что тест вычислительного комплекса даёт сбой, когда зажигают лампочку в туалете...  Это к вопросу реальности обеспечения "наихудшей" электромагнитной обстановки при испытаниях.

В конце концов, есть ГОСТы на  ЭМС для электроники, которые предписывают выдерживать стандартые тесты. Например, для интерфейсных линий, стандартный тест микросекундных импульсов 8-20 мкс 1 кВ  (это навскидку, можно уточнить по конкретным ГОСТам). Леонид, у Вас есть основание надеяться, что такой импульс не вызовет потерю пакета Ethernet? Эта ведь имитация электростатического импульса при реальной эксплуатации!

Отредактировано Гарманов Александр (04.12.2016 08:57:50)

Алексей,

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

Так что на первом этапе выясняли: преодолима ли проблема погрешности периода поступления данных с модуля -+2мс.

Далее начали делать проверки при 2-х работающих 16-ти позиционных крейтах. Здесь начали проявляться случайные редкие задержки в 30-40мс и эта проблема стала первоочередной.

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

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

Обмен между двумя ПК действительно ведется, но с использованием вторых сетевых интерфейсов и другого программного стека TCP-IP и qnet.

Программа tcpdump штатно поддерживается в QNX6, опыта ее использования нет. Как Вы рекомендуете с ее помощью установить природу "больших" задержек?

Александр, спасибо за поучительную историю.

Не думал, что потери пакетов могут происходить на короткой линии между крейтом и ПК при прямом соединении.

Т.к. "длинные" задержки наблюдаем только при втором работающем крейте, то не предполагаете ли Вы, что второй крейт является источником помех в сетевом канале 1-го крейта (лампочкой в туалете)?

Буду признателен за помощь в поиске причины "больших" задержек.

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

Конкретно tcpdump я не пользовался, но возможности насколько я знаю у нее схожи с Wireshark. Т.е. она может сохранять все Ethernet пакеты, передаваемые в сети. Соответственно, можно посмотреть, чем отличаются передачи в эти моменты. По крайней мере повторные передачи она должна показывать. Но как конкретно в ней это делается - это я не скажу.

В описанной конфигурации с "длинными" задержками рассматривали вывод tcpdump. В момент "длинной" задержки  не видно повторного обмена пакетами: пакеты прекращают приниматься-отправляться в течение примерно 20мс. При нормальном обмене, пакеты между ПК и крейтом "ритмично" курсируют примерно каждые 800 мкс.

Вывод распечаток периодичности приема измерений с модуля и tcpdump направлю на email Алексея.

Подключили крейты на вторые сетевые интерфейсы ПК. "Длинные" задержки исчезли! Два сетевых интерфейса ПК имеют одинаковые VID (0x8086) и разные DID (Device ID), т.е. разные микросхемы по-видимому.

Пока вывод такой, что предположение Александра о природе "длинных" задержек в действиях протокол TCP-IP при потере пакетов не подтверждается...

Активное  сетевое оборудование может вносить задержки, терять пакеты(!) и дробить пакеты, в зависимости от реализации (а скорее, в зависимости от стоимости этого оборудования). В материнской плате Ethernet - порты могут  быть реализованы, например, на основе коммутатора гигабитного Ehternet. Нам встречались такие реализации коммутаторов, которые редко теряют UDP-пакеты!  Порты с одним Device ID, по всей видимости,  - коммутируемые (это нужно перепроверять). А ведь, по сути, подключение через коммутатор, не является подключением "точка - точка".

По поводу "предположения Александра": существование ГОСТов и стандартных требований  ЭМС к электронике - это факт, а не предположение.

простите за ошибку, должен был написать:

При нормальном обмене, пакеты между ПК и крейтом "ритмично" курсируют примерно каждые 8000 мкс или через 8 мс.

Видимо  получение данных с модулей синхронно с измерениями имеет предел примерно 100Гц .

Чаще - через массивы измеренных данных...

Наши сетевые устройства имеют разные Device ID

LAN 1: Intel I217V

LAN 2: Intel I211

На конец сегодняшнего дня мы имеем стабильный прием результатов измерений от каждого модуля с частотой (20мс -+ 2 мс), что нас примерно устраивает.

Крейты и ПК подключены через общий сетевой коммутатор проекта.

Решение состоит в организации подсетей таким образом, что крейты взаимодействуют со вторыми сетевыми интерфейсами пром. платы PCA-6028.

http://downloadt.advantech.com/ProductF … 102734.pdf

Объяснить причину "длинных" задержек при подключении крейтов через первые сетевые интерфейсы не удается.

Александр!

Вы писали о возможности "...развития ПО крейтов LTR-EU в сторону протоколов Ethernet, обеспечивающих синхронизацию, в рамках договорной работы с L-Card".

Каким образом можно подробнее обсудить вариант подобной доработки?
Спасибо.

Леонид. А что, штатные возможности синхронизации крейтов LTR-EU разве нельзя задействовать? А внешнюю систему единого времени не хотите задействовать в проекте? - Это решается технически проще, чем модифицировать встроенное ПО крейта LTR-EU. - Эти вопросы, скорее всего, решаются в рамках техподдержки.

Отвечаю на Ваш вопрос. Начинать обсуждение заказной работы следует через наш отдел продаж. Наличие ТЗ или ТТ (на эту работу) крайне желательно. Существуют и первые простые организационное вопросы любой подобной работы, см. http://www.lcard.ru/support/faq/faq_develop_order , - Естественно, обсуждения заказных работ - не на данном форуме.

Протоколов реального времени на Ethernet довольно много, адаптированных для решения разных задач. Например, вот неплохая обзорная статья: http://www.cta.ru/cms/f/434753.pdf
Какие-то из этих протоколов можно внедрить в LTR-EU, при наличии соответствующей постановки задачи и финансирования. При соответствующих вложениях можно и сам контроллер крейта LTR-EU модифицировать в сторону более производительного процессора, гигабитного Ethernet и прочих радостей. Почему бы вашему предприятию не вложиться в развитие отечественной измерительной системы LTR? - этот вопрос не только к Леониду.

Отредактировано Гарманов Александр (06.12.2016 22:56:58)

Мы пытаемся использовать крейтовую систему LTR как систему измерений "реального времени". При всей справедливой критике по поводу возможных задержек в протоколе TCP-IP сейчас получаем измерения с периодом 10 -+2мс, 20 -+2мс.

В п. 4.6.5.1 РЭ описан проект развития ПО : применение меток синхронизации в UNIX Time формате (с точностью до секунды).

Возможно ли в проекте  изменения в ПО крейта и в API пользователя таким образом, чтобы при приеме каждого очередного результата измерения с модуля вместе с результатом так же принималось время поступления измерения в крейт с точностью до миллисекунды?

Таким образом была бы снята погрешность -2...+2мс периода поступления данных.