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

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

Кратко о проблеме:

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

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


person ACE2100    schedule 27.10.2009    source источник
comment
Если вам нужен режим реального времени, рассматривали ли вы возможность использования операционной системы реального времени?   -  person James Jones    schedule 28.10.2009
comment
Решения были приняты еще до того, как я пришел сюда, и у них уже есть кластер стоимостью более 100 000 долларов, работающий под управлением Windows Compute Cluster. Если бы мне пришлось выбирать, я бы отказался от кластера и запустил вычисления на одном четырехпроцессорном компьютере, чтобы не было необходимости в сетевом соединении.   -  person ACE2100    schedule 02.11.2009


Ответы (5)


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

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

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

person ACE2100    schedule 28.10.2009
comment
вы можете использовать метод QueryPerformanceCounter (секундомер в .Net), чтобы получить гораздо большую точность (он реализован аппаратно, а не Windows) - person ; 24.01.2010

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

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

person jldupont    schedule 27.10.2009
comment
Имейте в виду, что для большинства целей задержка в 15 мс останется незамеченной. У меня 40 мс пинг до моего интернет-провайдера, и я не замечаю проблем, даже когда он удваивается. Операционная система, предназначенная для настольного использования, такая как Windows или Mac OSX, не должна беспокоиться о таких небольших задержках. Я полностью согласен с jldupont: если задержка в 15 мс является проблемой, вам действительно нужно найти ОС, предназначенную для использования в жестком реальном времени, поскольку мягкое реальное время вам не подходит. (Мягкое реальное время = все работает достаточно быстро; жесткое реальное время = система гарантирует временные интервалы.) - person David Thornley; 27.10.2009

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

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

person caf    schedule 27.10.2009

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

person Skynet    schedule 28.12.2012

Я встречаю ту же проблему. Но в моем случае я использую GetTickCount() для получения текущего системного времени, к сожалению, оно всегда имеет разрешение 15-16 мс. Когда я использую QueryPerformanceCounter вместо GetTickCount(), все в порядке. На самом деле, TCP-сокет получает данные равномерно, а не 15 мс один раз.

person Yanda Lin    schedule 29.10.2019