Какая задержка в TCP / UDP?

Question

ПОМОГИТЕ ПОЖАЛУЙСТА! У меня есть приложение, которое требует максимально возможной обработки в реальном времени, и я продолжаю сталкиваться с этой необычной проблемой задержки как с TCP, так и с UDP. Задержка происходит, как по маслу, и она всегда одинакова (чаще всего от 15 до 16 мс). Это происходит при передаче на любую машину (даже локальную) и в любой сети (у нас их две).

Быстрое решение проблемы:

Я всегда использую winsock в C ++, скомпилированный в VS 2008 Pro, но я написал несколько программ для отправки и получения различными способами, используя как TCP, так и UDP. Я всегда использую промежуточную программу (запущенную локально или удаленно), написанную на разных языках (MATLAB, C #, C ++), для пересылки информации из одной программы в другую. Обе программы winsock работают на одной машине, поэтому они отображают временные метки для Tx и Rx с одинаковых часов. Я продолжаю наблюдать появление шаблона, в котором пакет пакетов будет передаваться, и затем перед следующим пакетом будет задержка около 15–16 миллисекунд, несмотря на то, что не запрограммирована никакая задержка. Иногда между каждым пакетом может быть 15–16 мс вместо пакет пакетов. В других случаях (редко) у меня будет другая задержка, например ~ 47 мс. Я всегда, кажется, получаю пакеты обратно в течение миллисекунды после их передачи, хотя с той же самой схемой задержки, показанной между переданными пакетами.

У меня есть подозрение, что winsock или NIC буферизуют пакеты перед каждой передачей, но я не нашел никаких доказательств. У меня есть гигабитное соединение с одной сетью, которая получает различные уровни трафика, но я также испытываю то же самое при запуске промежуточной программы в кластере с частной сетью без трафика (по крайней мере, от пользователей) и 2-гигабитным соединением. Я даже почувствую эту задержку при локальном запуске промежуточной программы с отправляющей и принимающей программами.

Answer 1

Сегодня утром я выяснил проблему, переписывая сервер на Java. Разрешение моих системных часов Windows составляет от 15 до 16 миллисекунд. Это означает, что каждый пакет, который показывает ту же миллисекунду, что и его время передачи, фактически отправляется с разными миллисекундами с интервалом в 16 миллисекунд, но мои временные метки увеличиваются только каждые 15-16 миллисекунд, поэтому они выглядят одинаково.

Я пришел сюда, чтобы ответить на мой вопрос, и увидел ответ о повышении приоритета моей программы. Итак, я запустил все три программы, зашел в диспетчер задач, поднял все три до «реального времени». приоритет (который не был другой процесс) и запустить их. Я получил те же интервалы от 15 до 16 миллисекунд.

Спасибо за ответы.

Answer 2

Всегда используется буферизация, и она зависит от оборудования / драйверов / операционной системы и т. д. Планировщики пакетов также играют большую роль.

Если вы хотите " жесткий режим реального времени " гарантии, вы, вероятно, должны держаться подальше от Windows ...

Answer 3

Вероятно, вы видите задержку планировщика - ваше приложение ожидает, пока другие процессы завершат свой временной интервал и освободят ЦП. Стандартные временные интервалы в многопроцессорных Windows - от 15 мс до 180 мс.

Вы можете попытаться повысить приоритет вашего приложения / темы.

Answer 4

О да, я знаю, что вы имеете в виду. Windows и ее буферы ... попробуйте настроить значения SO_SNDBUF на отправителе и SO_RCVBUF на стороне получателя. Кроме того, проверьте подключенное сетевое оборудование (маршрутизаторы, коммутаторы, медиашлюзы) - устраните как можно больше между компьютерами, чтобы избежать задержки.