Коллеги, здравствуйте!
Имеется устройство на базе DE0-nano SoC, которое высылает Ethernet пакеты. Прием пакетов производит рабочий ПК, на котором крутится ПО обработки. Во время отладки ПО были выявлены большие потери, которые устранили путем подъема перезапросов (TCP/IP).
Для отладки железа хватало приема по UDP (потерь не было) на несильный тестировочный ПК (соединение точка - точка, поэтому адреса у обоих ПК одинаковые).
Сейчас назрела необходимость проверки правильности работы ПО, что требует наличия "сырых" входных данных. Однако по ряду причин эти данные получить не удается (то мешали, то забыли, то запись не рабочий режим и т.д. Оставим отговорки на совести работников. Главное уходит время, а также нет уникальных данных для последующей работы).
В общем назрела необходимость в некотором устройстве (готовом или в виде демо-платы), которое позволило бы записывать параллельно данные на два ПК.
Была мысль использовать такую плату (перекачивать данные из одного порта в другой, а параллельность обеспечить выводом на GPIO, с последующим забором той же DE0-nano SoC). Но смущает возможный перезапрос, который по словам программистов восстанавливает до 30% потерь, и его придется делать на этой плате.
Что еще можно использовать в качестве целевого устройства?

То есть Вы хотите сделать TCP-соединение в два мастер-компьютера, чтоб со стороны слейва это выглядело как одно(!) TCP-соединение? Или у Вас просто UDP, без TCP соединения?

Или просто подслушку канала хотите сделать?

Почему просто Wireshark не подходит в качестве подслушки? Установить можно хоть на этом же мастере, хоть на любом другом компьютере в этой же сети.

Странное что-то у вас с потерей пакетов твориться, обычно такого не должо быть. А потери не связаны с OC на PC?
А какие скорости гоняете, какие кабеля, расстояния? DE0-nano SoC ну а посылать на два сокета, два потрта с одним IP?
Или роутить поток во внутренней подсети?

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

Чем не подходит любой свитч с поддержкой мирроринга?

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

Пиковая скорость до 100 М. Оптика от 50 м до 1 км. У входа в ПК медь.

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


Наверное подходит - просто не знал о существовании таковых (может это то что ищу и не надо писать доп ПО)

Ага, я тоже не знал. Похоже то что Вам нужно, судя по картинке
https://www.miarec.com/faq/what-is-port-mirroring

свитч с поддержкой мирроринга вам подходит 100%

----------------
второй вариант - запасной.
вместо TCP для FPGA есть замечательная альтернатива - UDT4.

Спасибо всем неравнодушным!
Теперь есть направление поиска и выбора.

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

Не совсем понял: вам распаралелливание на 2 машины для чего нужно? Для создания дублирующего проверочного канала (1), или для разгрузки TCP/IP соединения, чтобы тем самым уменьшить потери и гарантировать референс-данные (2)?

Я так понял: UDP-кадры теряются из-за программных багов. Вот и пытаются костыли приспособить. Причём почему-то схемотехники.....

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

Ну есть у некоторых чсв и они удовлетворяют его "умничая" в то время, когда другие по-уши в работе

Да нужно создать проверочный канал, по которому будут собраны данные двумя устройствами: нашим тестировочным ПК и рабочим ПК. Собранные (при отсутствии потерь) данные планируется использовать для качественной оценки правильности работы ПО рабочего ПК.

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

То что Вы тут описываете - это организационные проблемы Вашей конторы. И соответственно их и нужно решать в первую очередь.
А попытки сделать что-то, чтобы как-то обойти проблему - это всегда называлось "делать костыли". Когда решают не саму проблему.
Я бы на Вашем месте действовал так:
Если подозрение на кривую работу ПО на компе, то:
Пишете своё приложение, принимающее пакеты. Без всякой обработки, просто для контроля целостности приёма и отсутствия потерь. Контролируете работу встроенного ПО Ваших программистов с помощью этого тестового.
Если подозрение на кривую работу встроенного ПО, то:
Пишете свою прошивку, которая просто генерит поток тестовых данных в нужном формате с заданной скоростью и с помощью неё контролируете работу ПО на компе.
Полученные результаты показываете программистам, получаете их согласие, что баги есть и что они будут решать проблему. Если они не согласны - идёте с результатами тестов к руководству конторы.

Это уже сделано. ПО на тестовом ПК принимает данные без ошибок. Результаты работы - обрабатываются на другом ПК (у алгоритмистов).

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

Есть определенные трудности в реализации.
Для подтверждения делались тесты с формированием тональных сигналов (в аппаратной части). Ими была показана исправная работа узлов сбора данных и их передачи до тестового ПК.
Кроме того, по утверждению самих программистов ими были проведены подобные работы.
Основной режим работы проверяется с живым сигналом, а создание тестовой прошивки, точнее эталонного имитатора - долгая работа не гарантирующая учета всех факторов. (для справки, общий объем набираемых данных более 3 ГБайт).
Были работы, когда наши данные с тестовых режимов прогонялись в рабочем ПК (чтение файла без приема по сети) и якобы все прекрасно работало.
Предложение записать полученные нашим тестовым ПО данные на носитель и их транслировать было отвергнуто.

Они согласны, но им нужно время для отладки и несколько экспериментов.
Только пока они возятся и не дают данные, алгоритмисты не могут дальше развить свои наработки.

Круг замкнётся - руководитель проекта уже не раз приходил по поводу выкрутасов программистов.