проблема с htb

[shicoy]

имеем шейпер примерно такого вида (вешается на тунель ppp)

iface=$1
bw=$2

bw=`echo $bw*1.05 | bc 2>/dev/null`
bw01=`echo $bw*0.01 | bc 2>/dev/null`
bw75=`echo $bw*0.75 | bc 2>/dev/null`
bw24=`echo $bw*0.24 | bc 2>/dev/null`
bw99=`echo $bw*0.99 | bc 2>/dev/null`
upload=`echo $bw+1 | bc 2>/dev/null`

tc=/sbin/tc

$tc qdisc del dev $iface root
$tc qdisc del dev $iface handle ffff: ingress

$tc qdisc add dev $iface root handle 1: htb default 500
$tc class add dev $iface parent 1: classid 1:10 htb rate ${bw}Kbit

#Трафик критического приоритета: icmp, ssh, dns - 1%
$tc class add dev $iface parent 1:10 classid 1:15 htb rate ${bw01}Kbit ceil ${bw}Kbit prio 0
$tc qdisc add dev $iface parent 1:15 handle 15: sfq perturb 10
$tc filter add dev $iface parent 1:0 protocol ip prio 40 u32 match ip protocol 1 0xff flowid 1:15
$tc filter add dev $iface parent 1:0 protocol ip prio 40 u32 match ip sport 53 0xffff flowid 1:15
$tc filter add dev $iface parent 1:0 protocol ip prio 40 u32 match ip sport 22 0xffff flowid 1:15


#Трафик среднего приоритета 75%
$tc class add dev $iface parent 1:10 classid 1:50 htb rate ${bw75}Kbit ceil ${bw}Kbit prio 2
$tc qdisc add dev $iface parent 1:50 handle 50: sfq perturb 10

$tc filter add dev $iface parent 1:0 protocol ip prio 30 u32 match ip sport 443 0xffff flowid 1:50
$tc filter add dev $iface parent 1:0 protocol ip prio 40 u32 match ip sport 80 0xffff flowid 1:50
$tc filter add dev $iface parent 1:0 protocol ip prio 50 u32 match ip sport 8080 0xffff flowid 1:50
$tc filter add dev $iface parent 1:0 protocol ip prio 60 u32 match ip sport 110 0xffff flowid 1:50
$tc filter add dev $iface parent 1:0 protocol ip prio 70 u32 match ip dport 25 0xffff flowid 1:50

#Весь остальной трафик, выделяем 24%
$tc class add dev $iface parent 1:10 classid 1:75 htb rate ${bw24}Kbit ceil ${bw}Kbit prio 5
$tc qdisc add dev $iface parent 1:75 handle 75: sfq perturb 10
$tc filter add dev $iface parent 1:0 protocol ip prio 100 u32 match ip dst 0.0.0.0/0 flowid 1:75

#Исходящий трафик, выделяем 100%

$tc qdisc add dev $iface handle ffff: ingress
$tc filter add dev $iface parent ffff: protocol ip prio 50 u32 match ip src 0.0.0.0/0 police rate ${upload}kbit burst 1536kb drop flowid :1

 

последнее время стал замечать сообщения ядра:

[174947.108171] HTB: quantum of class 10015 is small. Consider r2q change.
[174947.200582] HTB: quantum of class 10075 is small. Consider r2q change.
[174947.264379] HTB: quantum of class 10015 is small. Consider r2q change.
[174987.885563] HTB: quantum of class 10015 is small. Consider r2q change.
[174990.194733] HTB: quantum of class 10015 is small. Consider r2q change.
[174991.155255] HTB: quantum of class 10015 is small. Consider r2q change.
[174991.243170] HTB: quantum of class 10075 is small. Consider r2q change.

 

С чем это может быть связано? Как отследить class 10015 и class 10075?

Помогите, нервируют такие сообщения в ядре =)

[Max P]

попробовать увеличить r2q, по дефолту вроде как 10

[photon]

Это сообщение вылезает из-за того, что автоматически рассчитанный quantum получается меньше MTU. Лучше везде в параметрах класса ставить quantum $MTU. Для Ethernet -- это 1500, для PPP -- зависит от настроек.

Edited November 11, 2009 by photon

[shicoy]

а quantum Должен быть обязательно равен МТУ? на что влияет при шейпинге?

[Max P]

http://solaris.opennet.ru/base/net/htb_saga.txt.html

 

2) Второй параметр R2Q используется для квантования трафика в

классах. В случае малых скоростей рекомендуется значение = 1, что

позволяет шейпать с точностью до 4kbit. Если не указан, то =10,

что для скоростей >120Kbit.

 

3) В скриптах допустим параметр QUANTUM, но он используется только

как параметр для sfq, а не htb. При использовании htb.init для

htb-классов вычисляется автоматически, исходя из глобального

параметра R2Q и rate класса. На что влияет quantum в HTB, можно

попробовать понять из

http://www.docum.org/stef.coene/qos/faq/cache/31.html

На что влияет QUANTUM(как параметр в скриптах) для sfq - читать

http://lartc.org/howto/lartc.qdisc.classless.html#LARTC.SFQ.

 

[voron]

QUANTUM - сколько htb выпустит байт из листа за 1 раз. Поэтому и не надо его делать меньше mtu.

[Max P]

r2q кстате влияет на точность, сейчас потестил, r2q = 10 и rate = 1200kbit, в итоге по показаниям iptraf скорость пляшет от 1130 до 1180 постоянно, поставил r2q = 1 и rate = 1200kbit - скорость встала как вкопанная на 1195, вот думаю где бы еще недостающих 5кбит взять :)

[photon]

http://solaris.opennet.ru/base/net/htb_saga.txt.html

3) В скриптах допустим параметр QUANTUM, но он используется только

как параметр для sfq, а не htb.

Вы все перепутали. quantum -- это параметр дочерних классов HTB, SFQ -- это дисциплина очереди краевого класса, для снижения нагрузки лучше ставить pfifo. Т.е. quantum нужно указывать в строках такого типа:

$tc class add dev $iface parent 1:10 classid 1:75 htb rate ${bw24}Kbit ceil ${bw}Kbit prio 5 quantum 1500

Edited November 11, 2009 by photon

[Max P]

это не я попутал, это те кто писал доку :)

[shicoy]

но r2q ставить общий на всю дисциплину htb или можно выставлять персональный на каждый класс?

Опять же как правильно считать quantum исходя из моего примера.

 

так скажем для high priority class с резервированием 1% полосы (icmp)

так скажем для middle priority class с резервированием 75% полосы (www,ftp)

 

mtu 1496

общий brandwitdh 1024Кбит/сек

high priority class 10Кбит/сек или 1280 байт/сек

если r2q равен 10, то получаем

quantum = 1280/10 = 128, т.е. в таком случае лучше ставить равном mtu т.е. 1496 или 1500

 

а если middle priority class = 768Кбит или 98304 байт/сек

quantum = 98304/10 = 9830 , то в этом случае quantum не прописываем руками, а оставляем на подсчет системы? или лучше всеже указать равнм 10000 например?

 

 

[Max P]

r2q ставится на root, например: tc qdisc add dev ${DEV} root handle 1: htb default 2 r2q 1

квантум я тупо независимо от rate на краевые классы поставил 1500 ибо езернет

 

[Max P]

кстати, в чем разница pfifo и pfifo_fast? и насколько каждый прожорлив к ресурсам?

[photon]

В мане написано. Разница в том, что pfifo_fast -- это как три очереди с pfifo и классификацией по ToS. Очевидно, что pfifo менее прожорлив.

[Max P]

почему то так и подумал :)