htb и ограничение высоких скоростей

[OVN]

На AS-сервере Linux на пользовательских ppp интерфейсах для ограничения по полосе пропускания с помощью tc и дисциплины HTB настроен shaper. Работает нормально только на относительно низких скоростях, т.е. до 1 Мбит/с, все что выше начинает врать, причем чем выше поднимаешь ограничение - тем больше врет. На 20 мбит/с выдает реально менее 3 Мбит/с. Собственно вопрос - в чем может быть проблема, кто-нибудь юзал htb на высоких скоростях?

 

PS: ядро: 2.4.34, на tc class show выдает все как положено.

Edited January 20, 2007 by OVN

[Kirya]

У нас в продакшине стоят ограничения до 5 мбит.

Чтоб врало, не замечали.

Правда стоит отметить мы режем скорости на IMQ и ядро у нас 2.6.17.

[nuclearcat]

У меня тоже режет 65Mbit точно, по классам с шарингом

ядро 2.6.18.3

[Oleg_S]

2.6.xx

htb работает как положено

диапазон от 64Кбит/с до 50-ти Мбит/с.

[OVN]

Т.е. ничего особенного не делали? Куда рыть не подскажите?

tc qdisc add dev $DEV handle 1:0 root dsmark indices 4 default_index 0
tc qdisc add dev $DEV handle 2:0 parent 1:0 htb
tc class add dev $DEV parent 2:0 classid 2:1 htb rate 2625000bps ceil 2625000bps
tc class add dev $DEV parent 2:1 classid 2:2 htb rate 48000bps ceil 50000bps
tc qdisc add dev $DEV handle 3:0 parent 2:2 sfq
tc class add dev $DEV parent 2:1 classid 2:3 htb rate 2500000bps ceil 2625000bps
tc qdisc add dev $DEV handle 4:0 parent 2:3 sfq
tc filter add dev $DEV parent 2:0 protocol all prio 1 tcindex mask 0x3 shift 0
tc filter add dev $DEV parent 2:0 protocol all prio 1 handle 2 tcindex classid 2:2
tc filter add dev $DEV parent 2:0 protocol all prio 1 handle 1 tcindex classid 2:3
tc filter add dev $DEV parent 1:0 protocol all prio 1 u32 match u32 0xac110000 0xffff0000 at 12 classid 1:1
tc filter add dev $DEV parent 1:0 protocol all prio 1 u32 match u32 0x0 0x0 at 0 classid 1:2

[desperado]

где-то инфа была что буфер надо расширять.

[nuclearcat]

Я никогда не делал цепочку такую, особенно с dsmark

Обычно все просто - root - htb, и потом пошли ветки

[OVN]

где-то инфа была что буфер надо расширять.

Буфер чего и как?

 

Я никогда не делал цепочку такую, особенно с dsmark

Обычно все просто - root - htb, и потом пошли ветки

Пример в студию, плиз!!! :)

[nuclearcat]

tc qdisc del dev eth1 root

 

tc qdisc add dev eth1 root handle 1: htb default 2000

# ROOT

tc class add dev eth1 parent 1: classid 1:100 htb rate 64500kbit quantum 32000

 

# HIGHEST PRIO (SMALL CIR)

tc class add dev eth1 parent 1:100 classid 1:140 htb rate 512kbit ceil 64500kbit quantum 32000

tc qdisc add dev eth1 parent 1:140 handle 140: bfifo limit 100000

 

# High PRIO

tc class add dev eth1 parent 1:100 classid 1:110 htb rate 40500kbit ceil 64500kbit quantum 32000

tc qdisc add dev eth1 parent 1:110 handle 110: bfifo limit 1000000

 

# Corporate

tc class add dev eth1 parent 1:100 classid 1:111 htb rate 3400kbit ceil 64500kbit quantum 32000

tc qdisc add dev eth1 parent 1:111 handle 111: bfifo limit 100000

 

tc filter add dev eth1 parent 1:0 prio 10 protocol ip u32 match ip src X.X.X.X/32 match ip protocol 17 0xff match ip sport 3000 0xffff classid 1:110

 

И т.п.

Ессно могут быть еще "дети" и более сложное дерево, но весь шейпер (здесь клиентов нет) - 12 кб, лениво запихивать сюда

 

Класс 2000 - существовать не должен(если его заюзать - начинаются баги, не выяснял почему, траффик идет, потом стопорится на неск секунд и т.п.), но должен быть дефолтовый класс такой конструкции:

 

# Low PRIO (JUNK BW)

tc class add dev eth1 parent 1:100 classid 1:131 htb rate 2000kbit ceil 64500kbit quantum 32000 prio 2

tc qdisc add dev eth1 parent 1:131 handle 131: sfq perturb 10

 

tc filter add dev eth1 parent 1:0 prio 100 protocol ip u32 match ip dst 0.0.0.0/0 classid 1:131

(обратить внимание на prio)

[OVN]

Спасибо, буду пробовать.