[anatole 0]

Перечитав свой первый пост, решил дополнительно уточнить такой момент.

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

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

Также на эту мысль наводит описание регистров чипа RTL8111B_8168B п. 2.8 (см. приложение, п. 2.8).

RTL8111B_8168B_Registers_DataSheet_1.0.pdf

Попутно возникли вопросы.

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

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

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

 

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

писюком и плисиной.

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

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

 

 

[zltigo 0]

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

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

 

[prig 0]

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

 

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

 

 

 

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

тут да, тайматуты в каком-то виде могут/будут присутствовать.

 

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

Так что, честная статистика по фреймам может очень даже пригодиться.

[zltigo 0]

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

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

 

[anatole 0]

Автор, кстати не сказал...

Виноват, забыл, исправляюсь.

Устройство подключено к ПК напрямую.

Сетевые настройки, следующие:

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

Изменено 18 марта, 2016 пользователем kanat

[prig 0]

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

...

 

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

Скорее всего, драйвер конкретного железа на компе кривоват, или само железо, или вообще не тот драйвер стоит. Т.е., скорее это проблемы 2-го уровня.

 

[kolobok0 0]

...если в настройках сетевой карты отключить поддержку Jumbo фреймов, и производить передачу блоками по 4-е сообщения...должны быть как можно большего размера.

 

а с чего Вы взяли, что вкл/откл настроек на приёме сказывается на возможность приёма больших пакетов?

чисто из опыта высылал с девайса максимально возможные пакеты(65535 октетов) - по сети, если через роутер идёт, то разрезание на размер мту.

Если напрямую соединять девайс с писюком, то пакеты режутся уже на приёме карточкой. Никаких доп. настроек сетевых дел не делал. Если комп скоростреьный - проблем с освобождением

буферов на приёме(уровень драйвера) не должно быть в принципе(хоть по 100 байт заправляй в ожидание). Со стороны мк кстати похожая екибана.

 

 

(круглый)

Изменено 18 марта, 2016 пользователем kolobok0

[zltigo 0]

Ну, разве что на стыке со 2-м уровнем (если 3-й и 4-й объединить). На стандартные стеки TCP/IP грешить трудно.

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

 

[anatole 0]

Так что, честная статистика по фреймам может очень даже пригодиться.

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

 

а с чего Вы взяли, что вкл/откл настроек на приёме сказывается на возможность приёма больших пакетов?

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

Изменено 18 марта, 2016 пользователем kanat

[prig 0]

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

 

Вы что подразумеваете под транспортным уровнем?

Вообще-то, транспортный уровень - это 4-й уровень, т.е, собственно UDP он и есть. Прямо-таки скажем, что транспорт незамысловатый.

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

Если пакеты UDP в конце концов доходят до адресата, то и с транспортным, и с физическим уровнем всё д.б. в порядке.

 

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

Скорее всего, канальный уровень просто в какой-то момент не передаёт фрейм на сетевой, а следующий фрейм его "проталкивает".

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

 

 

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

...

 

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

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

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