Информация из UDP пакетов не доходит до программного приложения, Gigabit Ethernet, UDP пакеты от устройства на 88E1111 в ПК Опции

[kanat]

Здравствуйте. Помогите решить возникшую проблему.

Дано.
Есть система, в которой устройство подключено к ПК по сети Gigabit Ethernet с обменом информацией по протоколу UDP.
Схема соединения узлов системы имеет вид: устройство[МК <=> MAC-контроллер (самописный контроллер на ПЛИС Cyclone III) <=> МС физического уровня (Marvell 88E1111)] <=> ПО на ПК (встроенная сетевая карта Realtek PCIe GBE RTL8168B/8111B, ОС Windows XP).
Упрощенно алгоритм обмена информацией содержит следующие шаги:

• Шаг 1. ПО настраивает устройство некоторым количеством команд.
• Шаг 2. Далее ПО посылает команду «Запрос данных».
• Шаг 3. После получения команды «Запрос данных» МК выдает блок сообщений: сообщение «Заголовок» (UDP пакет с размером полезных данных 32 байта) и следом 4-е сообщения «Данные[1] – [4]» (UDP пакеты с размером полезных данных 1032 байта). Интервалы времени между сообщениями от МК около 10 мкс.
• Шаг 4. ПО на ПК анализирует принятые сообщения и выдает либо команду «Правильный приём», либо «Повторить сообщение №N».
  Также на этом шаге ПО следит за таймером, и если в течение одной секунды не набран полный блок сообщений, то происходит принудительная подача команды «Повторить сообщение №N».
• Шаг 5. Затем ПО посылает снова команду «Запрос данных» и т. д. шаги 2 – 4 по кругу. Интервалы времени между командами «Запрос данных» при правильном приеме сообщений около 1,5 мс.

Проблема.
Имеет место ситуация, когда до ПО на ПК не доходит последнее сообщение (причем всегда именно последнее) от устройства, т. е. сообщение «Данные[4]», что приводит к срабатыванию таймаута на прием блока сообщений и к подаче от ПК команды «Повторить сообщение №N».
В этой ситуации, недошедшее сообщение также не видно и в сниффере (Wireshark), хотя по осциллографу на цепи TxCtl, между ПЛИС и МС физического уровня, наблюдается верная временная диаграмма, состоящая из 5-и передач в сеть. Более того, после команды «Повторить сообщение №N», на цепи TxCtl наблюдается только один импульс соответствующий передаче одного пакета в сеть, а в ПО доходит и «старый» недошедший пакет и «новый» переспрошенный пакет. В сниффере же наблюдаем следующую картину:

• 1. пакет в ПК: сообщение «Данные[3]» (последний правильно пришедший пакет)
• 2. пакет из ПК: команда «Повторить сообщение №4» (пакет из ПК по таймауту через 1 с после последнего пакета)
• 3. пакет в ПК: сообщение «Данные[4]» (недошедший до ПО и сниффера пакет, из-за которого была подана команда «Повторить сообщение»)
• 4. пакет в ПК: сообщение «Данные[4]» (сообщение, которое было выдано устройством в ответ на команду «Повторить сообщение»).

Т. е. получаем ситуацию, когда из устройства сетевые пакеты уходят, а до ПО и сниффера в ПК не доходят.

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

Вопрос.
Что посоветуете в данной ситуации? Причем менять сетевую карту, ОС или стандартный сетевой драйвер очень не желательно.

Заранее спасибо за любую помощь.

P.S. В этой системе сам я отвечаю за устройство, и с программной частью на ПК в плане работы с сетью не знаком. На вопросы связанные с ПО, смогу ответить после консультации с нашим программистом.

[kanat]

Перечитав свой первый пост, решил дополнительно уточнить такой момент.
Проблема возникает не постоянно, т. е. не при каждой передаче блока сообщений от устройства в ПК, а носит не периодический характер (или я ещё не выявил периодичности), т. е. устройство может без проблем передавать сообщения в течение нескольких минут, потом в течение одной минуты может быть один-два сбоя, и снова несколько минут беспроблемной передачи.
Поэтому у меня и возникло предположение, озвученное в первом посте, что пока объём данных приходящий в ПК имеет некоторую кратность объёму буфера в сетевой карте, то все работает хорошо, а как только не добираем необходимого объёма данных, то возникают проблемы.
Также на эту мысль наводит описание регистров чипа RTL8111B_8168B п. 2.8 (см. приложение, п. 2.8).
 RTL8111B_8168B_Registers_DataSheet_1.0.pdf ( 633.74 килобайт ) Кол-во скачиваний: 2412

Попутно возникли вопросы.
1. Можно ли узнать, как стандартный драйвер настроил чип?
2. Можно ли средствами стандартного драйвера перенастроить регистры чипа в сетевой карте на своё усмотрение?
------------------------------------------

необходимо проконтролировать корректность данных между
писюком и плисиной.

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

[zltigo]

Сами сетевые пакеты, насколько я понимаю, не содержат ошибок...

Снифер НЕ видит и не отображает ошибки и проблемы транспортного уровня. Попробуйте таки начать с наблюдения альтернативным снифером, как написал в первом посте.

[prig]

Снифер НЕ видит и не отображает ошибки и проблемы транспортного уровня. Попробуйте таки начать с наблюдения альтернативным снифером, как написал в первом посте.

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

... Единственно, что на интимном уровне фреймы с данными более 508 байт могут резаться и собираться обратно.
тут да, тайматуты в каком-то виде могут/будут присутствовать.

А вот нарезку пакетов действительно стоит проверить. Что там насчитал осциллографом ТС - тоже вопрос.
Так что, честная статистика по фреймам может очень даже пригодиться.