>Hi, Hello, > > I have 1 big remark. You results are incorrect and not usable. The > quantum of your class is too low. You have a rate of 1kbit, so quantum > is 1kbit / 10 = 100 bit. In your case, quantum is important. Each > class may send quantum bytes to use all remaining bandwidth from the > parent. Let's say class 21 and 22 are fighting for bandwidth. The > qauntums are 400 and 300. So class 21 may send 400bit and after that > class 22 may send 300bit. But most packets are 1500byte !!! So 1500 > byte is sended. So the internal calulations of htb are totally fucked > up (sorry for the language :). They are broken, indeed:). > > If you want to get some good results, use at minimum a rate of 15kbit or > change the r2q parameter. If you are curious about the qauntum > parameter, I have some more info on www.docum.org on the faq page. That's correct. I set up r2q to 1 and for rates of 12kbit/s quantum is bigger than 1500 bytes. Do you have any idea what happens if I set up very small rates like 1kbit/s or 0.01kbit/s=1bps :) and quantum=1500? Is htb precise in such situations. Is it equal to setting rate to 12kbit and quantum to 1500.Unfortunatelly, I am unable to set quantums in my version of htb and do some empirical tests. (It some early version of htb3 - patch against kernel 2.4.18 - it is extremely stable for me so I am not going to change it.). I want to create guarantees at certain level of a htb tree, so I am interested in rates close to zero:). Of course if I have many customers, it is not so important... I'm just curious:) > > I redid some of your test with higher rates. I multiplied the rates > with 16 (so kbit -> kpbs and x2). And I added r2q = 1 so lowest > quantum is 2000bytes. > > And I toke a wrong conclusion. The parent ceil is not respected IF the > sum of the rates of childs exceed the parent ceil. So if you have 2 > childs classes with rate = 100 and a parent ceil of 100, the parent > ceil is not respected and the childs will get each 100. But if you > have 2 class with rate = 2 and parent ceil = 100, then the childs to > gether will never get more then 100. So the parent ceil is respected. Your statement is absolutelly correct. > > Traffic in class 21 : 127.5 KB/s > Traffic in class 22 : 256.1 KB/s > Traffic in class 21 and 22 : 120.4 KB/s and 137.7 KB/s > so the parent ceil is respected. But I still don't know how the > traffic is > divided. The sum is 258.1 so class 21 gets 46.6%. I think each class > gets the configured rate and the remaining traffic is splitted 50-50. My others tests shows that each leaf class gets the configured rate (even if rates are overbooked - then parent ceil is not respected). Then rate of parent is divided beetween children according to quantums - so it is not equally distributed. And then children borrow free bandwidth from parents who borrow from grandparents etc... borrowing is proportional to quantums. The difference is visible only if rates difference is significant. In case rates are the same every children gets the same share. I found this in hbt manual: "You should see that if several classes are competing for parent's bandwidth then they get it in proportion of their quantums. It is important to know that for precise operation quantums need to be as small as possible and larger than MTU. ". Now, thanks to your advices and www.docum.org's docs I am able to predict htb behaviour. Thanx Stef:) > >> During the tests I discovered that in case of root class (1:0 in my >> example) only rate matters not ceil. I accidentally changed 1:2 and >> 1:3 to root classes and then 22,23,24 were limited to 8kbit/s. > I did the same. And indeed. For a root class, ceil = rate even if you > specify a higher ceil. Strange. On the other hand, it's logic to > create 1 root class that holds all traffic so it has rate = ceil. It's > the "bottleneck" within the htb structure. That's correct. Multiple root classes inside htb qdisc can be used to simulate "circuits". Those circuits cannot borrow from each other. It can be useful sometimes. I just have to check if root class can go over rate in case sum of its children rates exceeds root class rate. BTW. Those scripts from www.docum.org are very nice. Robert Kryczało
