[bogaev_roman 0]

Уважаемые форумчане, требуется помощь.

Суть проблемы - теряются UDP пакеты в режиме RGMII. Была связка ПК->marvell 88e1111->борда с arriaII->marvell 88e1111->ПК и, соответственно, гонялись пакеты по обратной связи. Из миллиона отправленных пакетов принимались все без ошибок.

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

Куда двигаться дальше, ну помимо того, чтобы тыкаться осциллографом в сигналы RGMII?

[DimaG 0]

Куда двигаться дальше, ну помимо того, чтобы тыкаться осциллографом в сигналы RGMII?

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

[bogaev_roman 0]

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

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

[Ant_m 0]

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

[bogaev_roman 0]

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

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

[Ant_m 0]

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

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

 

Если найдете ответ, сообщите пожалуйста. Мне это крайне интересно, т.к есть такая же проблема.

Пока решение есть только одно - ставить самое быстрое железо для ПК какое есть сейчас.

 

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

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

[bogaev_roman 0]

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

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

[gin 0]

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

[RobFPGA 27]

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

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

 

Если найдете ответ, сообщите пожалуйста. Мне это крайне интересно, т.к есть такая же проблема.

Пока решение есть только одно - ставить самое быстрое железо для ПК какое есть сейчас.

...

 

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

 

Удачи! Rob.

 

 

[Ant_m 0]

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

Там нужно битик в регистре поставить. Ищите в доках какой.

Но это не нужно делать, т.к вы проверите работу phy, а mac нет.

 

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

 

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

отнимал процессорное время

- если нагрузка на превышает 20% общей, или 50% на поток, то пакеты теряются.

Картинки выше сняты на винде №7, установленной с офф. диска + драйвера от intel для сетевушки. Винда устанавливалась специально для тестов, к интернету/сети доступа не имела, на тестируемом интерфейсе отключено все, кроме IPv4.

[EgorT 0]

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

 

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

 

[Aner 3]

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

[aabmail 0]

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

 

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

[FakeDevice 0]

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

[Ant_m 0]

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

Поясните что значит loss-less, а то есть сомнения что правильно понимаю этот термин контексте сетевой карты :)

Flow-control уже пишем...