Сокращение потери пакетов в tc ограничении уровня

Rsync в восходящем направлении оказывает поддержку для SLP (Протокол обнаружения сервисов). Это не включено в ванили rsync источники, но можно найти поддержку SLP в rsync-патчах tarball в rsync домашней странице (slp.diff). Например, SUSE rsync пакет создается с этим патчем; я не знаю о других дистрибутивах.

Я не уверен, что это - то, что Вы ищете, ни делаете у меня есть любой опыт с SLP, все же.

2
27.06.2011, 16:56
3 ответа

Если я понял правильно, Вы пытаетесь ограничить свой входной трафик от Вашего ISP путем ограничения исходящего трафика в локально стоящем интерфейсе.

Потеря пакетов, которую Вы видите, должна, вероятно, ожидаться, поскольку отброшенными пакетами является (один из) TCPs путь (пути) обнаружить перегрузку и способ, которым маршрутизатор может сигнализировать о перегрузке. Это - также единственный разумный способ, которым Ваш маршрутизатор может соблюдать ограничение, которое Вы дали ему через tc, не повреждаясь т.е. предотвращение перегрузки TCPs. (tc действительно имеет средства для использования КРАСНОГО, хотя я не знаю достаточно об этом, чтобы сказать Вам что-либо вне, он - существование).

Вместо того, чтобы формировать исходящий трафик в Вашем входящем интерфейсе направления, Вы могли проверить вход tc qdisc, присоединить его к интерфейсу, стоящему перед Вашим ISP и фильтром tc для управления на основе политик входным трафиком. Потеря пакетов все еще произойдет, поскольку это - вероятно, единственный жизнеспособный путь к Вашему маршрутизатору для передачи сигналов о перегрузке.

Для примера посмотрите запись поваренной книги LARTC "Окончательный Транспортный Формирователь", которые среди прочего используют вход tc qdisc.

3
27.01.2020, 22:07
  • 1
    Даже в ingress qdisc будет потеря пакетов. Я указал 2 Мбит как предел и шоу интерфейса направления WAN входящий уровень приблизительно 300 Кбит/с. В интерфейсе направления NAT это были стабильные 250 Кбит/с. Но это было немного лучше, чем уровень limting в интерфейсе направления NAT. В моем случае у меня есть один интерфейс глобальной сети и больше чем один интерфейс NAT, стоящий перед отдельными локальными сетями. Для одной сети я должен ограничить скорость загрузки 2 Мбит. –  nixnotwin 24.05.2011, 13:02
  • 2
    : "Потеря пакетов все еще произойдет, поскольку это - вероятно, единственный жизнеспособный путь к Вашему маршрутизатору для передачи сигналов о перегрузке". TCP сигнализирует о перегрузке с потерей пакетов; нет никакого волшебства, связанного с выходной организацией очередей или входом. –  Mike Pennington 24.05.2011, 13:57

Это зависит от размера Вашей tx очереди при регулировке трудно затем TC, может только отбросить, а не поставить пакеты в очередь, к сожалению, я только знаю, как сделать это на Cisco iOS, не Unix tc.

0
27.01.2020, 22:07

Вы можете увеличить размер очереди, чтобы решить проблему. (Как заявил jdborg )Извините, мой рейтинг недостаточно высок, чтобы комментировать напрямую.

Вот пример

Если эта команда вызывает нежелательную потерю пакетовsudo tc qdisc add dev eno1 root tbf rate 1mbit burst 32kbit latency 400ms

Вы можете решить эту проблему, увеличив размер буфера (очереди ), изменив задержку с 400msна 10000ms

.

Теперь команда будет выглядеть примерно такsudo tc qdisc add dev eno1 root tbf rate 1mbit burst 32kbit latency 10000ms

Резюме:Увеличение размера очереди, как показано выше, решит проблему потери пакетов. Вопрос только в том, насколько его нужно увеличить.

Мои исследования

Я провел тест iPerf со скоростью 10 Мбит/с, когда очередь была всего 400 мс, что привело к потере 90% пакетов UDP. Повторное выполнение теста iPerf, когда очередь была установлена ​​на 10000 мс, привела к потере пакетов 0%.

Как настроить тест iPerf

Был проведен тест iPerf, в котором ПК #1 был сервером iPerf, а ПК #2 — клиентом iPerf. Исходящее соединение ПК #2 было заблокировано с помощью команды tcenter image description here

0
04.03.2020, 23:48

Теги

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