> > 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:)
Quantum is used when 2 or more classes are fighting for remaining bandwidth
from the same parent. Each class may send quantum bytes at a turn. So if
you have 1 class with quantum = 100 and an other with quantum = 900, you
should expect that the first class gets 10% and the second 90%. But if the
packet size is 1000 byte, each class can send the same amount of traffic.
Basically, nothing bad will hapenn, but it will less obviously to find out
what's going on.
And I think it's save to upgrade to the latest htb.
> 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. ".
But is this also for classes with childs? I'm not sure. I mailed Devik about
it, and I will forward you his answer.
> Now, thanks to your advices and www.docum.org's docs I am able to predict
> htb behaviour. Thanx Stef:)
No problem.
> >> 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.
I tested it, they can.
> BTW. Those scripts from www.docum.org are very nice.
Thx.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
