anatole 0 18 марта, 2016 Опубликовано 18 марта, 2016 · Жалоба Перечитав свой первый пост, решил дополнительно уточнить такой момент. Проблема возникает не постоянно, т. е. не при каждой передаче блока сообщений от устройства в ПК, а носит не периодический характер (или я ещё не выявил периодичности), т. е. устройство может без проблем передавать сообщения в течение нескольких минут, потом в течение одной минуты может быть один-два сбоя, и снова несколько минут беспроблемной передачи. Поэтому у меня и возникло предположение, озвученное в первом посте, что пока объём данных приходящий в ПК имеет некоторую кратность объёму буфера в сетевой карте, то все работает хорошо, а как только не добираем необходимого объёма данных, то возникают проблемы. Также на эту мысль наводит описание регистров чипа RTL8111B_8168B п. 2.8 (см. приложение, п. 2.8). RTL8111B_8168B_Registers_DataSheet_1.0.pdf Попутно возникли вопросы. 1. Можно ли узнать, как стандартный драйвер настроил чип? 2. Можно ли средствами стандартного драйвера перенастроить регистры чипа в сетевой карте на своё усмотрение? ------------------------------------------ необходимо проконтролировать корректность данных между писюком и плисиной. Сами сетевые пакеты, насколько я понимаю, не содержат ошибок, т. к. нет никаких ошибок ни в статистике сниффера, ни в отчете netstat. Аналогично нет ошибок и в самих сообщениях, поскольку, когда сообщение всё-таки доходит до ПО, то анализ сообщения показывает, что с его содержимым всё в порядке. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 18 марта, 2016 Опубликовано 18 марта, 2016 · Жалоба Сами сетевые пакеты, насколько я понимаю, не содержат ошибок... Снифер НЕ видит и не отображает ошибки и проблемы транспортного уровня. Попробуйте таки начать с наблюдения альтернативным снифером, как написал в первом посте. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
prig 0 18 марта, 2016 Опубликовано 18 марта, 2016 · Жалоба Снифер НЕ видит и не отображает ошибки и проблемы транспортного уровня. Попробуйте таки начать с наблюдения альтернативным снифером, как написал в первом посте. Ну, если UDP пакеты не теряются, то и с транспортным уровнем проблем быть не должно. ... Единственно, что на интимном уровне фреймы с данными более 508 байт могут резаться и собираться обратно. тут да, тайматуты в каком-то виде могут/будут присутствовать. А вот нарезку пакетов действительно стоит проверить. Что там насчитал осциллографом ТС - тоже вопрос. Так что, честная статистика по фреймам может очень даже пригодиться. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 18 марта, 2016 Опубликовано 18 марта, 2016 · Жалоба Ну, если UDP пакеты не теряются, то и с транспортным уровнем проблем быть не должно. Отнюдь. Видно, что они приходят целыми но почему-то только после сетевой активности связанной с передачей других пакетов. Автор, кстати не сказал, прямое соединентие или еще и через свичи/роутеры? Как не озвучил и размер пакетов. Кстати, а UDP заголовок честый? В смысле в нем нет broadcast MAC/IP ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
anatole 0 18 марта, 2016 Опубликовано 18 марта, 2016 (изменено) · Жалоба Автор, кстати не сказал... Виноват, забыл, исправляюсь. Устройство подключено к ПК напрямую. Сетевые настройки, следующие: 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 18 марта, 2016 Опубликовано 18 марта, 2016 · Жалоба Отнюдь. Видно, что они приходят целыми но почему-то только после сетевой активности связанной с передачей других пакетов. ... Ну, разве что на стыке со 2-м уровнем (если 3-й и 4-й объединить). На стандартные стеки TCP/IP грешить трудно. Разве что, исходники какие-то левые. Скорее всего, драйвер конкретного железа на компе кривоват, или само железо, или вообще не тот драйвер стоит. Т.е., скорее это проблемы 2-го уровня. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kolobok0 0 18 марта, 2016 Опубликовано 18 марта, 2016 (изменено) · Жалоба ...если в настройках сетевой карты отключить поддержку Jumbo фреймов, и производить передачу блоками по 4-е сообщения...должны быть как можно большего размера. а с чего Вы взяли, что вкл/откл настроек на приёме сказывается на возможность приёма больших пакетов? чисто из опыта высылал с девайса максимально возможные пакеты(65535 октетов) - по сети, если через роутер идёт, то разрезание на размер мту. Если напрямую соединять девайс с писюком, то пакеты режутся уже на приёме карточкой. Никаких доп. настроек сетевых дел не делал. Если комп скоростреьный - проблем с освобождением буферов на приёме(уровень драйвера) не должно быть в принципе(хоть по 100 байт заправляй в ожидание). Со стороны мк кстати похожая екибана. (круглый) Изменено 18 марта, 2016 пользователем kolobok0 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 18 марта, 2016 Опубликовано 18 марта, 2016 · Жалоба Ну, разве что на стыке со 2-м уровнем (если 3-й и 4-й объединить). На стандартные стеки TCP/IP грешить трудно. Именно по этой причине и не рассматриваю их в ПЕРВУЮ очередь и говорю о физическом и транспортном уровне. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
anatole 0 18 марта, 2016 Опубликовано 18 марта, 2016 (изменено) · Жалоба Так что, честная статистика по фреймам может очень даже пригодиться.А подскажите, пожалуйста, каким способом можно получить эту статистику в Windows? а с чего Вы взяли, что вкл/откл настроек на приёме сказывается на возможность приёма больших пакетов?Если я выключаю возможность приема Jumbo фреймов в настройках сетевой карты, и потом настраиваю устройство на выдачу сообщений с данными размером фрейма 4146 байтов, то на приеме в ПК, как в сниффере, так и в ПО, я вижу только первое сообщение "Заголовок" (размер фрейма 74 байта) и дальше ничего. Изменено 18 марта, 2016 пользователем kanat Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
prig 0 21 марта, 2016 Опубликовано 21 марта, 2016 · Жалоба Именно по этой причине и не рассматриваю их в ПЕРВУЮ очередь и говорю о физическом и транспортном уровне. Вы что подразумеваете под транспортным уровнем? Вообще-то, транспортный уровень - это 4-й уровень, т.е, собственно UDP он и есть. Прямо-таки скажем, что транспорт незамысловатый. Как я уже говорил, проблемы на уровне стека весьма сомнительны, особливо для UDP. Если пакеты UDP в конце концов доходят до адресата, то и с транспортным, и с физическим уровнем всё д.б. в порядке. Так как пакеты или фреймы где-то зависают, затык наиболее вероятен между канальным и сетевым уровнем. Скорее всего, канальный уровень просто в какой-то момент не передаёт фрейм на сетевой, а следующий фрейм его "проталкивает". Как вариант, проблема может быть как-то связана с фрагментированием пакета (чуть ли не первое, что на ум приходит). А подскажите, пожалуйста, каким способом можно получить эту статистику в Windows? ... Ну, при необходимости я трясу статистику из программеров. В детали не погружаюсь. Достукиваться надо до счётчиков MAC. Наверное, реализуется через какой-нибудь API. М.б. и готовые утилиты под Виндами имеются. Как вариант, подключить всё через подходящий свитч, у которого имеются готовые возможности посмотреть статистику по портам. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться