Меню
+7 (495) 785-95-25
sale@lcard.ru
sale@lcard.ru
Вы не вошли. | Поиск | Регистрация | Вход |
|
||||
|
ltrd: Ритмичность приема измеренных данных16-ти позиционный крейт заполнен LTR-27 и LTR-114 модулями. Обмен идет по Ethernet-интерфейсу через сервер ltrd в ОС реального времени QNX6. 1-й модуль настроен на измерения с частотой 100Гц по всем каналам. Остальные модули - с частотой 50Гц. Наблюдается период поступления данных с 1-го модуля в миллисекундах: ... Иногда есть отклонения, но закономерность просматривается довольно отчетливо... Полученная ранее рекомендация выдать команду #sysctl -w net.inet.tcp.ack-on-push=1 исполнена. Какие еще могут быть способы улучшить ритмичность поступающих данных с измерениями? Спасибо. |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхЛеонид, а из каких предпосылок следует, что крейт LTR-EU должен ритмичнее отдавать данные в Ehernet при существующем штатном низкоуровневом ПО с протоколом TCP/IP? |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхВозможно, есть "тонкая" настройка ПО крейта через ltrctl ( заставить FIFO - буфер крейта побыстрее отрпавлять на выход поступающие пакеты от модулей ). М.б. новые возможности появились в обновленной прошивке... Будем признательны за любой совет. |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхЛеонид, Ваш первый пост противоречит второму. Чтобы обеспечить "ритмичность" получения данных, нужно данные накопить в буфере (т.е. данные задержать), а потом (по каким-то признакам синхронизации) синхронно выдавать их из буфера. А чтобы "побыстрее отправлять", нужно наоборот: отправлять по первой возможности, а значит, "ритмичность" отправки отходит на второй план, поскольку возможности для отправки у процессора Blackfin возникают не синхронно (процессор несёт накладные расходы по обслуживанию протокола TCP/IP, по обслуживанию пересылок данных по DMA и на другие фоновые задачи). При этом, сам протокол TCP/IP (и его обслуживание) не предполагает ни строго синхронную передачу данных, ни гарантированную малую задержку передачи данных. |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхВ нашем случае роль синхронизатора вроде бы выполняет модуль: модуль программно настраивается на заданную частоту опроса. Полагаю что модуль, после выполнения очередного цикла опроса, без задержки отправляет результаты в контроллер крейта. Далее нужно чтобы ПО контроллера крейта, без накопления данных от других модулей, "как можно быстрее" отправило пакет в ltrd-сервер, а ltrd-сервер - в программу-клиент модуля. Желательно сделать все возможное, чтобы на этом пути не было накоплений буферов и задержек. Т.е. вопрос о гарантиях не ставится, вопрос об использовании всех возможностей. Cо совей стороны мы повысили приоритет ltrd-сервера и клиентов модулей по отношению к другим процессам проекта. |
|||
|
||||
|
Re: 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. Задержка будет значительно расти при приближении суммарного трафика к максимальной пропускной способности системы. |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхДополню, что задержка также может определятся логикой работы процессора в крейте. Т.е. штатная прошивка не оптимизирована для минимизации времени отправки относительно времени прихода данных (т.к. не специализирована для работы в ОС реального времени) и вполне может проверять наличие данных на отправку раз в какой-то период. кроме того, вторым источником задержки может служить определенные алгоритмы TCP, если они не отключены. Желаемое вами поведение может быть неприемлемо для штатной работы, т.к. быстрая отправка мелкими пакетами увеличивает нагрузку на сеть и снижает максимальную скорость. Все же штатная версия прошивки ориентирована на работу из ОС общего назначения, где задержки таких порядков могут (и даже больших) быть в самой ОС. Таким образом, не уверен что в штатной прошивке можно добиться большего (можно конечно проверить ради интереса на всех трех версиях 1.0.0.1, 2.0.0.0 и 3.0.0.x, но не уверен что это имеет большой смысл). А у Вас только 2 или 8/16 местные крейты? одноместные не используете? |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхКстати, методологически, если действительно в системе исследуются задержки относительно входов АЦП, то LTR11 в одноканальном режиме можно использовать как опорный канал, имеющий минимальную собственную задержку на уровне модуля (можно принять 4 мкс), и относительно этого канала можно измерить собственные задержки АЦП остальных модулей, если подавать на все входы АЦП один и тот же сигнал. Вместо LTR11 в качестве опорного канала можно использовать и вход метки синхронизации крейта LTR-EU или LTR43, если сигнал - TTL-совместимый. |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхМы тестируем два 16-ти позиционных крейта. Модули LTR27, LTR114 прошу рассматривать как тестовые поставщики данных через заданное для них время измерения. Задача не столько в том, чтобы накопить и записать данные для последующего анализа, сколько в ритмичном получении данных и обновлении их в памяти принимающего ПК для последующей раздачи другим программам проекта. Рекомендацию подключить каждый крейт отдельным кабелем выполнили. Видимо у нас приоритет в передаче данных от крейта к ПК именно мелкими пакетами и ритмично, т.к. объем данных заведомо меньше ограничений сети. В среднем мы получаем ритмичность -+2 мс при периоде 10мс, с которой можно примириться... Просьба к Алексею подробнее написать об "определенных алгоритмах TCP", если возможно - мы их отключим. Спасибо за внимание к вопросу. |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данных...Уже появилось два крейта... Абсолютная задержка в трактах измерения, значит, не играет роли (это второй поворот в постановке задачи с начала темы). А как не технический критерий "ритмичность -+2 мс при периоде 10мс" употребить к случаю получения данных от двух крейтов в ситуации, когда частоты преобразования (и выдачи данных) не когерентны в этих крейтах? Частота опорного генератора каждого крейта может отличаться на +-50*10^-6 от номинальной частоты. |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхСогласен, что "ритмичность" - не очень красиво звучит, м.б. погрешность соблюдения периода измерения для LTR-модуля при поступлении результатов измерения от ltrd-сервера к клиенту, обслуживающему данный модуль. У нас 2 крейта, но один крейт подключен к одному ПК, второй - к другому. Проверяется точность соблюдения периода поступления результатов измерения от 1-го крейта. М.б. более полно постановка проверки описана здесь: |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхИзвините, если повторюсь, для лучшего взаимопонимания: В проекте несколько ПК ( под ОС реального времени ) объединены в сеть. К ПК подключены LTR-крейты ( сейчас к 2-м ПК по одному 16-ти поз. крейту ). На данных ПК работает по одному экземпляру ltrd-сервера и по 16-ть экземпляров ltr-клиентов ( к каждому модулю свой клиент ). Каждый клиент настраивает соотв. модуль на нужную частоту опроса, обычно 50Гц или 100Гц. После настройки, клиент в бесконечном цикле "повисает" на вызове Клиент "надеется", что из ф-ции LTR..._Recv() он будет выходить с частотой, на которую настроен обслуживаемый модуль. После получения порции измерений, клиент преобразует результат в физ. величину и отправляет ( как и все остальные клиенты ) в общий сервер данных проекта и вновь "повисает" на LTR..._Recv(). Все остальные программы проекта в нужное им время забирают данные из сервера данных проекта. Пока мы видим, что клиенты получают данные с периодом 20-+2мс или 10-+2мс. Основную проблему сейчас составляют редкие задержки в 30-40мс ( что подробно описано в ссылке предыдущего сообщения). |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхЛеонид, у Вас планируется большая система, где много ПК, много сетей и много оборудования. Это значит, что идеальной связи по Ethernet точно не будет, и следует ждать (хотя бы редких) перезапросов TCP/IP, и значит, редкие задержки (десятки мс) передачи данных вполне возможны. Без введения синхронизации в такой большой системе задачу не решите. Кроме синхронизации, о которой я говорил выше, возможно развитие ПО крейтов LTR-EU в сторону протоколов Ethernet, обеспечивающих синхронизацию, в рамках договорной работы с L-Card. |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхПо поводу алгоритмов TCP, то думаю со стороны ПК тут уже вряд ли что отключишь, кроме того, что уже делали до этого. Есть алгоритм Нейгла со стороны крейта, который если включен, может приводить к дополнительным задержкам, если одна передача будет разбита на две из-за того, что в момент передачи пришла лишь часть кадра от модуля, но он включается в самом крейте (т.е. он влияет именно на отправку, поэтому настройка ПК тут не поможет). Если я правильно помню этот алгоритм включен в пошивке 2.0.0.0 и выключен в 1.0.0.1... Поэтому в прниципе можно сравнить работу этих прошивок на всякий случай. Но отличия в 2 мс может быть и из-за самого алгоритма крейта проверки наличия данных на отправку, что может быть более вероятнее. Правда я не до конца понял, вначлае речь шла именно о отклонениниях на 2 мс, а в последних постах Вы ссылаетесь уже на проблему редкого отклонения в 30-40 мс, о чем раньше вообще не упоминалось... Какую проблемы Вы все же решаете или обе? Более того в ссылке это выглядит не очень реально, т.к. если сети разделены физически, то как они могут друг на друга влять. Либо что-то там не досказано и обмен по этим интерфейсам приводит к обмену между двумя ПК, который уже влият... ведь если ПК не будут соеденены по второму интерфейсу, они же никак не будут оказывать друг на друга влияния? Ну если есть потери пакетов, то задачу реального времени с гарантированной доставкой вообще вряд ли можно решить... но я не думаю, что они доложны быть, при выделенных подключенях между каждым ПК и каждым крейтом. Кстати интересно, а есть в qnx программы захвата трафика, типа wirshark, tcpdump и т.п. |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхЕсли системный интегратор большой индустриальной системы идёт на авантюру, делая ставку на то, что никогда не будет перезапросов TCP/IP из-за потери пакетов (даже при сетевых соединениях точка-точка), то эксперименты с частью системы (только два компьютера) вообще бессмысленны, поскольку тогда нужно экспериментировать с максимальной конфигурацией всего оборудования, в наихудших условиях электромагнитной обстановки, и если эти условия не будут изменены при реальной эксплуатации (что невозможно реально гарантировать, если вдуматься). Мне известен реальный курьёзный случай (по моему старому месту работы), когда при многочасовых госиспытаниях большого вычислительного комплекса исполнитель (под придуманным наспех предлогом) вынужден был закрыть туалеты в здании, поскольку в последний момент было обнаружено, что тест вычислительного комплекса даёт сбой, когда зажигают лампочку в туалете... Это к вопросу реальности обеспечения "наихудшей" электромагнитной обстановки при испытаниях. В конце концов, есть ГОСТы на ЭМС для электроники, которые предписывают выдерживать стандартые тесты. Например, для интерфейсных линий, стандартный тест микросекундных импульсов 8-20 мкс 1 кВ (это навскидку, можно уточнить по конкретным ГОСТам). Леонид, у Вас есть основание надеяться, что такой импульс не вызовет потерю пакета Ethernet? Эта ведь имитация электростатического импульса при реальной эксплуатации! Отредактировано Гарманов Александр (04.12.2016 08:57:50) |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхАлексей, действительно в начале мы смотрели на соблюдение частоты поступления данных с первого модуля первого 16-ти позиционного крейта. Так что на первом этапе выясняли: преодолима ли проблема погрешности периода поступления данных с модуля -+2мс. Далее начали делать проверки при 2-х работающих 16-ти позиционных крейтах. Здесь начали проявляться случайные редкие задержки в 30-40мс и эта проблема стала первоочередной. При исследовании "больших" задержек последовательно пришли к конфигурации, в которой каждый крейт подключается к своему ПК по "выделенной" линии связи и поддерживается отдельным программным стеком TCP-IP. Была надежда, что при такой конфигурации "большие" задержки исчезнут, а с "малыми" мы примиримся. Обмен между двумя ПК действительно ведется, но с использованием вторых сетевых интерфейсов и другого программного стека TCP-IP и qnet. Программа tcpdump штатно поддерживается в QNX6, опыта ее использования нет. Как Вы рекомендуете с ее помощью установить природу "больших" задержек? Александр, спасибо за поучительную историю. Не думал, что потери пакетов могут происходить на короткой линии между крейтом и ПК при прямом соединении. Т.к. "длинные" задержки наблюдаем только при втором работающем крейте, то не предполагаете ли Вы, что второй крейт является источником помех в сетевом канале 1-го крейта (лампочкой в туалете)? Буду признателен за помощь в поиске причины "больших" задержек. |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхЛеонид пишет:
Априори известно, что устройство А может влиять на устройство В. Но, чтобы предполагать, у техподдержки нет исходных данных. В данном случае, предполагать (и сообщать подробные исходные данные техподдержке при возникновении проблемы) должен системный интегратор этой системы. С другой стороны, редкие перезапросы TCP/IP, как я объяснял выше, не являются проблемой, а являются штатной ситуацией. Но, не факт, что это именно перезапросы TCP/IP, а не какой-то программный эффект в ПК. |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхЛеонид пишет:
Конкретно tcpdump я не пользовался, но возможности насколько я знаю у нее схожи с Wireshark. Т.е. она может сохранять все Ethernet пакеты, передаваемые в сети. Соответственно, можно посмотреть, чем отличаются передачи в эти моменты. По крайней мере повторные передачи она должна показывать. Но как конкретно в ней это делается - это я не скажу. |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхВ описанной конфигурации с "длинными" задержками рассматривали вывод tcpdump. В момент "длинной" задержки не видно повторного обмена пакетами: пакеты прекращают приниматься-отправляться в течение примерно 20мс. При нормальном обмене, пакеты между ПК и крейтом "ритмично" курсируют примерно каждые 800 мкс. Вывод распечаток периодичности приема измерений с модуля и tcpdump направлю на email Алексея. Подключили крейты на вторые сетевые интерфейсы ПК. "Длинные" задержки исчезли! Два сетевых интерфейса ПК имеют одинаковые VID (0x8086) и разные DID (Device ID), т.е. разные микросхемы по-видимому. Пока вывод такой, что предположение Александра о природе "длинных" задержек в действиях протокол TCP-IP при потере пакетов не подтверждается... |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхАктивное сетевое оборудование может вносить задержки, терять пакеты(!) и дробить пакеты, в зависимости от реализации (а скорее, в зависимости от стоимости этого оборудования). В материнской плате Ethernet - порты могут быть реализованы, например, на основе коммутатора гигабитного Ehternet. Нам встречались такие реализации коммутаторов, которые редко теряют UDP-пакеты! Порты с одним Device ID, по всей видимости, - коммутируемые (это нужно перепроверять). А ведь, по сути, подключение через коммутатор, не является подключением "точка - точка". По поводу "предположения Александра": существование ГОСТов и стандартных требований ЭМС к электронике - это факт, а не предположение. |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхпростите за ошибку, должен был написать: При нормальном обмене, пакеты между ПК и крейтом "ритмично" курсируют примерно каждые 8000 мкс или через 8 мс. Видимо получение данных с модулей синхронно с измерениями имеет предел примерно 100Гц . Чаще - через массивы измеренных данных... Наши сетевые устройства имеют разные Device ID LAN 1: Intel I217V LAN 2: Intel I211 |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхНа конец сегодняшнего дня мы имеем стабильный прием результатов измерений от каждого модуля с частотой (20мс -+ 2 мс), что нас примерно устраивает. Крейты и ПК подключены через общий сетевой коммутатор проекта. Решение состоит в организации подсетей таким образом, что крейты взаимодействуют со вторыми сетевыми интерфейсами пром. платы PCA-6028. http://downloadt.advantech.com/ProductF … 102734.pdf Объяснить причину "длинных" задержек при подключении крейтов через первые сетевые интерфейсы не удается. |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхАлександр! Вы писали о возможности "...развития ПО крейтов LTR-EU в сторону протоколов Ethernet, обеспечивающих синхронизацию, в рамках договорной работы с L-Card". Каким образом можно подробнее обсудить вариант подобной доработки? |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхЛеонид пишет:
Леонид. А что, штатные возможности синхронизации крейтов LTR-EU разве нельзя задействовать? А внешнюю систему единого времени не хотите задействовать в проекте? - Это решается технически проще, чем модифицировать встроенное ПО крейта LTR-EU. - Эти вопросы, скорее всего, решаются в рамках техподдержки. Отвечаю на Ваш вопрос. Начинать обсуждение заказной работы следует через наш отдел продаж. Наличие ТЗ или ТТ (на эту работу) крайне желательно. Существуют и первые простые организационное вопросы любой подобной работы, см. http://www.lcard.ru/support/faq/faq_develop_order , - Естественно, обсуждения заказных работ - не на данном форуме. Протоколов реального времени на Ethernet довольно много, адаптированных для решения разных задач. Например, вот неплохая обзорная статья: http://www.cta.ru/cms/f/434753.pdf Отредактировано Гарманов Александр (06.12.2016 22:56:58) |
|||
|
||||
|
Re: ltrd: Ритмичность приема измеренных данныхМы пытаемся использовать крейтовую систему LTR как систему измерений "реального времени". При всей справедливой критике по поводу возможных задержек в протоколе TCP-IP сейчас получаем измерения с периодом 10 -+2мс, 20 -+2мс. В п. 4.6.5.1 РЭ описан проект развития ПО : применение меток синхронизации в UNIX Time формате (с точностью до секунды). Возможно ли в проекте изменения в ПО крейта и в API пользователя таким образом, чтобы при приеме каждого очередного результата измерения с модуля вместе с результатом так же принималось время поступления измерения в крейт с точностью до миллисекунды? Таким образом была бы снята погрешность -2...+2мс периода поступления данных. |
Адрес: 117105, Москва, Варшавское шоссе, д. 5, корп. 4, стр. 2
Многоканальный телефон:
+7 (495) 785-95-25
Отдел продаж: sale@lcard.ru
Техническая поддержка: support@lcard.ru
Время работы: с 9-00 до 19-00 мск