1)Просьба сформулировать требования к сети для подключения крейтов LTR.
Если у LCard есть документ по этому поводу, прошу выслать или  указать ссылку.

2) Заказчик настоял, чтобы компьютер, собирающий данные с LTR, находился в одном сегменте сети, а сами LTR в другом.
В результате наш софт, когда подключаем к единому сегменту, работает замечательно, а когда в соответствии с требованиями заказчика - постоянно прерываемся из-за сбоев (коды -79, -73, -10010 и пр.).
Будем признательны, если что-то по этому поводу порекомендуете.

А какие версии прошивки крейта у Вас? Если ниже последней (3.0.0.17), то лучше обновить.

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

А как именно у Вас организована сеть у клиента? Что отвечает за разделение сетей? Есть там NAT и если да, настроен ли проброс портов и каким образом и т.д. Также вопрос наличия другого трафика, не может ли возникать полная загрузка канала другим трафиком в этой сети?
Также на всякий случай следует проверить отсутствие пересечения IP адресов других устройств с адресами крейтов в сети клиента.

Есть ли возможность записать на ПК клиента обмен данными с помощью программы вроде Wireshark и прислать нам?

1) Высылаю файл wireshark, полученный в результате запуска сбора пакетов на wireshark, затем запуска нашей программы сбора данных с 2 крейтов с 3 и 4 модулями LTR (114-ые, 212-ые и 12-й - 7 потоков сбора данных модулями и основной поток записи данных), затем фиксируем прекращение сбора данных и после небольшой задержки завершаем программу сбора данных с LTR, а затем сбор пакетов wireshark.

2) Описание сети

2.1) Два крейта LTR, разнесенные на 20м, подключены к коммутатору в шкафу одного из этих крейтов.
В работающем (временном) варианте в том же шкафу устанавливаем компьютер с ltrd, на котором одна программа нашей система собирает измерительные данные с LTR, а другая - картинки с двух видеокамер.
Все прекрасно работает.

2.2) Другой (основной) вариант:
далее от упомянутого коммутатора по меди через 2 репитера через 100м подключение к коммутатору, от которого по оптике подключение через километры к местному провайдеру, от которого далее подключение компьютера, на котором крутится ltrd и наша система.
Сбор данных с LTR довольно быстро нарушается.
Сбор ведется порциями по 2сек.
Иногда в сессии таких порций собираем несколько десятков до прекращения работы, иногда одну порцию, довольно часто вообще не собираем.

Что-то файлы wireshark до нас не дошли, Вы на support высылали?
А  поставить что-то вроде ПК (возможно одноплатного) на стороне крейта, чтобы там был ltrd, а конечный софт уже в пользовательской сети, такой возможности нет?

Так как файл wireshark (251107-1647.7z) через форум не дошел, высылаю на support.

1. Высылаю файл wireshark,который получили так:
1.1. Запустили запись wireshark коммуникации с крейтами 192.168.13.87 и 192.168.13.97
1.2. Запустили наше приложение сбора измерительных данных.
1.3. Дождались аварийного завершения приложения.
1.4. Остановили запись wireshark.

Использованный компьютер i3 содержит процессор i3.
Дополнительно высылаю скриншот работы i3 (i3.jpg).
В левом-верхнем окне видно, что cron периодически перезапускает приложение, которое аварийно останавливается после не слишком продолжительной работы.
В правом-верхнем окне видно, что коммуникация с крейтом 192.168.13.87 содержит большое число сбоев.
В нижнем окне видим, что работа некоторая происходит от перезапуска до перезапуска: сначала собрал 15176 порций, далее 15184.

2. Проверка, что дело в компьютере, не подтвердила это предположение.
Другой компьютер i5, который мы использовали при правильном подключении к крейтам (непосредственное подключение к крейтам без всяких дополнительных сегментов сети), содержит процессор i5.
При правильном подключении с ним никаких проблем не было.
Высылаю скриншот i5.jpg при его длительной работе при правильном подключении.
Видим, что перезапуски не требуются (все время один и тот же PID).

Компьютер i5 отнесли и подключили на место i3.
Получили те же проблемы, что и с i3.
Вывод: дело в сетке.

3. Дополнительно высылаю скрины ltrmanager (ltrmanager.7z), на которых видна коммуникация модулей с i5 при правильном подключении.

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

5. Дополнительный вопрос: какое mtu выставлено в ethernet драйверах ltr. Если можно изменить mtu, как это сделать?

Да. Забыл важное. При работе i5 при правильном подключении время берем с компьютера при получении очередной 2сек порции данных. В этом случае интервал между последовательными получениями порций 2сек с точностью до 1мс. При неправильном подключении этот интервал в среднем около 2сек, но разброс от 0.018 до 5.012сек.

В сети выставлено MTU 1500.

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

А по поводу большого процента потерь пакетов (там где 5.5% на скриншоте), если такой тест произвести не с крейтом, а с пк, который вовне (i3), проверить путь до ПК который в той же сети, что с крейтами (i5), то также будет большой процент потерь (чтобы понять, такие потери только при обмене с крейтом или в канале до той точки где крейт)?

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

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

1. Тест с примером LCard.
Примеры LCard получают только измерительные данные.
Вопрос о временных метках опускается, хотя это важнейший вопрос при разработке систем непрерывного мониторинга объектов.
По этой причине мы немного доработали аналог тестового приложения LCard по мотивам примеров для LTR114 и LTR212.
Тестовое приложение создает один поток сбора измерительных данных с модуля LTR114.
Используем 6 каналов, как в одном из модулей основной программы.
Частота оцифровки каждого канала 100Гц, как в основной программе.
Текст теста прилагаем к ответу.
Добавили для каждого 2-сек блока (по 200 значений на канал) выдачу времени после получения блока с точностью до мс по часам компьютера.
Тестовое приложение назвали ltr114.
Откомпилировано в Qt под Ubuntu24.04.

2. Результаты теста.
При подключении через сложную сеть.
Тестовая программа по мотивам примеров LCard работает и работает, так как не контролирует длительность интервала между приемами порций данных.
Среднее значение интервала между примами порций данных составляет 2сек.
Но разброс очень большой. Это для нас критично с учетом того, что в нашей системе несколько крейтов, содержащих по несколько модулей. При этом требуется обеспечить предоставление синхронных данных в реальном времени .
ВОПРОС: Как снизить разброс ?

3. Прилагаются:
- Тестовое приложение «ltr114» с исходниками (1893-ltr114.7z).
- файл, содержащий лог программы (251112-1893-ltr114.txt.7z).
По разностям времени получения соседних порций данных определяли интервал получения данных.
- График интервалов (ltr114-dt.GIF).

Приведенная картина с задержками объясняется как раз одиночными потерями пакетов при передаче. Исходя из слова "практически" в вашем сообщении я так понимаю полностью потери не исчезли, просто их процент стал значительно меньше по сравнению с огромным числом (>5%) до этого.

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

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

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

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