Miernik, I'll add a bit to Stef's answer. : When configuring HTB classes, is it true that the rate of a parent : MUST be exactly equal to the sum of rates of it's children? No. This is not true. This is merely a recommendation for how to use HTB. When the parent class ceil matches the total of all of the ceil parameters of the children classes, there is no way for bandwidth usage to exceed the parent ceil. : For example let's say I have a 160Kbit link, and two clients. I want : each of them to have equal transfer rate, and ceil each of them to : 70Kbit. I leave 5% of the link idle as suggested on : http://www.docum.org/stef.coene/qos/faq/cache/9.html I have a clarification to make, which may help you understand all of the answers to your questions: With HTB, shaping is only performed by the leaf class. Why bother setting rate and ceil in parent classes? The ceil is used by the parent class to lend bandwidth to the child classes [1]. In short, all non-leaf classes use ceil to cap how much bandwidth to lend to a child class. [ example set one snipped: A: total child rate bandwidth does not exceed parent ceil bandwidth children are configured not to borrow B: total child rate bandwidth does not exceed parent ceil bandwidth children are configured to borrow ] : Does the rate of a parent class MUST be greater or equal than the sum : of the rates of it children? No. (Note, that I assume you mean "Does the ceil of a parent..." because the parent rate is not considered at all.) : Or does it have to be exactly equal? : What happens if it is smaller? If the parent class ceil is smaller than the sum of the children ceil, then the children can consume more bandwidth than the parent class appears to allow. This occurs because the parent class is never checked! The parent class is only checked if the child has exceeded rate and wishes to borrow from the parent. : What happens if it is larger? In the case that the parent class ceil is larger than the sum of the children ceil, there is available bandwidth in the parent class. That is, a new child class could probably borrow bandwidth from the parent. [ example set two snipped A: total child rate bandwidth exceeds parent ceil bandwidth children are configured not to borrow B: total child rate bandwidth does not exceed parent ceil bandwidth total child ceil bandwidth exceeds parent ceil bandwidth children are configured to borrow ] : Are both setups equivalent now? I would disagree with Stef (note, Stef *does* have more experience with HTB, so let's see what he says). These setups are not equivalent. : Are they both valid? Valid? Yes. Advisable? No. : If they are equivalent, then is one of them somehow better? : If they are not, then why? I'd agree with Stef...setup B is probably better. : If setup B is the only valid setup, then what if I want to add 50 : clients to this link, and also give each one a ceil of 70Kbit. Each of : them will use the link rarely, so statistically there will be no more : then two clients on this link at the same time. This seems to me the most natural use and leveraging of HTB. It seems like you are adding 1 class per client. If this is so, the borrowing rules of HTB will ensure that each class has fair access to the bandwidth between sum ( rate of children ) and parent ceil. : Should I then setup for each of the clients rate 3Kbit ceil 70Kbit : : : tc qdisc add dev eth0 root handle 1: htb : tc class add dev eth0 parent 1: classid 1:1 htb rate 150Kbit ceil 150Kbit : tc class add dev eth0 parent 1:1 classid 1:2 htb rate 3Kbit ceil 70Kbit : tc class add dev eth0 parent 1:1 classid 1:3 htb rate 3Kbit ceil 70Kbit : tc class add dev eth0 parent 1:1 classid 1:4 htb rate 3Kbit ceil 70Kbit : ... and so on? Miernik--I would recommend this type of approach. In your example, though, you are using a rate which is below Devik's recommend minimum rate for reliable operation of HTB [2]. Perhaps you could create 25 classes, and put two IPs in each class. That gives you a 6kbit rate for each child class. children classes parent class # rate ceil rate ceil notes -- ---- ---- ---- ---- ---------------------------------- 2 70 70 150 150 *1 no B, p->L never exceeded 2 40 70 150 150 *2 B, p->L never exceeded 3 70 70 150 150 *3 no B, p->L might be exceeded 3 40 70 150 150 *4 B, p->L never exceeded 50 3 70 150 150 *5 B, c->R probably too low 25 6 70 150 150 *6 B, maybe good model? c=child/children class(es) p=parent class B=borrowing R=rate (in kbit) L=ceil (in kbit) *1: Because the rate of each child class is equal to the ceiling, no child class will try to borrow. The sum of the child class rates, sum( c->R ), does not exceed the parent ceiling, p->L. The total transmitted traffic should be below p->L. *2: Each child will begin to borrow from the parent when it has more than 40kbit to send. Note, also, that the sum of the child class ceil, sum ( c->L ), is still below the parent ceiling, p->L. This means that the parent class will always have more bandwidth to offer than the children will request. This means your clients would never use more than 140kbit total, leaving 10kbit of your (already conservatively estimated) 150kbit link. *3: This is a setup almost exactly like the setup in *1, but you now have three children, each of which will consume up to 70kbit (c->R = c->L). This means that if all three children are sending traffic at their configured rate, the parent ceiling will be exceeded. If you are using traffic control to prevent congestion on your uplink, this defeats your purpose. *4 is a better solution if you want to use three classes. *4: This is similar to the setup in *2. The sum of the rates of the children classes, sum( c->R ), is less than the parent's ceiling, p->L. The children will always ask to borrow from the parent when they have more than 40kbit to send. The parent class will divide bandwidth among each of the child classes as they request bandwidth. This model, where sum( c->R ) < p->L, provides the most natural use of borrowing with HTB. *5: This is almost the same model as *4. The c->R, however is very low, perhaps lower than HTB can reliably handle. Try *6. *6: A suggested alternative to *5, based on the same rules as *4. Note, also, that I have some doubt [3] about the suggestion that sum( c->R ) < p->R, because I didn't think that p->R was ever consulted for borrowing purposes. I hope the thread following my posting answers this question, and sheds some more light on the use of HTB. -Martin [1] http://www.docum.org/stef.coene/qos/faq/cache/12.html [2] http://luxik.cdi.cz/~devik/qos/htb/htbfaq.htm [3] http://mailman.ds9a.nl/pipermail/lartc/2003q2/008592.html -- Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
