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

Дано.
Есть система, в которой устройство подключено к ПК по сети 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. В этой системе сам я отвечаю за устройство, и с программной частью на ПК в плане работы с сетью не знаком. На вопросы связанные с ПО, смогу ответить после консультации с нашим программистом.

В роутере настраивается маршрутизация на еще один порт. К нему подключается еще один компьютер с тем-же снифером для НЕЗАВИСИМОГО контроля. Ну а дальше - либо он видит эти фреймы, либо нет.

1) не в сетевой карте а в софте
2) не буффер а тайм-аут
3) не на ПК, а на обеих концах в сетевых стэках
4) данный тайм-аут надо скинуть в ноль.(что то туплю, заклинило - с ходу название не вспомнил...лезть в склады кода лень, простите)

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

Таки лучше залезте, ибо таймаутов в UDP/IP стеке просто нет по причине их нахреннненужности.

да, пакетная передача. накопления нет. согласен. поспешил похоже.

значит остаётся начать с самого простого - откуда идёт замер интервала.

Уточню последовательность пакетов во времени.
Последовательность пакетов на ПК в сниффере:
[(1) передан один пакет] – [(2) принято ЧЕТЫРЕ пакета] – [(3) таймаут 1 с] – [(4) передан один пакет] – [(5) принято ДВА пакета].
Последовательность пакетов в устройстве:
[(1) принят один пакет] – [(2) передано ПЯТЬ пакетов] – [(3) пауза 1 с] – [(4) принят один пакет] – [(5) передан ОДИН пакет].

Причем если в ПО отключить таймаут на прием сообщений, т. е. ждать сообщения бесконечно долго, то недошедший пакет рано или поздно появится в сниффере при какой-нибудь активности по сети со стороны ПК, например, при отправке пакета по протоколу Browser Protocol (раз в 11 мин), который в устройстве отбрасывается на стороне МАС-контроллера, или при ping-е IP-адреса отличного от адреса устройства.

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

О каком интервале идет речь?

Тоже ни о каком.

Если судить по описанию проблемы (см. на упражнения с осциллографом и последующий приём пропавшего фрейма после запроса повторной передачи), фреймы таки нормально долетают.
Скорее всего, в софте где-то ловко накосячено или стандартные "дрова" не совсем стандартно работают.

об этом:

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

если прочитать первое сообщение TC


то станет понятно о чём речь.

Ваша фраза

это флуд чистой воды. Причём тут UDP если идёт речь о логике работы программы TC?

Настоятельно рекомендую Вам перечитать написаное Автором и ОБА своих ответа про таймауты, а не бросатся словами "флуд".

То, что я говорил про настройки - я уже написал выше, читайте пост номер 5.

Вы не ответили на конкретно поставленный вопрос (см. пост номер 11).
Ответ будет или вы уйдёте от ответа?

Читаем Автора:

Что Вам, простите, в написанном Автром про таймаут непонятно, что Вы решили посоветовать автору следующее:

А мне заявить:

Можете не отвечать, поверьте, так будет лучше.

Вы пишете следующее:

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

пакет доходит, но с существенной задержкой. Т.е. мест где бы он "хранился" - всего три. мк, плисина, карточка писюка.
если предположить, что данные между мк и плисиной корректны, то вам необходимо проконтролировать корректность данных между
писюком и плисиной. Отсюда Вы поймёте в какую сторону копать.

(круглый)

Перечитав свой первый пост, решил дополнительно уточнить такой момент.
Проблема возникает не постоянно, т. е. не при каждой передаче блока сообщений от устройства в ПК, а носит не периодический характер (или я ещё не выявил периодичности), т. е. устройство может без проблем передавать сообщения в течение нескольких минут, потом в течение одной минуты может быть один-два сбоя, и снова несколько минут беспроблемной передачи.
Поэтому у меня и возникло предположение, озвученное в первом посте, что пока объём данных приходящий в ПК имеет некоторую кратность объёму буфера в сетевой карте, то все работает хорошо, а как только не добираем необходимого объёма данных, то возникают проблемы.
Также на эту мысль наводит описание регистров чипа RTL8111B_8168B п. 2.8 (см. приложение, п. 2.8).
Нажмите для просмотра прикрепленного файла
Попутно возникли вопросы.
1. Можно ли узнать, как стандартный драйвер настроил чип?
2. Можно ли средствами стандартного драйвера перенастроить регистры чипа в сетевой карте на своё усмотрение?
------------------------------------------

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

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

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





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

Отнюдь. Видно, что они приходят целыми но почему-то только после сетевой активности связанной с передачей других пакетов. Автор, кстати не сказал, прямое соединентие или еще и через свичи/роутеры? Как не озвучил и размер пакетов. Кстати, а UDP заголовок честый? В смысле в нем нет broadcast MAC/IP ?

Виноват, забыл, исправляюсь.
Устройство подключено к ПК напрямую.
Сетевые настройки, следующие:

• MAC-адрес устройства: 0x001122334455
• IP-адрес устройства: 192.168.100.250
• Порт устройства: 3080
• IP-адрес ПК: 192.168.100.134
• Порт ПК: 3080

В настройках сетевой карты включен режим приема Jumbo фреймов размером 4 КБ MTU (максимальный размер для данной сетевой карты).

Размеры пакетов указывал в первом посте, напомню:

• команды от ПК: размер фрейма не меньше 60 байт, полезные байты UDP >= 18
• сообщение от устройства «Заголовок»: размер фрейма 74 байта, полезные байты UDP = 32
• сообщение от устройства «Данные»: размер фрейма 1074 байтов, полезные байты UDP = 1032

Размер сообщения «Данные» в устройстве можно настраивать, так вот, если изменять этот размер и выдавать данные не 4-мя сообщениями, а, например, одним (размер фрейма 4146 байтов, полезные байты UDP = 4104), то ситуация изменяется и проблемный прием в ПК возникает намного реже.
А если в настройках сетевой карты отключить поддержку Jumbo фреймов, и производить передачу блоками по 4-е сообщения «Данные» (размер фрейма 1074 байтов, полезные байты UDP = 1032), то проблема с приемом вообще никогда не возникает. Но отключение Jumbo фреймов не годится, т. к. в другом исполнение устройства, передаваемые сообщения с данными должны быть как можно большего размера.

Ну, разве что на стыке со 2-м уровнем (если 3-й и 4-й объединить). На стандартные стеки TCP/IP грешить трудно. Разве что, исходники какие-то левые.
Скорее всего, драйвер конкретного железа на компе кривоват, или само железо, или вообще не тот драйвер стоит. Т.е., скорее это проблемы 2-го уровня.

а с чего Вы взяли, что вкл/откл настроек на приёме сказывается на возможность приёма больших пакетов?
чисто из опыта высылал с девайса максимально возможные пакеты(65535 октетов) - по сети, если через роутер идёт, то разрезание на размер мту.
Если напрямую соединять девайс с писюком, то пакеты режутся уже на приёме карточкой. Никаких доп. настроек сетевых дел не делал. Если комп скоростреьный - проблем с освобождением
буферов на приёме(уровень драйвера) не должно быть в принципе(хоть по 100 байт заправляй в ожидание). Со стороны мк кстати похожая екибана.


(круглый)

Именно по этой причине и не рассматриваю их в ПЕРВУЮ очередь и говорю о физическом и транспортном уровне.

А подскажите, пожалуйста, каким способом можно получить эту статистику в Windows?

Если я выключаю возможность приема Jumbo фреймов в настройках сетевой карты, и потом настраиваю устройство на выдачу сообщений с данными размером фрейма 4146 байтов, то на приеме в ПК, как в сниффере, так и в ПО, я вижу только первое сообщение "Заголовок" (размер фрейма 74 байта) и дальше ничего.

Вы что подразумеваете под транспортным уровнем?
Вообще-то, транспортный уровень - это 4-й уровень, т.е, собственно UDP он и есть. Прямо-таки скажем, что транспорт незамысловатый.
Как я уже говорил, проблемы на уровне стека весьма сомнительны, особливо для UDP.
Если пакеты UDP в конце концов доходят до адресата, то и с транспортным, и с физическим уровнем всё д.б. в порядке.

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




Ну, при необходимости я трясу статистику из программеров. В детали не погружаюсь.
Достукиваться надо до счётчиков MAC. Наверное, реализуется через какой-нибудь API. М.б. и готовые утилиты под Виндами имеются.
Как вариант, подключить всё через подходящий свитч, у которого имеются готовые возможности посмотреть статистику по портам.