Можно ли "распараллелить" Ethernet?, Нужно принимать данные на два ПК Опции

[Александр77]

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

[Александр77]

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

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

А проблемы с ЭМС наверное программисты решают?

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

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

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

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

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