С многопоточными качалками как раз все сложно, потому что они берут потоками.. вот могу процитировать "повесть о линукс и управлении трафиком":

А так как ESFQ в ядре нет (надо патчить), но оказывается есть какой то аналог-внешний классификатор для SFQ под именем SFQ flow classifier, то погуглите на эту тему.

Кажется все у вас нормально написано, правда несколько запутанно, но вроде как надо, кроме этого участка:

/sbin/tc class add dev eth1 parent 1:2 classid 1:20 htb rate 100kbps ceil 100kbps
/sbin/tc class add dev eth1 parent 1:20 classid 1:30 htb rate 95kbps ceil 95kbps
/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 10.10.7.0/255.255.255.224 classid 1:30
/sbin/tc class add dev eth1 parent 1:2 classid 1:30 htb rate 10kbps ceil 9000kbps
Тут как я понимаю создается класс 1:20 и его потомок (который является умолчальным) 1:30.. а смысл этого делать? можно написать в 1:20 rate 95kbps ceil 100kbps.. и фильтром отправлять нужные пакеты в 1:20.. мне в общем видится лишний класс.. Кроме того - вы два рада определяете класс 1:30, только с разными родителями, но суть не меняется: класс определен два раза, и работать будет, очевидно, только последний (или я чего-то не знаю? =)

Еще рекомендуется на концы htb классов вешать бесклассовую дисциплину sfq, например так:tc class add dev $IN_DEV parent 1:1 classid 1:13 htb rate 64kbit ceil 64kbit prio 3
tc qdisc add dev $IN_DEV parent 1:13 handle 13: sfq perturb 10Но она, как уже писали, не сильно то помогает при многопоточных закачках, остается читать про новый SFQ flow classifier, которым был призван заменить собой esfq (для использования которого надо патчить tc и ядро)..

И еще, приоритеты не расставляете? Незнаю насколько это важно, но логичнее было бы обрабатывать вперед пользователей, которые имеют маленькую скорость, все таки они и так страдают больше всех =) и можете оформить шейпер в скрипт, который будет выглядеть примерно так, так оно и читается удобнее и ошибки искать проще, хотя это уже конечно мелочи.. Надеюсь, что я тут написал что-то полезное.. =)

Блин.. не туда ответ вставил нечаянно, сам на свой ответил.. (((

Кстати, странно, что вы пишете 95Кбит, а в шейпере у вас rate 97mbit ceil 97mbit.. к тому же дальше видно что опять же rate 100kbps ceil 100kbps.. это неправильно, у вас весь канал съест первый же, кто попадет под правило.. что такое rate & ceil знаете? Вы датете гарантированную полосу и тут же она у вас равна максималньо доступной.. Если есть интерес, опишите схему как хотите поделить, а я завтра вам шейпер нарисую простой.. часов этак через 10-11.. как на работе буду работу делать =)

ТЬфу, кажется я все перепутал, простите, завтра уже на свежую голову гляну.. пардон.. =)

жду свежую голову :) В двух словах, локалка на фул спиде- 100мбит поэтому вот такие правила.

Уже понял.. сейчас посмотрю более внимательно.. =)

Ответ выше, не туда закомментил.. что-то у меня с этим проблемы..

чтение про новый SFQ flow classifier мне ничего пока не дало сейчас подкорректирую и выложу, то что выйдет. Останется вопрос только с SFQ flow classifer.

Получилось вот так
# корневая дисциплина
/sbin/tc qdisc del dev eth1 root
/sbin/tc qdisc add dev eth1 root handle 1 htb default 30 r2q 6

/sbin/tc class add dev eth1 parent 1: classid 1:2 htb rate 100mbit
# локалка
/sbin/tc class add dev eth1 parent 1:2 classid 1:10 htb rate 97mbit ceil 97mbit
/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip src 10.10.7.1/255.255.255.224 classid 1:10
/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip src 192.168.1.0/255.255.255.0 classid 1:10
# инет
/sbin/tc class add dev eth1 parent 1:2 classid 1:20 htb rate 100kbps ceil 100kbps
/sbin/tc qdisc add dev eth1 parent 1:20 handle 20 sfq perturb 10
/sbin/tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 10.10.7.0/255.255.255.224 classid 1:20

/sbin/tc class add dev eth1 parent 1:2 classid 1:30 htb rate 10kbps ceil 9000kbps

Все вроде правильно.. а насчет sfq flow classifier я сам ни разу не пробовал использовать его, даже до тестов руки не дошли, мало информации по нему, но вот что я пока нашел, может быть вам пригодится: http://lwn.net/Articles/236200/ и вот человек заменял ранее использовавшуюся sfq. Честно говоря самому интересно бы разобраться в этом вопросе, но пока некогда, если бы вы разобрались и отписались было бы круто =)

Это я тоже находил, но что-то не доганяю как это сделать. Тем более в самом вразумительном посте цитата "No. I still use ESFQ." наталкивает на мысль что ничего у него не вышло.

Жаль что документации и особенно на русском по этому делу мало..

Еще например человек делал так: tc qdisc add dev eth1 parent 1:7 handle 10: sfq perturb 10
tc filter add dev eth1 protocol ip parent 10: handle 2 flow hash keys src,dst divisor 1024

И опять дополню, вот еще интересный тред и посмотрите что говорит man tc-drr.

добавил такую штуку
tc filter add dev eth1 parent 1: protocol ip handle 20 flow hash keys dst divisor 32

ядро скушало, но как проверить работу не знаю.

Попросить пользователей врубить торрент-качалки и смотреть статус сколько чего дропнуло..

факир был пьян и фокус не удался. Ничего из этого не вышло.

тут инфа более актуальная:
Наложение патчей IMQ, ESFQ и Layer7

но менее применима для "боевых условий". Хотелось бы обойтись без патчей, а методом sfq flow classifier Может кто сталкивался?

тут есть моё поделие:
WonderShaper

меня устраивает.
торенты качает сервак и я. канала делится поровну.
плюс параллельно хожу по страничкам.