Jump to content

    

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

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

Share this post


Link to post
Share on other sites
3 hours ago, b-volkov said:

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

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

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

 

(круглый)

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites
2 hours ago, b-volkov said:

ногодрыг на LPT

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

Share this post


Link to post
Share on other sites
11 hours ago, b-volkov said:

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

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

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

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

 

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

(круглый)

Share this post


Link to post
Share on other sites
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мс. Если под асинхронным сокетом предполагается неблокирующий, то не использую, просто не знаю как

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
15 hours ago, Rst7 said:

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

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

 

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now