Перейти к содержанию
    

Можно ли "распараллелить" Ethernet?

Коллеги, здравствуйте!

Имеется устройство на базе 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 минут не всегда есть возможность.

Проводная акула не устраивает именно потому, что крутится она на рабочем ПК, а тот в свою очередь "слишком" занят прикладным ПО.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

А какие скорости гоняете, какие кабеля, расстояния?

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

DE0-nano SoC ну а посылать на два сокета, два потрта с одним IP?

Тут сложность с программистами - в один ПК загонять и так хватает проблем, а доступа к крутящемуся ПО в арме у нас нет.

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

 

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Ага, я тоже не знал. Похоже то что Вам нужно, судя по картинке :)

https://www.miarec.com/faq/what-is-port-mirroring

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

----------------

второй вариант - запасной.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Спасибо всем неравнодушным!

Теперь есть направление поиска и выбора.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Тут сложность с программистами - в один ПК загонять и так хватает проблем, а доступа к крутящемуся ПО в арме у нас нет.

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Программисты отлаживают свою часть, но для отладки им уже (по их заверению) нужны "натурные" эксперименты. Прогон записанных тестировочных данных для отладки ПО по словам программистов уже проводился и он исправен и по существу им не интересен.

Сами эксперименты нестационарны: мы работаем не в условиях безэховости - в среде присутствуют посторонние составляющие и их вклад случаен.

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

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

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

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

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

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

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

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

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

Вот и получается такая "вещь в себе" от которой хочется избавиться.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Вот и получается такая "вещь в себе" от которой хочется избавиться.

То что Вы тут описываете - это организационные проблемы Вашей конторы. И соответственно их и нужно решать в первую очередь.

А попытки сделать что-то, чтобы как-то обойти проблему - это всегда называлось "делать костыли". Когда решают не саму проблему.

Я бы на Вашем месте действовал так:

Если подозрение на кривую работу ПО на компе, то:

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

Если подозрение на кривую работу встроенного ПО, то:

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

Полученные результаты показываете программистам, получаете их согласие, что баги есть и что они будут решать проблему. Если они не согласны - идёте с результатами тестов к руководству конторы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если подозрение на кривую работу ПО на компе, то:

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

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

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

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

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

Есть определенные трудности в реализации.

Для подтверждения делались тесты с формированием тональных сигналов (в аппаратной части). Ими была показана исправная работа узлов сбора данных и их передачи до тестового ПК.

Кроме того, по утверждению самих программистов ими были проведены подобные работы.

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

Были работы, когда наши данные с тестовых режимов прогонялись в рабочем ПК (чтение файла без приема по сети) и якобы все прекрасно работало.

Предложение записать полученные нашим тестовым ПО данные на носитель и их транслировать было отвергнуто.

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

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

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...