tc htb sfq деление канала

Из вопроса не ясна задача, так что стоит ли делать по другому - сложно сказать.

Кроме того, если у тебя и так default 3, то незачем создавать еще и фильтры на flowid 1:3.

В принципе, ты можешь попробовать эту схему в действии, сам узнаешь, подходит ли :)

ок. потестирую...
будем надеятся, что просветление наступит...

Конечно, если бы ты сказал, что тебе действительно надо, возможно, просветление уже бы наступило.. :)

да я недавно только занялся этим поэтому у меня еще 
каша в голове.
На самом деле там схема такая:
tc qdisc add dev eth0 root handle 1: htb default 3

tc class add dev eth0 parent 1: classid 1:1 htb rate 512kbit

#gate squid 256kbit up to 512kbit
tc class add dev eth0 parent 1:1 classid 1:2 htb rate 256kbit ceil 512kbit
#other users
tc class add dev eth0 parent 1:1 classid 1:3 htb rate 256kbit ceil 512kbit

#first person
tc class add dev eth0 parent 1:3 classid 1:10 htb rate 25kbit burst 1500 ceil 256kbit
#second person
tc class add dev eth0 parent 1:3 classid 1:11 htb rate 25kbit burst 1500 ceil 256kbit
#third person
tc class add dev eth0 parent 1:3 classid 1:12 htb rate 25kbit burst 1500 ceil 256kbit
#4 person
tc class add dev eth0 parent 1:3 classid 1:13 htb rate 25kbit burst 1500 ceil 256kbit
tc class add dev eth0 parent 1:3 classid 1:14 htb rate 25kbit burst 1500 ceil 256kbit
tc class add dev eth0 parent 1:3 classid 1:15 htb rate 25kbit burst 1500 ceil 256kbit
tc class add dev eth0 parent 1:3 classid 1:16 htb rate 25kbit burst 1500 ceil 256kbit
tc class add dev eth0 parent 1:3 classid 1:17 htb rate 25kbit burst 1500 ceil 256kbit
tc class add dev eth0 parent 1:3 classid 1:18 htb rate 25kbit burst 1500 ceil 256kbit
tc class add dev eth0 parent 1:3 classid 1:19 htb rate 25kbit burst 1500 ceil 256kbit

tc qdisc add dev eth0 parent 1:2 handle 9: sfq perturb 10

tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth0 parent 1:11 handle 11: sfq perturb 10
tc qdisc add dev eth0 parent 1:12 handle 12: sfq perturb 10
tc qdisc add dev eth0 parent 1:13 handle 13: sfq perturb 10
tc qdisc add dev eth0 parent 1:14 handle 14: sfq perturb 10
tc qdisc add dev eth0 parent 1:15 handle 15: sfq perturb 10
tc qdisc add dev eth0 parent 1:16 handle 16: sfq perturb 10
tc qdisc add dev eth0 parent 1:17 handle 17: sfq perturb 10
tc qdisc add dev eth0 parent 1:18 handle 18: sfq perturb 10
tc qdisc add dev eth0 parent 1:19 handle 19: sfq perturb 10


U32="tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32"
#gate
$U32 match ip dst 192.168.1.1/32 flowid 1:2
#first person
$U32 match ip dst 192.168.1.13/32 flowid 1:10
#second person
$U32 match ip dst 192.168.1.3/32 flowid 1:11
#third person etc...
$U32 match ip dst 192.168.1.250/32 flowid 1:12
$U32 match ip dst 192.168.1.16/32 flowid 1:13
$U32 match ip dst 192.168.1.4/32 flowid 1:14
$U32 match ip dst 192.168.1.7/32 flowid 1:15
$U32 match ip dst 192.168.1.9/32 flowid 1:16
$U32 match ip dst 192.168.1.5/32 flowid 1:17
$U32 match ip dst 192.168.1.28/32 flowid 1:18
$U32 match ip dst 192.168.1.8/32 flowid 1:19

Вот. Т.е. Я хочу разделить 512kbit (это спутник там только входящий трафик). гарантированная скорость 256 отадана gate'у(1:2) плюс возможность
залезать в другую полосу. а другую 1:3 полосу я делю 
между остальными пользователями, но хочу чтобы у каждого была гарантированная полоса. Я так понимаю что в принципе можно было-бы
на 1:3 повесить sfq и он там бы сам справедливо делил между сессиями.
Но юзеры несознательные и один может 1 сессию наплодить а другой 10..
поэтому я создаю на каждого пользователя по подклассу для 1:3.
Кроме того трафик спутника анлимит, так что я позволяю юзерам залезать в полосу gate'а (1:2) тоже..

Но я больше путаюсь в направленностях канала и что мы там ограничиваем.
Вот в моем примере будет также считаться трафик с ответами(ack) на запросы пользователей, хоть они и занимают мало, но тут вопрос больше принципиальный...

ну вообщем мало rtfm'ил... буду благодарен за ответ.
а пока пойду еще почитаю...

     |
     | inet 512kbit
     |
+---------+
|  squid  |
+---------+
     |eh0 lan 100mbit
     /\  
    /  \
1:2     \
gate     |1:3
      ++++++++
      ||||||||
      ||||||||
      12345678   - юзеры 1:10 - 1:19

это картинка... к тому описанию

Ну, с виду все правильно, но..

>хочу чтобы у каждого была гарантированная полоса.

На практике ты скорее всего убедьшься в том, что подобным образом гарантировать что либо довольно сложно. Т.е. правила-то верны, но для таких скоростей как 25Кбит на пользователя будут неточности. Короче, гарантированность полосы зависит от трафика пользователей (интерсивности, кол-ва потоков, размера пакетов) и не всегда она будет действительно соответствовать приведенным выше цифрам. И тут ничё не попишешь.

>Я так понимаю что в принципе можно было-бы на 1:3 повесить sfq и он там бы сам справедливо делил между сессиями.

см. выше :) даже ESFQ не помогает иногда.

>я больше путаюсь в направленностях канала и что мы там ограничиваем.

У тебя все верно описанно, на eth0 ты ограничиваешь "входящий" для абонента трафик.

>Вот в моем примере будет также считаться трафик с ответами(ack) на запросы пользователей

Ты имеешь ввиду процедуру создания логического соединения? Не думаю, что это настолько критично, если речь идет не об использовании p2p сетей, где только этим и занимаются.. :) Можно попробовать и класс создать отдельный для мелких пакетов (<64б) или даже PRIO поцепить, она вроде более реактивная...

большое спасибо.
комментарии приняты к размышлению :-)

> Т.е. правила-то верны, но для таких скоростей как 25Кбит на пользователя будут неточности.

Вместо tc qdisc add dev eth0 root handle 1: htb default 3 исползовать tc qdisc add dev eth0 root handle 1: htb default 3 r2q 1

Не думаю, что это сильно поможет.