Переменная задержка в сети Windows

Question

У меня есть ПЛК, который отправляет UDP-пакеты каждые 24 мс. «Одновременно» (т. Е. В пределах того, что должно быть несколько десятков или не более сотен микросекунд), тот же ПЛК запускает камеру для привязки изображения. Существует система Windows 8.1, которая получает как изображения, так и UDP-пакеты, и приложение, работающее на нем, которое должно соответствовать каждому изображению с UDP-пакетом из ПЛК.

В большинстве случаев существует достаточно фиксированная латентность между двумя событиями, что касается приложения Windows - 20 мс +/- 5 мс. Но иногда латентность поднимается и никогда не падает. В конце концов, он выходит за пределы диапазона буфера соответствия, который у меня есть, и две системы перезагружаются, что всегда начинается с «нормальных» уровней латентности.

Что меня озадачивает изменчивость этой переменной задержки - что иногда она будет сидеть весь день на 20 мс +/- 5 мс, но в другие дни она будет регулярно и быстро возрастать, и наша система очень часто сбрасывается.

Что может быть здесь? Что можно сделать, чтобы исправить это? Является ли Windows вероятным источником задержки или системой ПЛК?

I 99% подозревают Windows, поскольку ПЛК предназначен для ответа в реальном времени, а Windows - нет. Звучит ли это «нормально» для Windows? Если это так, даже если есть другие процессы, связанные с сетью и/или другими ресурсами, почему Windows никогда не пытается догнать - чтобы увеличиться в латентности, когда возникает конфликт, но вернитесь к нормальным уровням задержек после прекращения конкуренции?

FYI: приложение Windows вызывает SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS), и каждый критический поток запускается с AfxBeginThread(SomeThread, pSomeParam, THREAD_PRIORITY_TIME_CRITICAL). В системе как можно меньше работает, и приложение использует только около 5% доступного четырехъядерного процессора (с гиперпотоком, поэтому 8 эффективных процессоров). Нет смысла использовать SetThreadAffinityMask(), хотя я его рассматриваю.

Answer 1

Итак, у вас есть два устройства, ПЛК и камера, которые отправляют данные на один и тот же ПК с использованием UDP.

I 90% подозрительных сетей.

Либо просто механизм буферизации/форматирования в вашем коммутаторе/маршрутизаторе (кстати, я надеюсь, что ваша установка изолирована, то есть вы не просто подключили свое оборудование в занятую корпоративную сеть), либо сетевой стек на любом из устройств, или, возможно, какой-то пользовательский механизм повторной передачи в ПЛК. Оба протокола IP и Ethernet никогда не предназначались для обеспечения низких задержек.

Чтобы проверить сетевой трафик, используйте Wireshark.

Для лучшего эксперимента вы можете использовать другой компьютер с тремя сетевыми картами.

Подключите три устройства (клиент Windows, ПЛК, камера) к этому ПК и настройте network bridge between the 3 cards. Таким образом, второй ПК будет действовать как коммутатор Ethernet, и вы сможете использовать Wireshark для захвата всего сетевого трафика, который проходит через него.

Answer 2

Ответ оказался сложным взаимодействием между несколькими факторами, большинство из которых не передают какую-либо информацию, полезную для других ... кроме как примеров «только потому, что, похоже, она работает нормально в течение 12 месяцев» «Я даю вам лицензию на то, чтобы все было на самом деле».

Критически важным вопросом было то, что ПЛК был устройством от Beckhoff, к которому были присоединены несколько модулей ввода/вывода.Оказывается, что чем больше этих модулей подключено, тем меньше вероятность того, что ПЛК должен передавать UDP-пакеты, несмотря на наличие большого количества процессорного времени и пропускной способности сети. Это похоже на проблему разногласий по ресурсам, которую мы не решили - мы просто решили перейти на более мощное устройство ПЛК. Это устройство по-прежнему подвержено одной и той же проблеме, но проблема возникает, если вы пытаетесь передать примерно каждые 10 мс, а не 24 мс.

Проблема возникла из-за того, что наше приложение ПЛК работало прямо на пороге своих возможностей передачи UDP. ПЛК должен пройти свой путь через состояния на конечной машине, чтобы выполнить передачу. Если цикл PLC равен 2 мс, то самое быстрое, что он может когда-либо пройти через состояния в машине состояния, с которыми мы подключили модули ввода/вывода, составлял каждые 22 мс.

И, наконец, то, что было принято на первом этапе, было незначительным и несвязанным изменением при запуске ПЛК, опрокидывало его по краю и оставляло его время от времени не в состоянии идти в ногу с нормальным циклом передачи 24 мс. Таким образом, он будет постепенно отставать, давая появление все более латентного времени.

Я принимаю ответ @Soonts, потому что тщательный анализ некоторых захватов Wireshark был ключом к разблокированию происходящего.