b-volkov 0 28 января, 2019 Опубликовано 28 января, 2019 · Жалоба Реализуя связь комп-контроллер через UDP столкнулся с одной странностью. Обмен сделан просто, по принципу мастер-слейв: комп посылает пакет с командой/запросом, получив который контроллер отправляет ответный пакет. От компа к контроллеру пакет доставляется за вполне разумное время, меньше 100мкс. А вот с момента передачи пакета контроллером до момента, когда функция recvfrom() возвращает полученные данные проходит порядка 1мс. Это нормально, не слишком ли много для 100Мбит? Почти на порядок больше, чем время передачи 1.4к пакета. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kolobok0 0 28 января, 2019 Опубликовано 28 января, 2019 · Жалоба 3 hours ago, b-volkov said: Реализуя связь комп-контроллер через UDP ...на порядок больше, чем время передачи 1.4к пакета. У Вас тактовая камня сколько? Если предположить, что большинство МК это сотни мГц, а писюк - единицы гигагерц...то вот Вам и есть этот порядок просадки. Если Вы пихаете в передатчик изернета не в рукопашную, а полуавтоматом - то расходы на подготовку пакетов минимальна(по секрету - вы можете отправлять с железки и по максимуму 65к :) на IP уровне. правда это немного не по фэншую но явных ограничений в RFC не было вроде как.) (круглый) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
b-volkov 0 29 января, 2019 Опубликовано 29 января, 2019 · Жалоба Тактовая 200. Только вот тормозит не МК, а комп (точнее - винда), со своими гигагерцами. Задержка была измерена осциллографом от момента передачи пакета контроллером ( сигнал TX на RMII) до момента выхода из recvfrom() (ногодрыг на LPT) Конечно, можно увеличить длину пакета, но мне важнее не больше, а чаще :). Суть вопроса в другом: 1 мс - это нормальное "время реакции" винды на получение пакета, или я чего не так делаю? Если так оно и должно быть, то придется искать альтернативу ethernet, например возвращаться на старый добрый RS-422 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
aaarrr 69 29 января, 2019 Опубликовано 29 января, 2019 · Жалоба 2 hours ago, b-volkov said: ногодрыг на LPT А есть уверенность, что "ногодрыг на LPT" является адекватным средством измерения? Что, например, Wireshark говорит про тайминги? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
kolobok0 0 29 января, 2019 Опубликовано 29 января, 2019 · Жалоба 11 hours ago, b-volkov said: .. тормозит не МК, а комп (точнее - винда).... Нет не нормально. 1) Как тут прозвучало - объективные средства контроля (ваершак в данном случае, будет более правильным средством) 2) Смотреть программку по обслуживанию UDP. Профилировать код, если своё или сваливать временные поинты в лог. 3) Что говорит пинг на этот комп? Используется ли асинхронный доступ к сокету? Наверное (если свой код) имеет смысл сделать минимум-миниморэ балванку и выложить на профильных форумах. как то так, для начала... (круглый) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
b-volkov 0 30 января, 2019 Опубликовано 30 января, 2019 · Жалоба 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мс. Если под асинхронным сокетом предполагается неблокирующий, то не использую, просто не знаю как Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 30 января, 2019 Опубликовано 30 января, 2019 · Жалоба Выключите в настройках сетевой карты "Interrupt Moderation" для начала. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dxp 65 31 января, 2019 Опубликовано 31 января, 2019 · Жалоба Измерять времянки на хосте путём ногодрыга LPT всё же не очень хорошая идея (то, что в цикле получилась 1 мкс, не означает, что при одиночных обращениях тоже будет такое время - там куча программно-аппаратной шняги на пути от кода до пина LPT находтися, которая никак не контролируется пользователем). Ведь для этого там есть специальные средства - аппаратные таймеры. В венде к этому доступ через функцию QueryPerformanceCounter(), в линухах есть свои аналоги. Точность измерения времянок событий тут намного выше, чем через ногодрыг LPT. И измерительные приборы не нужны. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
b-volkov 0 31 января, 2019 Опубликовано 31 января, 2019 · Жалоба 15 hours ago, Rst7 said: Выключите в настройках сетевой карты "Interrupt Moderation" для начала. Спасибо огромное!!! Время уменьшилось почти на порядок! Не знал о наличии такого режима у сетевух. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
