Уважаемые форумчане, требуется помощь.
Суть проблемы - теряются UDP пакеты в режиме RGMII. Была связка ПК->marvell 88e1111->борда с arriaII->marvell 88e1111->ПК и, соответственно, гонялись пакеты по обратной связи. Из миллиона отправленных пакетов принимались все без ошибок.
Сделали собственную плату с точно таким же контроллером - из миллиона пакетов стабильно теряются пару сотен, при этом MAC в fpga говорит о том, что все пакеты приняты и отправлены, т.е. потеря происходит где-то между выходом fpga->marvell->ПК. Все временные ограничения на fpga описаны в соответствии с документацией, более того - разводка на выходе фиксировалась и двигалась по фазе опорная частота с мелким шагом в пределах рабочего окна - в результате система либо не работала вообще, либо все те же доли процентов потери пакетов. Разработчик ПП проверил разброс длин сигнальных линий - все в пределах 20ps.
Куда двигаться дальше, ну помимо того, чтобы тыкаться осциллографом в сигналы RGMII?

Смотреть счетчики на PHY.

Что за счетчики и где они - в 88E1111? Я просто сам не совсем в теме, поэтому заранее извиняюсь за глупые вопросы.

Для начала сделать простой опыт: передать с ПК на ПК без всяких своих плат. Можете быть очень удивлены, если раньше такого не делали.
Нажмите для просмотра прикрепленного файла Нажмите для просмотра прикрепленного файла

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

Как много раз я слышал эту песню

Если найдете ответ, сообщите пожалуйста. Мне это крайне интересно, т.к есть такая же проблема.
Пока решение есть только одно - ставить самое быстрое железо для ПК какое есть сейчас.


Ну так это элементарно. Замыкаете шины mac ядра в плисе, (loopback на уровне mac), в дырку эзернета подтыкаете BER тестер для медного эзернета и тестируете.

Там вообще можно пустить loopback через сам 88e1111, в обход fpga, только я пока не понял как. Что, кстати, на тестере можно увидеть?

Добрый день! Проверьте, не изменилась ли программная часть на ПК. У нас в свое время была проблема, связанная с потерей пакетов. Запускался Касперский, и он отнимал процессорное время - терялись пакеты. Отключили Касперского проблема решилась

Приветствую!


Потеря пакетов при точка-точка может быть как по "электрическим" причинам (помехи на кабель тут уж ничего не сделать) так из за того что приемный буфер в сетевой карте переполнен и не может принят очередной пакет. С этим можно бороться используя loss-less режим работы сетевой карты и соответственно поддерживая flow-control со стороны MAC в FPGA.

Удачи! Rob.

Там нужно битик в регистре поставить. Ищите в доках какой.
Но это не нужно делать, т.к вы проверите работу phy, а mac нет.

На тестере можно увидеть статистику (кол пакетов туды и взад). Смоделировать разные типы нагрузки (burst к примеру), поиграться с объемом трафика, длинной пакетов и т.п. Я гонял по 6-8 часов тесты с нашей железкой - все успешно.

Насчет антивирусов и прочего, да может быть и такое, но далеко не всегда. Тут ключевая фраза - если нагрузка на превышает 20% общей, или 50% на поток, то пакеты теряются.
Картинки выше сняты на винде №7, установленной с офф. диска + драйвера от intel для сетевушки. Винда устанавливалась специально для тестов, к интернету/сети доступа не имела, на тестируемом интерфейсе отключено все, кроме IPv4.

На тестере можно увидеть например количество битовых ошибок, определить правильно ли подсчитана контрольная сумма, возможно в преамбуле проблемы (это тоже может тестер показать), по крайней мере он может показать, что проблема точно не в FPGA или наоборот. ОС на ПК может не пропускать например пакеты с неправильной CRC (или даже сетевая карта на ПК может такое делать). Ну и тайминги на FPGA, должны обязательно выполняться) У меня была такая же схема ПК->ПЛИС->ПК, только не RGMII, а MII, тоже пакеты терялись, проблемы решить не удалось, забросил, с RGMII проще мне кажется.

Элементарно. Проверяете на 10-ке, если там все без потерь, тогда меняете кварц или генератор на правильный. Если тактирование с чипа с PLL, тогда смотрите джиттер, меняете коэффициэнты деления чтобы джиттер вписался в стандарт 100-ки. Как бы и все.

Если важно не потерять ни одного пакета, нужно проверить вашу систему связи на более низком аппаратном уровне. Для этого используются измерители BER. Например http://metrotek.spb.ru/en/b3et.html

У меня было такое, что терялись пакеты по неизвестной причине, правда на 10G. Решение оказалось до безобразия простым - перезагрузить Windows. Через некоторое время после перезагрузки компьютера пакеты вновь начинали теряться.

IP/UDP сами реализовывали? Данные те же самые, что и на "безглючном" железе гоняли? MAC/IP/порты и проч. такие же? А то мало ли? Сами, помню, сталкивались с тем, что некоторые пакеты теряются. Оказалось, тупо проглядели один нюанс в расчёте CRC.

Поясните что значит loss-less, а то есть сомнения что правильно понимаю этот термин контексте сетевой карты
Flow-control уже пишем...

Приветствую!

Подразумевается что сетевая карта совместно с ее товаркой (по точка-точка линку!) поддерживают flow_control
В этом случае приемный MAC если видит что место в буфере приема скоро_кончится/совсем_не_осталось посылает специальный контрольный пакет на удаленный MAC и тот ТОРМОЗИТ передачу на какое-то время. Соответственно не посланный пакет НЕ ТЕРЯЕТСЯ а передается чуть позже.
Естественно этот механизм не защищает от потерь по "электрическим" причинам. Если нужен 146% гарантированная доставка пакетов то тут без соответствующего протокола верхнего уровня НЕ обойтись.

Успехов! Rob.

Проблема решилась заменой кварца 25МГц, тактирующего marvell (со слов разработчика ПП был очень большой джиттер по непонятной причине).