Допустим, у меня есть 3 очереди (# указывает на данные):
Q1: (in)[ ###](out)
Q2: (in)[ #####](out)
Q3: (in)[ #############](out)
Допустим, я поместил все свои ICMP-пакеты в Q1 и все постоянные загрузки в Q3.
Как мне использовать tc команду (из iproute2), чтобы очистить Q1, когда у него есть данные, и игнорировать другие 2 очереди?
В настоящее время я ограничиваю скорость Q3, но это выглядит довольно грубо. Я бы хотел, чтобы Q3 загружался на полной скорости в то время, когда Q1 не имеет трафика.
Это возможно?
Обновить: Смотри мой версия 1 моего сценария QoS.
Обновление 2: Я дополнительно обновил свой сценарий (см. версия 2), но с тех пор я сменил ISP на того, который не поддерживает QoS (поэтому нет необходимости в динамическом изменении скорости). Однако я добавил аргументы -u и -d, чтобы я мог изменять свои верхние / нижние пределы без необходимости редактировать скрипт. Проблема с этим сценарием заключается в том, что скорость очереди никогда не достигает значения ceil; они только когда-либо достигают rate - я считаю, что этого не должно быть.
Обновление 3: Я не знаю почему, но версия 3 моего сценария QoS работает! Если бы кто-нибудь мог объяснить почему, это было бы здорово ... Я внес только очень незначительные изменения; Я не вижу, как то, что я сделал, заставило его работать ... Я изменил настройки серийной съемки после того, как обнаружил, что это работает.
Хороший скрипт, мне нравится часть с зависящей от времени динамической скоростью загрузки. ;) Во всяком случае, делаю именно то, что вы хотите. Я делал это с помощью htb, но несколько месяцев назад перешел на hfsc. Хитрость заключается в том, чтобы ограничить q3 со скоростью до очень низкой скорости, но дать ему с помощью ceil полную полосу пропускания. q1, с другой стороны, получает более высокую скорость и тот же самый ceil. Один пример из реального мира:
tc class add dev ppp0 parent 1: classid 1:1 htb rate 100kbps ceil 100kbps
tc class add dev ppp0 parent 1:1 classid 1:10 htb rate 60kbps ceil 100kbps prio 1
tc class add dev ppp0 parent 1:1 classid 1:11 htb rate 39kbps ceil 100kbps prio 2
tc class add dev ppp0 parent 1:1 classid 1:12 htb rate 1kbps ceil 100kbps prio 3
Q1 будет 1:10
Q2 будет 1:11
Q3 будет 1:12
Может быть, ваша проблема кроется в вашем сложном сценарии. Попробуйте более легкую версию для отладки.
tc -s -d class show dev <interface> должен показать некоторую статистику об очередях. Давайте покажем нам результат, если q1 нечего делать, а q3 не использует полную полосу пропускания. Также вы можете попробовать hfsc.
Одно замечание: QOS или Traffic Control для входящего трафика бесполезны в большинстве конфигураций. Обычно вы выполняете роль получателя, у которого нет власти над тем, какой объем данных / время получать. Вы можете использовать Ingress-Queuing, но это мало поможет, только отбрасывает уже принятые пакеты.
Это не так плохо, как кажется, потому что в настоящее время большинство коммутируемых соединений асимметрично, а это означает, что направление передачи является узким местом. (Всегда с вашей точки зрения)
Посмотрите на использование «приоритета», «скорости» и «потолка».
Вы должны иметь возможность дать Q3 низкий уровень (и высокий потолок) ... и Q1 «более низкий» приоритет (что делает его на самом деле более важным). Что это должно сделать, так это дать Q1 преобладающую полосу пропускания ... когда он не используется ... Q3 затем следует поднять до своего потолка (поскольку это не так важно).
Вот моя рабочая версия: qos-v3.sh
Это работает даже с QoS для загрузок; но для «стабилизации» требуется некоторое время. Это потому, что, насколько я понимаю, серверы по-прежнему будут пытаться отправлять вам с максимально возможной скоростью, но поскольку сценарий QoS отбрасывает пакеты, входящее соединение часто замедляет скорость, с которой оно отправляет пакеты (до тех пор, пока пакеты перестаньте падать).
Как 7 из 9 сказали бы: грубый, но эффективный (о боже, я не ...)