Шейпер, HTB + PRIO, подскажите как правильнее

Обрабатывать голос и видео

Рекомендую выкинуть HTB для траффика критичного к задержкам и обратить внимание на HFSC

HTB хорошо гарантирует утилизацию канала(то есть если у вас N mbit он честно раздаст их), но приоритеты у него достаточно мягкие, то есть дропать низкоприоритетный траффик он будет только если уж совсем много высокоприоритетного.

HFSC(а точнее его подкласс RT) в этом плане хорош тем, что как только пришёл высокоприоритетный(real-time в терминах HFSC) траффик, он будет доставлен, а доставка низкоприоритетного(link-share) будет отложена.

Но то же самое делает PRIO. Про HFSC честно говоря вообще впервые слышу.

Скрипт я сделал, критичный трафик обрабатывается до передачи остального в HTB, в котором делится и приоритезируется чуть менее критичный трафик. Но в общем сделать то сделал, но пока отложил на полку. Оставил простую PRIO и тупо обрезал канал беспарольным вайфайщикам с помощью TBF. Трабл у меня в том, что есть 2 интернет-канала: основной и резерв. Переключения между ними происходят автоматически (скрипт раз в минуту проверяет состояние обоих каналов), а вот скорость у них разная, у первого 12Мбит/с, у второго 2Мбит/с. Поэтому для дележки канала нужно перезапускать скрипт шейпера в зависимости от состояния каналов и их скоростей. В общем получается довольно монструозно. Решил не извращаться, не усложнять и просто оставил PRIO.

Но то же самое делает PRIO

Нет, у PRIO независимые очереди и высокоприоритетный траффик легко зафлудить большим количеством низкоприоритетного. Отдаваться он БУДЕТ, но задержки будут существенно скакать...

Но если PRIO устраивает - городить огород с HTFC не стоит. У меня PRIO тоже используется там, где HTB и HFSC - выстрел из пушки по воробьям.

Поэтому для дележки канала нужно перезапускать скрипт шейпера в зависимости от состояния каналов и их скоростей.

Можно влепить соответствующие tc change на все нужные классы. Ну или перезапускать скрипт передавая rate в качестве параметра

Нет, у PRIO независимые очереди и высокоприоритетный траффик легко зафлудить большим количеством низкоприоритетного. Отдаваться он БУДЕТ, но задержки будут существенно скакать...

Это да.. .

Можно влепить соответствующие tc change на все нужные классы. Ну или перезапускать скрипт передавая rate в качестве параметра

Можно, я передавал rate в зависимости от переключения на определенный интерфейс. Но реально выходит тихий ужас.

Нужно поискать информацию об HFSC. Я всегда руководствовался LARTC, но даже в английском варианте HFSC я там не нашел.

Хотя в LARTC (в переводе) написано следующее:

Когда необходимо извлечь пакет из очереди, то первым проверяется класс :1. Каждый последующий класс проверяется только в том случае, если в предыдущем нет ни одного пакета.

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

ps: это я про PRIO.

даже в английском варианте HFSC я там не нашел.

Да, документации по нему кот наплакал, но могу рассказать вкратце суть.

У HFSC есть 3 типа подклассов(очередей, хз, как удобнее): ls(link-share, по сути засрать выделенную полосу как получиться), rt(real-time - как траффик придёт в полосу - сразу же отдать, не важно где в иерархии классов он находится) и sc(гибридная дисциплина, может содержать внутри себя как rt так и ls-подклассы. Ну и другие sc-подклассы, конечно же).

Есть еще директива ul - аналог htb-шного ceil - описывает верхний потолок скорости класса, который он может отдать.

Классических приоритетов(атрибут prio как в HTB) в HFSC нет! Если сильно надо, то можно прицепить на ls подкласс дочерний класс, например, HTB и разруливать там как привычнее.

То есть, простейший вариант с 2 полосами: высокоприоритетной(для VOIP) и низкоприоритетной(для всего остального) выглядит так(рабочий пример, скопипащено с конфига домашнего сервера):

BAND="6Mbit"
HIGH_LIMIT="5Mbit"
MAIN_IFACE="imq0"

tc qdisc add dev ${MAIN_IFACE} root handle 1: hfsc default 11

# Internet traffic (full MAXIMUM speed)
tc class add dev ${MAIN_IFACE} parent 1:0 classid 1:1 hfsc sc rate ${BAND} ul rate ${BAND}
# Subclasses of Internet traffic
tc class add dev ${MAIN_IFACE} parent 1:1 classid 1:10 hfsc rt rate 1Mbit ls rate ${HIGH_LIMIT}
tc class add dev ${MAIN_IFACE} parent 1:1 classid 1:11 hfsc ls rate 1Mbit

Да, забыл сказать - классы могут быть гибридными - содержать как link-share так и real-time составляющую. Тут классу 1:10 гарантируется 1 мегабит при любых раскладах, остальное - как получится, верхняя граница не указана -> упрётся в верхнюю границу класса 1:1. А вот класс 1:11 - от мегабита и выше может сожрать, но будет конкурировать за скорость с ls-частью класса 1:10, упираясь в верхнюю границу всё того же 1:1

Еще фишка есть у HFSC называется «Нелинейная кривая обслуживания»(Non-linear service curve). Типа можно первые N(1, 2, 3, 10, 100500) секунд отдавать на одной скорости для соединения, а потом - на другой, более низкой, например. Я этим пока не пользуюсь, но подумываю заюзать.

Ну, я тестил PRIO торрентами, засунул всё что не классифицировал в класс с наименьшим приоритетом и проверил отзывчивость SSH(который сунул в максимальный приоритет, естественно). Честно говоря - хреновой оказалась отзывчивость. Не, бесспорно лучше, чем с дефолтной(pfifo_fast) дисциплиной обслуживания. Но всё равно - хреново.

Спасибо вам большое за краткий вводный курс по HFSC! Вообще-то это то, что нужно. Надо будет подумать!

Вот была-бы дисциплина типа HFSC, но не зависящая от rate - это было бы просто супер-вариантом для моей задачи.

А вот класс 1:11 - от мегабита и выше может сожрать, но будет конкурировать за скорость с ls-частью класса 1:10, упираясь в верхнюю границу всё того же 1:1

Подскажите, а как он будет конкурировать. Если он realtime, то скорее всего конкуренцию он будет выигрывать?

Я набросал скрипт под свои задачи: в первую очередь обрабатывать высокоприоритетный голосовой/видео-трафик, затем делить остаток на 2 группы и в каждой подгруппе в первую очередь обрабатывать трафик с 80/443 портов. Вот что вышло:

#!/bin/bash

rate="5000"
lan_if="lan"
high_prio_ports="53 1935"
high_prio_dst="8.8.8.8 8.8.4.4"
medium_prio_ports="80 443"

tc qdisc del dev $lan_if root    2> /dev/null > /dev/null

tc qdisc add dev $lan_if root handle 1: hfsc default 222
tc class add dev $lan_if parent 1:0 classid 1:1 hfsc sc rate ${rate}kbit ul rate ${rate}kbit
#Корневой класс: голос/видео и остальное 
tc class add dev $lan_if parent 1:1 classid 1:10 hfsc rt rate $[4*${rate}/10]kbit ls rate $[8*${rate}/10]kbit
tc class add dev $lan_if parent 1:1 classid 1:20 hfsc ls rate $[6*${rate}/10]kbit
#Остальное делим на 2 группы: пользователи и свободный wi-fi
tc class add dev $lan_if parent 1:20 classid 1:21 hfsc sc rate $[4*${rate}/10]kbit
tc class add dev $lan_if parent 1:20 classid 1:22 hfsc sc rate $[2*${rate}/10]kbit
#Пользователи: трафик с 80/443 портов и прочий трафик
tc class add dev $lan_if parent 1:21 classid 1:211 hfsc rt rate $[3*${rate}/10]kbit
tc class add dev $lan_if parent 1:21 classid 1:212 hfsc rt rate $[1*${rate}/10]kbit
#Свободный wi-fi: трафик с 80/443 портов и остальное
tc class add dev $lan_if parent 1:22 classid 1:221 hfsc rt rate $[1*${rate}/10]kbit
tc class add dev $lan_if parent 1:22 classid 1:222 hfsc rt rate $[1*${rate}/10]kbit


#Фильтры для высокоприоритетного трафика
for port in $high_prio_ports ; do
   tc filter add dev $lan_if protocol ip parent 1: prio 1 \
   u32 match ip sport $port 0xffff flowid 1:10
done
for dst in $high_prio_dst ; do
   tc filter add dev $lan_if protocol ip parent 1: prio 1 \
   u32 match ip src $dst flowid 1:10
done

#Остальной транзитный трафик (по меткам iptables, 103 - трафик для wi-fi клиентов)
for i in "101" "102" ; do
   tc filter add dev $lan_if protocol ip parent 1: prio 3 \
   handle $i fw flowid 1:21
done
   tc filter add dev $lan_if protocol ip parent 1: prio 3 \
   handle 103 fw flowid 1:22

##Фильтр для чуть менее приоритетного трафика с  80/443 портов для классов 1:21 и 1:22
for port in $medium_prio_ports ; do
   for class in "1:21" "1:22" ; do
      tc filter add dev $lan_if protocol ip parent 1: prio 7 \
      u32 match ip sport $port 0xffff flowid ${class}1
   done
done

Фильтры я вроде описал верно, на первый взгляд, пока что не могу проверить, дома всего 1 компьютер с linux, но сам скрипт выполняется.

Думаю, что в боевых условиях дисциплину hfsc помещу в подкласс 1:1 дисциплины PRIO, чтобы в подкласс 1:2 шел весь локальный трафик, который может достигать гигабита. Идентификаторы конечно придется поменять..

Ой, просмотрел для классов 1:212 и 1:222 нужно задать ls вместо rt. )

Если он realtime, то скорее всего конкуренцию он будет выигрывать?

Он не realtime, он - гибридный. 1 мегабит real-time и 5 мегабит - link-share. Конкурировать он будет ТОЛЬКО в рамках link-share

Понял, спасибо :)

Парни отпишитесь получилось разобраться с приоритетами?

Что лучше использовать htb или hfsc для этих целей?

Сейчас используется такая конструкция

$TC qdisc add dev $imq_download root handle 1: htb

$TC class add dev $imq_download parent 1: classid 1:1 htb rate $rate_isp

$TC class add dev $imq_download parent 1:1 classid 1:11 htb rate $rate_min ceil $rate_isp prio 0
$TC class add dev $imq_download parent 1:1 classid 1:12 htb rate $rate_min ceil $rate_isp prio 1
$TC class add dev $imq_download parent 1:1 classid 1:13 htb rate $rate_min ceil $rate_isp prio 10

$TC qdisc add dev $imq_download parent 1:11 handle 11: sfq perturb 10
$TC qdisc add dev $imq_download parent 1:12 handle 12: sfq perturb 10
$TC qdisc add dev $imq_download parent 1:13 handle 13: sfq perturb 10

$TC filter add dev $imq_download parent 11: protocol all handle 11 flow hash keys dst divisor 1024
$TC filter add dev $imq_download parent 12: protocol all handle 12 flow hash keys dst divisor 1024
$TC filter add dev $imq_download parent 13: protocol all handle 13 flow hash keys dst divisor 1024

Но что-то пока не удается поставить веб-трафик перед торрентом. Трафик попадает в нужные классы.

С hfsc возможно равномерное распределение скорости между всеми пользователями? Или просто на класс с hfsc вещается тот же sfq с нужными фильтрами?

Я все таки остановился на простой prio

   #Описание шейпера
   $qdisc_add dev $lan_if root handle 1: prio bands 3 priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
   $qdisc_add dev $lan_if parent 1:1 handle 10: pfifo           #Трафик от сервера AdobeConnect
   $qdisc_add dev $lan_if parent 1:2 handle 20: sfq perturb 10  #Транзит до клиента с $medium_prio_ports
   $qdisc_add dev $lan_if parent 1:3 handle 30: sfq perturb 10  #Прочий (в т.ч. локальный) трафик

Но набрасывал для своих задач скрипт с HFSC, однако не тестировал (как уже было сказано, hfsc по умолчанию весь, не попадающий под фильтры трафик, блокирует).

tc qdisc add dev $lan_if root handle 3: prio bands 2 priomap 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
tc qdisc add dev $lan_if parent 3:1 handle 1: hfsc default 222
tc qdisc add dev $lan_if parent 3:2 handle 2: pfifo

tc class add dev $lan_if parent 1: classid 1:1 hfsc sc rate ${rate}kbit ul rate ${rate}kbit
#Корневой класс: голос/видео и остальное
tc class add dev $lan_if parent 1:1 classid 1:10 hfsc rt rate $[4*${rate}/10]kbit ls rate $[8*${rate}/10]kbit
tc class add dev $lan_if parent 1:1 classid 1:20 hfsc ls rate $[6*${rate}/10]kbit
#Остальное делим на 2 группы: пользователи и свободный wi-fi
tc class add dev $lan_if parent 1:20 classid 1:21 hfsc sc rate $[4*${rate}/10]kbit
tc class add dev $lan_if parent 1:20 classid 1:22 hfsc sc rate $[2*${rate}/10]kbit
#Пользователи: трафик с 80/443 портов и прочий трафик
tc class add dev $lan_if parent 1:21 classid 1:211 hfsc rt rate $[3*${rate}/10]kbit
tc class add dev $lan_if parent 1:21 classid 1:212 hfsc ls rate $[1*${rate}/10]kbit
#Свободный wi-fi: трафик с 80/443 портов и остальное
tc class add dev $lan_if parent 1:22 classid 1:221 hfsc rt rate $[1*${rate}/10]kbit
tc class add dev $lan_if parent 1:22 classid 1:222 hfsc ls rate $[1*${rate}/10]kbit

Фильтры не привожу, надеюсь поможет.