LINUX.ORG.RU
ФорумAdmin

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

 , ,


0

1

Здравствуйте! Пытаюсь разобраться с hfsc, есть у меня интернет-канал скажем 20мбит в обе стороны, есть 3 приоритета трафика: видеосвязь, веб, прочее. Хочется это приоритезировать. сейчас вот такая конструкция с 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           #видеосвязь
   $qdisc_add dev $lan_if parent 1:2 handle 20: sfq perturb 10  #веб-трафик
   $qdisc_add dev $lan_if parent 1:3 handle 30: sfq perturb 10  #Прочий (в т.ч. локальный) трафик
Пытаясь раскурить hfsc нарисовал вот что (prio в начале, чтобы не терялся неотклассифицированный трафик и ходил локальный трафик):
$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
$qdisc_add dev $lan_if parent 3:1 handle 1: hfsc default 1:22
$qdisc_add dev $lan_if parent 3:2 handle 2: pfifo

$class_add dev $lan_if parent 1: classid 1:1 hfsc sc rate 20mbit ul rate 20mbit 
$class_add dev $lan_if parent 1:1 classid 1:10 hfsc rt rate 8mbit ls rate 16mbit #видеосвязь
$class_add dev $lan_if parent 1:1 classid 1:20 hfsc sc rate 12mbit 		 
$class_add dev $lan_if parent 1:20 classid 1:21 hfsc rt rate 8mbit #веб-трафик
$class_add dev $lan_if parent 1:20 classid 1:22 hfsc ls rate 4mbit #прочее

Вот не пойму во втором примере не будут ли между собой конкурировать классы 1:10 и 1:21?
Или же у класса 1:10 приоритет выше, так как он находится выше в иерархии?
Или же подклассы 1:21 и 1:22 будут конкурировать между собой в ls-части класса 1:1?


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

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

fet4 ()
Ответ на: комментарий от fet4

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

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

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

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

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

gard ()
Ответ на: комментарий от gard

Но в общем в конце концов я просто оставил 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

fet4 ()
Ответ на: комментарий от fet4

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

        #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
Про два интернет канала - маршрут и менялся, сейчас кстати один канал остался.
Про цифры, указываемые в priomap - я вот тут это пытался объяснить: http://debianforum.ru/index.php?topic=6982.msg56972#msg56972

gard ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.