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

Попутно возникли вопросы.
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 фреймов не годится, т. к. в другом исполнение устройства, передаваемые сообщения с данными должны быть как можно большего размера.

Сообщение отредактировал kanat - Mar 18 2016, 11:01

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

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


(круглый)

Сообщение отредактировал kolobok0 - Mar 18 2016, 16:28

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

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

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

Сообщение отредактировал kanat - Mar 18 2016, 20:21

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

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




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