On Mon, 2006-03-06 at 02:19 +0100, Andreas Klauer wrote: > > The revised class structure is now: > > > > htb class parent 1: classid 1:10 rate 80% ceil 100% > > htb class parent 1:10 classid 1:11 rate 100% ceil 100% > > htb class parent 1:11 classid 1:19 rate 30% ceil 100% prio 0 [VOIP leaf] > > htb class parent 1:10 classid 1:20 rate 70% ceil 100% > > htb class parent 1:20 classid 1:21 rate 20% ceil 100% prio 1 > > [interactive leaf] > > htb class parent 1:20 classid 1:22 rate 50% ceil 100% prio 2 [other leaf] > > Interesting analysis, although it kind of defies my HTB logic > (which is just an inaccurate model). If the 1:10 class is > limited to the rate as you said above (which would be 80%), > how can a child class have a rate of 100%?
I got the idea from the FAQ, section titled "What if sum of child rates is greater than parent rate?": http://luxik.cdi.cz/~devik/qos/htb/htbfaq.htm What he says happens in there does agree with the "Theory of Operation" document - but you would have to be smarter than I apparently am to infer it from just reading the "Theory of Operation". Anyway, after reading "Theory of Operation", you can restate how HTB works in fairly simple terms. Lets say you have a node with a assured rate (ie "rate") of X%, and its owns a packet that is queued to go. Then one of three things happen: a. If the current traffic flow through this node and its children is over the nodes ceiling, the packet is not sent. b. If the current traffic flow through this node is less than the nodes N% assured rate the packet is transmitted. This happens unconditionally - regardless of what the parents rates might be. Thus lets say you set up a hierarchy with rates like this: 100% / \ 60% 60% If both nodes are sending as fast as they can go, then they will use 120% of the link capacity, regardless of that fact that the parent is at 100%. This presumably would be an error. c. If the current traffic flow this node is over the N% assured rate, then this node will flatly refuse to send packet. Instead it passes it onto its parent to deal with. The parent now "owns" the packet, and thus goes through these exact same three steps. So if the parent is also over its assured rate, it will give the packet to its parent. This is how the packet works its way up the hierarchy. So the packet passes up the tree, from node to node, until it can find a node that will send it. As time goes on a packets ownership may go back down the tree, towards the leaf that generated it. This happens because as time passes, nodes will go back under their assured rate. If there are lots of packets in the queue, this means there could be several nodes in the tree all holding up their hands saying "I have a packet ready to send". HTB has to choose between them. There are three cases: a. Packets that are owned by nodes at the bottom of the tree get first priority. Thus the leaves get to send their packets first. Only if no leaves have packets to send does the next layer of nodes even get considered. Thus packets owned by the root have the lowest priority of all. b. Even after (a), we could have several nodes at the same level all with packets ready to send. HTB chooses between them based on the prio field. The nodes with the lowest prio field wins, and gets to send before everybody else. c. But .. there could be several nodes with the same prio, at the same level in the tree, all with packets to send. The nodes are then processed in a round robin fashion - ie HTB cycles around them, servicing each in turn. Somewhere in all this the quantum raises its ugly head. I avoided having to think about that by making all my quantum's the same. The quantum effects how a parent node allocates bandwidth to the over-rate children that want to borrow from someone else. The parent allocates the excess bandwidth to the children according to their quantum. The higher a child quantum, the more of the excess bandwidth the parent allocates it. Thus if all children have the same quantum, they each get the same share of the excess bandwidth. If there where three over-rate children whose quantums were - A:3000 B:1500 C:1500, then A would get 50% of the excess bandwidth: 50% = 3000 / (3000+1500+1500) and B & C would get 25% each: 25% = 1500 / (3000+1500+1500) Notice the quantum only effects nodes that are trying to send over their assured rate, and thus have to borrow from their parent. If they are not borrowing they are not effected. > I still don't understand what to make of a root class with > different rate / ceil settings. It's either limited to rate, > or to ceil all the time; if it isn't, it decides to jump > over it's rate under which circumstances? A node will only send a packet if the collective flow of the node and its children is less than the nodes assured rate (ie the "rate" parameter). If the flow is above that figure the node will never send the packet, but its ancestors may. The root doesn't have any ancestors, so the packet won't be sent if the its assured rate is exceeded. Making the roots ceil equal to assured rate would make what is happening clearer, but doesn't alter the behaviour in any way. As it happens the classes I actually use are a bit more complicated that I have shown here. The scripts that create them are automatically generated. The code that did the generating was easier to write when all ceil's were 100% - which is why I presented it that way. _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
