Дисциплина hfsc, разъясните пожалуйста

У тебя в 1:10 и 1:21 есть rt составляющая, а rt насколько я знаю не конкурирует, сразу отдается в сеть. В 1:21 нет ls.

Как вообще hfsc у тебя работает чувствуется разница с htb? А prio, по манам приоритетный класс передается, а менее приоритетный ждет пока в приоритетном есть что-то. Как на практике, условие выполняется? Вроде бы то что нужно.

С htb в свое время работало нормально, но торрентами конечно задавить весь канал довольно легко, там создается много соединений. Я пробовал htb->prio настраивать sfq hash keys (на «листьях») по адресу источника из локальной сети (инфы мало, но что-то состряпал) и оно даже работало минут 15, а потом пакеты просто переставали ходить. Особо дальше не разбирался, хотя тема интересная и можно будет еще потестировать, но не на рабочем шлюзе.

Но в общем в конце концов я просто оставил prio, потому как было 2 интернет-канала (основной и резерв) с очень разными скоростями и скрипты запуска шейпера в зависимости от того какое соединение работает/не работает были какими-то костыльными.

В принципе prio работает, пакеты в нужных классах бегают, скорость соединения задавать не нужно, удобно. А чувствуется ли разница с htb.. даже не знаю, прям реально не замерял, prio все таки для меня больше подходит, потому что мне нужны именно приоритеты трафика, а не ограничения скорости.

Ну и естественно трафик приоритезируется в обе стороны: к клиенту и от него.

А что касается hfsc, хочется заюзать, но мне нужно несколько приоритетов, потому и спрашиваю, так как немного не догоняю логику процесса. Хочется выделить высокоприоритетный трафик, среднеприоритетный, который будет обрабатываться во вторую очередь и остальной.

Но в общем в конце концов я просто оставил prio, потому как было 2 интернет-канала (основной и резерв) с очень разными скоростями и скрипты запуска шейпера в зависимости от того какое соединение работает/не работает были какими-то костыльными.

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

Мне собственно тоже нужны только приоритеты но жесткие. Буде пробовать сегодня prio.

Про priomap из соседней темы priomap 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1, priomap 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2

Что получается в итоге? В чем разница если просто не указывать?

Я пробовал htb->prio настраивать sfq hash keys (на «листьях») по адресу источника из локальной сети (инфы мало, но что-то состряпал) и оно даже работало минут 15, а потом пакеты просто переставали ходить

Я использую так на концах, ничего не дропается, но насчет равномерности распределения пока не проверял. Говорят должно не по сессиям бить скорость, а по ip.

$TC filter add dev $imq_upload parent ${i}01: protocol all handle ${i}01 flow hash keys dst divisor 1024
$TC filter add dev $imq_upload parent ${i}02: protocol all handle ${i}02 flow hash keys dst divisor 1024
$TC filter add dev $imq_upload parent ${i}03: protocol all handle ${i}03 flow hash keys dst divisor 1024

Как я понимаю, это режет сессии по указанному параметру, то есть «выравнивает их количество». Вот мой пример (закомментированное в конце).

        #Qdisc PRIO для трафика, идущего с lan-интерфейса в локальную сеть
        $qdisc_ $lan_if root handle 1: prio
        $qdisc_ $lan_if parent 1:1 handle 11: sfq perturb 10
        $qdisc_ $lan_if parent 1:2 handle 12: sfq perturb 10
        $qdisc_ $lan_if parent 1:3 handle 13: sfq perturb 10
        #Классификаторы
        $filter $lan_if parent 1: protocol ip prio 1 u32 match ip sport 1935 0xffff flowid 1:1
        #Внешние классификаторы
        #$filter parent 11: protocol ip handle 5 flow hash keys dst divisor 256
        #$filter parent 13: protocol ip handle 6 flow hash keys dst divisor 256