ethernet, RGMII, потеря пакетов Опции

[bogaev_roman]

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

[Ant_m]

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

[bogaev_roman]

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

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

[Ant_m]

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

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

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

Тут ведь вопрос в чем - во всей этой тестовой системе отличие одно - ПП другая стоит (ПК, кабеля и прочее одинаковое)

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

[RobFPGA]

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

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

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

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

Удачи! Rob.

[Ant_m]

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

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

[RobFPGA]

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

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

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

Успехов! Rob.