Прием потока данных

Захват, обработка и генерирование сигнала
Ответить
Аватара пользователя
Juri
I/O
I/O
Сообщения: 263
Зарегистрирован: 19 апр 2017, 23:06
Версия LabVIEW: 2021
Благодарил (а): 13 раз
Поблагодарили: 6 раз

Прием потока данных

Сообщение Juri »

Написан тулкит приема потока данных (массив амплитуд) из сети ethernet 12800 байт в секунду в самом простом случае или тоже кол-во умноженное на 3 или на 4 если в сети несколько потоков от разных приборов. При этом происходит копирование одних и тех же байт 2 раза: 1 раз - из dll в тулкит, там они накапливаются до нужного объема, 2 раз - когда накопился нужный объем данных за 1 секунду, он посылается в очередь.
На скриншоте Read.vi забирает из очереди массив байт за одну секунду. Далее уже происходит парсинг и обработка.
На обычном компьютере все работает хорошо, но на одноплатнике уже приходится заниматься оптимизацией, т.к. на пределе загрузки цп, пакеты теряются. Если я не могу избавиться от копирования байт в первом случае, то хочу хотябы избавиться от копирования во второй раз. Никогда не пользовался палитрой Memory control. Сделана ли она именно для такой задачи? Дублирования данных не будет? Еще, ни разу не пользовался опцией Channel Writer. Она тоже для таких случаев?
Вложения
Screenshot_1.png
Аватара пользователя
Juri
I/O
I/O
Сообщения: 263
Зарегистрирован: 19 апр 2017, 23:06
Версия LabVIEW: 2021
Благодарил (а): 13 раз
Поблагодарили: 6 раз

Re: Прием потока данных

Сообщение Juri »

Второй вопрос вдогонку. В примере есть 3 участка массива байт (в disabled структуре), который можно парсить одной vi, однако это сильно ухудшает производительность. Такой эффект возникает только когда код программы загружается из lvlibp. Первый график загрузки цп - когда используется суб vi. Второй график - когда код vi был продублирован три раза без использования суб vi. Игрался разными свойствами vi в меню Execution, но ничего не помогает. Впечатление, что свойство inline не работает если код загружен из lvlibp. Это лечится?

upd: Вероятно в LV21 этот косяк устранен
Вложения
2.png
Последний раз редактировалось Juri 21 апр 2023, 18:55, всего редактировалось 1 раз.
Artem.spb

Activity Автор
professor
professor
Сообщения: 3396
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: Прием потока данных

Сообщение Artem.spb »

Juri писал(а): 13 мар 2023, 17:48 Написан тулкит приема потока данных (массив амплитуд) из сети ethernet 12800 байт в секунду в самом простом случае или тоже кол-во умноженное на 3 или на 4 если в сети несколько потоков от разных приборов.
Из вашей картинки всё сразу очевидно, что даже хрустальный шар не нужен.
Написан кем?
При этом происходит копирование одних и тех же байт 2 раза:
Происходит зачем? Если авт ор вы, то избавьтесь от двойного копирования
1 раз - из dll в тулкит, там они накапливаются до нужного объема, 2 раз - когда накопился нужный объем данных за 1 секунду, он посылается в очередь.
Тут первая непонятнка с методом накопления, но главный вопрос: что мешает или сразу брать больше, или не копить, а отправлять дальше?
На скриншоте Read.vi забирает из очереди массив байт за одну секунду. Далее уже происходит парсинг и обработка.
И вот это не понятно. Вы копите данные с помощью очереди?
т.к. на пределе загрузки цп, пакеты теряются.
Работать на пределе загрузки вообще так себе затея
Дублирования данных не будет?
Это зависит от прямых рук программиста. Избежать ненужного копирования можно и без особых палитр
Artem.spb

Activity Автор
professor
professor
Сообщения: 3396
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 49 раз
Поблагодарили: 172 раза
Контактная информация:

Re: Прием потока данных

Сообщение Artem.spb »

Juri писал(а): 13 мар 2023, 19:02 Второй вопрос вдогонку. В примере есть 3 участка массива байт (в disabled структуре), который можно парсить одной vi,
Если Unflatten From String вы называете парсингом, то я бы призадумался над оптимизацией самого метода.
И если это некий массив, что мешает его разом конвертировать в последовательность чего-то там?
Если нет, то воспользуйтесь хотя бы String To Byte Array для начала
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2210
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 27 раз
Поблагодарили: 26 раз

Re: Прием потока данных

Сообщение Borjomy_1 »

При такой "мощной" обработке и потоке данных возникают сильные сомнения, что проблема в парсинге и копировании данных. Используйте профилер, чтобы определить VI, которая грузит процессор. И уже с ней надо разбираться.
Аватара пользователя
Juri
I/O
I/O
Сообщения: 263
Зарегистрирован: 19 апр 2017, 23:06
Версия LabVIEW: 2021
Благодарил (а): 13 раз
Поблагодарили: 6 раз

Re: Прием потока данных

Сообщение Juri »

Я оптимизировал код, кое-где избавился от создания промежуточных кластеров данных, но самый главный вывод сделал в том, что если какая-то VI имеет priority "time critical priority (highest)" и при этом отправляет данные в очередь, то необходимо озаботиться, чтобы читающая из этой очереди VI тоже имела такой priority. иначе отправляющая VI будет тормозить, и не важно мало или много байт передается в очереди.
Ответить
  • Похожие темы
    Ответы
    Просмотры
    Последнее сообщение

Вернуться в «Обработка сигнала»