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

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

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

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

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

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

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

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

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

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

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

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

[jcxz]

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

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

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

Если подозрение на кривую работу ПО на компе, то:
Пишете своё приложение, принимающее пакеты. Без всякой обработки, просто для контроля целостности приёма и отсутствия потерь.

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

Контролируете работу встроенного ПО Ваших программистов с помощью этого тестового.

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

Пишете свою прошивку, которая просто генерит поток тестовых данных в нужном формате с заданной скоростью и с помощью неё контролируете работу ПО на компе.

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

Если они не согласны...

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

...идёте с результатами тестов к руководству конторы.

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