Перейти к содержанию

    

recvfrom() тормозит при получении UDP пакета

Реализуя связь комп-контроллер через UDP столкнулся с одной странностью. Обмен сделан просто,  по принципу мастер-слейв: комп посылает  пакет с командой/запросом, получив который контроллер отправляет ответный пакет. От компа к контроллеру пакет доставляется  за вполне разумное время, меньше 100мкс. А вот  с момента передачи пакета контроллером до момента, когда функция recvfrom()   возвращает полученные данные проходит порядка 1мс. Это нормально, не слишком ли много для 100Мбит? Почти на порядок больше, чем время передачи 1.4к  пакета.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
3 hours ago, b-volkov said:

Реализуя связь комп-контроллер через UDP ...на порядок больше, чем время передачи 1.4к  пакета.

У Вас тактовая камня сколько? Если предположить, что большинство МК это сотни мГц, а писюк - единицы гигагерц...то вот Вам и есть этот порядок просадки.

Если Вы пихаете в передатчик изернета не в рукопашную, а полуавтоматом - то расходы на подготовку пакетов минимальна(по секрету - вы можете отправлять с железки и по максимуму 65к :) на IP уровне. правда это немного не по фэншую но явных ограничений в RFC не было вроде как.) 

 

(круглый)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Тактовая 200. Только вот тормозит  не МК, а комп (точнее - винда), со своими гигагерцами. Задержка была измерена осциллографом от момента передачи пакета контроллером  ( сигнал TX на RMII) до момента выхода из recvfrom() (ногодрыг на LPT)

 Конечно, можно увеличить длину пакета, но мне важнее не больше, а чаще :). Суть вопроса в другом: 1 мс - это нормальное "время реакции" винды на получение пакета, или я чего не так делаю? Если так оно и должно быть, то придется искать альтернативу ethernet, например возвращаться на старый добрый RS-422

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
2 hours ago, b-volkov said:

ногодрыг на LPT

А есть уверенность, что "ногодрыг на LPT" является адекватным средством измерения? Что, например, Wireshark говорит про тайминги?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
11 hours ago, b-volkov said:

.. тормозит  не МК, а комп (точнее - винда)....

Нет не нормально.
1) Как тут прозвучало - объективные средства контроля (ваершак в данном случае, будет более правильным средством)

2) Смотреть программку по обслуживанию UDP. Профилировать код, если своё или сваливать временные поинты в лог.

3) Что говорит пинг на этот комп? Используется ли асинхронный доступ к сокету? Наверное (если свой код) имеет смысл сделать минимум-миниморэ балванку и выложить на профильных форумах.

 

как то так, для начала...

(круглый)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
20 hours ago, aaarrr said:

А есть уверенность, что "ногодрыг на LPT" является адекватным средством измерения? Что, например, Wireshark говорит про тайминги?

Вначале я увидел задержку между переданным и принятым пакетом именно в Wireshark , а потом уже стал разбираться, на каком этапе она происходит. 

Собственная задержка ногодрыга на LPT ~1мкс (т.е., если запустить в мертвом цикле 0->1, то получается мегагерцовый меандр)

12 hours ago, kolobok0 said:

Нет не нормально.
1) Как тут прозвучало - объективные средства контроля (ваершак в данном случае, будет более правильным средством)

2) Смотреть программку по обслуживанию UDP. Профилировать код, если своё или сваливать временные поинты в лог.

3) Что говорит пинг на этот комп? Используется ли асинхронный доступ к сокету? Наверное (если свой код) имеет смысл сделать минимум-миниморэ балванку и выложить на профильных форумах.

 

 

2) Так обслуживание UDP сводится только к вызову recvfrom().  Это блокирующая функция, пока пакет не получит  - управление не вернет. Сразу после нее дергаю LPT. До ногодрыга профилировал с помощью QueryPerformanceCounter и видел, что recvfrom() выполняется миллисекунду с небольшим. Но что бы понять, где именно задержка, пришлось взять осциллограф.

3) Пинг - примерно та же 1мс. Если под асинхронным сокетом предполагается неблокирующий, то не использую, просто не знаю как

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Выключите в настройках сетевой карты "Interrupt Moderation" для начала.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Измерять времянки на хосте путём ногодрыга LPT всё же не очень хорошая идея (то, что в цикле получилась 1 мкс, не означает, что при одиночных обращениях тоже будет такое время - там куча программно-аппаратной шняги на пути от кода до пина LPT находтися, которая никак не контролируется пользователем). Ведь для этого там есть специальные средства - аппаратные таймеры. В венде к этому доступ через функцию QueryPerformanceCounter(), в линухах есть свои аналоги. Точность измерения времянок событий тут намного выше, чем через ногодрыг LPT. И измерительные приборы не нужны.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты
15 hours ago, Rst7 said:

Выключите в настройках сетевой карты "Interrupt Moderation" для начала.

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для публикации сообщений создайте учётную запись или авторизуйтесь

Вы должны быть пользователем, чтобы оставить комментарий

Создать учетную запись

Зарегистрируйте новую учётную запись в нашем сообществе. Это очень просто!

Регистрация нового пользователя

Войти

Уже есть аккаунт? Войти в систему.

Войти