Re: Is this possible?

Linux Advanced Routing and Traffic Control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

[Index of Archives]     [LARTC Home Page]     [Netfilter]     [Netfilter Development]     [Network Development]     [Bugtraq]     [GCC Help]     [Yosemite News]     [Linux Kernel]     [Fedora Users]
  Powered by Linux