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

603
John Smith

У меня есть установка, в которой одна «главная» система 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 

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

0
Это не то, как работает UDP, он не «собирается» от ведомого устройства, он отправляется слепым ведомым устройством, и мастер получает его. если вы видите задержки, это либо потому, что сетевая очередь заполнена на ведомых устройствах, либо на ведущем устройстве, либо потому, что ведущее устройство не выполняет правильное планирование для вашего случая. djsmiley2k 7 лет назад 1
Означает ли 5 ​​мс 5 миллисекунд или вы имели в виду 5 мин. Если первое, вы идете по дуракам, потому что Linux не является операционной системой реального времени. Вы можете расставить приоритеты трафика, добавив ограничения скорости / очереди - вы захотите сделать это для отправителей. Google "расширенный контроль пакетов" для Howtos по управлению трафиком. Также обратите внимание на уменьшение размеров MTU всех устройств на вашей локальной сети. Это уменьшит пропускную способность, но также уменьшит задержку. davidgo 7 лет назад 0
Да, я имел в виду 5 миллисекунд и понимаю, что Linux не является ОСРВ. Тем не менее, я также упомянул, что при запуске только UDP-приложения задержки находятся в определенных пределах. Проблема начинается только тогда, когда приложение FTP тоже становится активным. Это гигабитная сеть, зарезервированная только для этих 4 плат без добавления переходов и т. Д. Я изучил управление трафиком в Linux и создал 2 фильтра. Тем не менее, они, кажется, не вступают в силу. Пожалуйста, посмотрите на редактирование в вопросе. John Smith 7 лет назад 0

1 ответ на вопрос

1
dirkt

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

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

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

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

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

Я посмотрел на управление движением. "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 ". Третий - это то, что я считаю" фильтром всех совпадений ". Однако это не имеет значения. Я все еще получаю такие же шипы. John Smith 7 лет назад 0
Я не могу удаленно отладить твою проблему, извини. Первым шагом было бы выяснить, действительно ли очередь пакетов связана с вашими пиками, то есть получить некоторую регистрацию того, как используются ваши очереди. И если это вызывает планировщик ввода / вывода, который вызывает пики, то, конечно, контроль трафика не поможет ... dirkt 7 лет назад 0
Я определенно ценю вашу помощь! Эти фильтры (я сейчас добавил их в сам вопрос. Правильно отформатированные) выглядят правильно для вас? Как я могу проверить, используются ли 3 предварительные группы, как ожидалось? Я не могу найти ссылку на это. John Smith 7 лет назад 0

Похожие вопросы