Приоритет UDP по FTP, SCP и т. Д. В Linux

У меня есть установка, при которой одна «ведущая» система Linux связывается с 3 «подчиненными» системами, также работающими под управлением Linux, на выделенном интерфейсе Ethernet (только мастер и 3 подчиненных). Ведомые устройства отправляют данные на мастер через UDP каждые 5 мс или около того. Кроме того, мастер имеет приложения, которые непрерывно извлекают файлы из всех трех ведомых по протоколам FTP, SCP и т. Д.

Пакеты UDP должны собираться ведущим как можно быстрее, предпочтительно в течение 3-4 мс. Когда я запускаю установку только с приложением приема UDP, запущенным на главном компьютере, я вижу, что это условие легко выполняется. Тем не менее, когда FTP / SCP / и т. Д. приложения также остаются запущенными, во время приема наблюдаются всплески. Размер передаваемых файлов довольно меньше, но каждый второй или около того получает новый файл от каждого ведомого устройства.

Тот факт, что результаты хороши при запуске установки без активных приложений передачи файлов, говорит о том, что "организация очередей / планирование" в сети Linux, похоже, дает одинаковый приоритет как UDP, так и другим протоколам. Может быть, он даже удерживает UDP, если FTP работает?

Есть ли способ сообщить Linux (программно / командам), чтобы он отдавал наивысший приоритет связи UDP и "приостанавливал" другие вещи, такие как передача файлов, когда сообщение UDP готово к приему?

Редактировать 1: я добавил их для управления трафиком на основе типа протокола (UDP - протокол 17)

tc qdisc add dev eth0 root handle 10: prio
tc filter add dev eth0 parent 10: protocol ip prio 1 u32 match ip protocol 17 0xff flowid 10:1
tc filter add dev eth0 parent 10: prio 3 protocol all u32 match u32 0 0 flowid 10:3

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

— Джон Смит
источник

Это не то, как работает UDP, он не «собирается» от ведомого устройства, он отправляется слепым ведомым устройством, и ведущий получает его. Если вы видите задержки, это либо потому, что сетевая очередь заполнена на ведомых устройствах, либо на ведущем устройстве, либо потому, что ведущее устройство не выполняет правильное планирование для вашего случая.

— djsmiley2k

Означает ли 5 мс 5 миллисекунд или вы имели в виду 5 мин. Если первое, вы идете по дуракам, потому что Linux не является операционной системой реального времени. Вы можете расставить приоритеты трафика, добавив ограничения скорости / очереди - вы захотите сделать это для отправителей. Google "расширенный контроль пакетов" для Howtos по управлению трафиком. Также обратите внимание на уменьшение размеров MTU всех устройств на вашей локальной сети. Это уменьшит пропускную способность, но также уменьшит задержку.

— Давидго

Да, я имел в виду 5 миллисекунд и понимаю, что Linux не является ОСРВ. Тем не менее, я также упомянул, что при запуске только UDP-приложения задержки находятся в определенных пределах. Проблема начинается только тогда, когда приложение FTP тоже становится активным. Это гигабитная сеть, зарезервированная только для этих 4 плат без добавления переходов и т. Д. Я посмотрел на систему управления трафиком Linux и создал 2 фильтра. Тем не менее, они, кажется, не вступают в силу. Пожалуйста, посмотрите на редактирование в вопросе.

— Джон Смит

Первое: Linux не является операционной системой реального времени. Невозможно сказать ядру, что некоторые приложения должны реагировать на какое-то событие в заданный период времени, например, 3-4 мс, и дать гарантию, что это произойдет. Таким образом, всякий раз, когда система загружается, вы должны предполагать, что будут задержки.

Тем не менее, вы можете настроить вещи в пользу вашего приложения приема пакетов UDP:

В Linux есть управление сетевым трафиком (см., Например, Traffic Control HOWTO , пример скрипта для DSL с ограниченной пропускной способностью ), который вы можете использовать для настройки разных очередей с разными приоритетами, например, для ваших пакетов UDP и для больших пакетов.
В Linux есть cgroups (контрольные группы), которые вы можете использовать для назначения различных приоритетов и пределов ввода-вывода для вашего процесса получения UDP и ftpd/ / sshdпроцессов, потому что я предполагаю, что дисковый ввод-вывод другими процессами также может остановить ваш Приложение для приема UDP-пакетов (поэкспериментируйте, чтобы узнать, правда ли это).

Опять же: нет способа гарантировать что-либо.

— dirkt
источник

Я посмотрел на управление движением. "tc qdisc add dev eth0 корневой дескриптор 10: prio", "tc filter add dev eth0 parent 10: протокол ip prio 1 u32 match ip protocol 17 0xff flowid 10: 1", "tc filter add dev eth0 parent 10: протокол prio 3 all u32 match u32 0 0 flowid 10: 3 ". Третий - это то, что я считаю" фильтром всех совпадений ". Однако это не имеет значения. Я все еще получаю такие же шипы.

— Джон Смит

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

— dirkt

Я определенно ценю вашу помощь! Эти фильтры (я сейчас добавил их в сам вопрос. Правильно отформатированные) выглядят правильно для вас? Как я могу проверить, используются ли 3 предварительные группы, как ожидалось? Я не могу найти ссылку на это.

— Джон Смит