Hello, >> A >> / \ >> B C >> >> Class A rate and ceiling is set to something like 490kbit/sek (or >> lower) >> to move queues to my linux traffic shaper. I set equal prios, rate for >> B and C equals 8 kbit/s, ceiling for B and C equals 128 kbit/s. This >> setup is supposed to fulfill my needs. It should work as expected, >> right? > No. Why don't you take rate = ceil = 128kbit/s ?? If A uses all it > can, 128, there is still 512-128 left for the other as his mimum > bandwidth. Or do you want so say 8kilobyte ? No, 8 kilobits or 1kilobyte per second. The reason for this is that I want to have around 40-50 customer classes inside A. With guaranteed rate of 8kbit/s and ceiling of 128kbit/sek. The statistics data I have gathered leads me to a conclusion that one of every three users utilizes 33% of his bandwidth (33% of 128kbit/s), two others are idle. In pratice we can have 80-100 customers per 1Mbit and it works well if no p2p software (like Kazaa is involved). This is why I want to switch to htb and its ceiling feature. Customers pay relatively low rates and thanks to current cbq setup receive relatively good service. Anyway, we have customers using 128/128(rate/ceiling) which pay 8 times more. >> A >> / \ >> B C >> /|\ /|\ >> D E F G H I >> >> D,G rate=4/ceil=64 >> E,H rate=3/ceil=128 >> F,I rate=1/ceil=32 >> >> Priorities for all classes are the same. >> >> Lets assume all classes try to send at their maximum speed trying to >> saturate the link. According to what you have written class D will get >> 64kbit/s, class E 128kbit/s and class F will get 32kbit/s. The sum is >> 224kbit/s if I am correct. Am I right? > Yes. So the rate of the parent B must also be at least 224kbit/s. And > not 8kbis/s like you wrote before. I understand but... I still want to limit customer B to 128 kbit/s. And guarantee them 8kbit/s. > >> I dont want it to happen since customers have paid for 128kbit/s with >> guaranteed rato of 8kbit/s. Is there a way to acomplish my task???. >> Can it be done using HTB only? > Yes, make the sum of D,E and F = 128kbit/s. Let's say I give D bandwidth of 32 kbit/s, E bandwidth od 64 kbit/s and F bandwidth 32 kbit/s. When every classes are idle ond only E attempte to transmit at maximum speed, it will be given 64kbit/sek not 128kbit/s:(. Customers will not be happy, because in current setup they can reach 128kbit/s (and thanks to cbq inaccuracies even more - around 155kbit/s). > >> >> >Remaining bandwidth inside class B is distributed first to class >> D, >> >> >> >> then E and then F and is limited by ceiling parameter . Right??? >> >> yes, what you have said is right. >> > >> > Confirmed. Lowest prio classes are allowed to send first. >> >> It is intuitive. Thanks for confirmation. Anyway, classes D,E,F are >> limited only by their ceil, not by ceil of class B. Hm?. Performance >> reasons, right? > I have some rules on the faq page on www.docum.org regarding the rate > and ceil of parent and child classes. If you follow these rules, it > will be easier to understand how each class will behave. I have read it. In simple cases I totaly agree. But there must be something missing (or I am totally wrong:) ). Or the setup I require is not possible to create. >> > Nor the rate, nor the ceil are respected if the child class can >> send. So if B end C can send the remaining bandwidth, they will. >> Even if the parent ceil is not permitting it. >> >> Well... I hoped for opposite. If the ceiling of parent class is not >> respected, then setting htb up the way I require is rather >> impossible.? Right:( ? > No. You have to see the rate as a minimum bandwidth and also like a > "proportion". I mean if you have a class with child rate = 10 and an > other child class with rate = 30, the first class will get 25% of the > bandwidth. So the real value of rate doesn't mather. I think exactly the way you described. I see rate the same way you do. Unfotunetaly this leads me to a conclusion that htb has serious drawbacks. If the ceiling of the parent is not respected then it is impossible to create setup I require. In this case it is also not necesary to create parent classes. I hardly belive that. I must omit something important. There follows interesting quote from http://luxik.cdi.cz/~devik/qos/htb/old/develnotes.htm "Lower levels are completely dequeueued before borrowing from higher levels.". So is it possible that prio and rate and ceiling of parent class matters? And teator of htb qdisc often uses term of borrowing bandwidth from parent...... >> >> >What if C and B have different rates? >> >> >Is prio parameter taken into account when htb tries to meet >> >> guaranteed rate rules? >> >> >> >> I think the "prio" parameter is only used after all classes have >> >> reached their guaranteed minimum rate, to allow the user to create >> classes that will borrow bandwidth over other classes. >> > >> > Yep. >> >> OK. You have cleared thing up:) > I think there is a page on the htb homepage that state that only prio of > leaf classes are used. In fact if you have a htb setup, and you asks > the setup, the prio of non-leaf classes isn't even shown. On the other > hand, I did some small tests and the prio parameter seems to be > important. I really have to do some tests ..... Yes, I will try to do some research on my own, too. Anyway, I would like to read your opinions Stef about my doubts. I think this thread can be useful to many people. Robert Kryczało
