| .TH HTB 8 "10 January 2002" "iproute2" "Linux" |
| .SH NAME |
| HTB \- Hierarchy Token Bucket |
| .SH SYNOPSIS |
| .B tc qdisc ... dev |
| dev |
| .B ( parent |
| classid |
| .B | root) [ handle |
| major: |
| .B ] htb [ default |
| minor-id |
| .B ] |
| |
| .B tc class ... dev |
| dev |
| .B parent |
| major:[minor] |
| .B [ classid |
| major:minor |
| .B ] htb rate |
| rate |
| .B [ ceil |
| rate |
| .B ] burst |
| bytes |
| .B [ cburst |
| bytes |
| .B ] [ prio |
| priority |
| .B ] |
| |
| .SH DESCRIPTION |
| HTB is meant as a more understandable and intuitive replacement for |
| the CBQ qdisc in Linux. Both CBQ and HTB help you to control the use |
| of the outbound bandwidth on a given link. Both allow you to use one |
| physical link to simulate several slower links and to send different |
| kinds of traffic on different simulated links. In both cases, you have |
| to specify how to divide the physical link into simulated links and |
| how to decide which simulated link to use for a given packet to be sent. |
| |
| Unlike CBQ, HTB shapes traffic based on the Token Bucket Filter algorithm |
| which does not depend on interface characteristics and so does not need to |
| know the underlying bandwidth of the outgoing interface. |
| |
| .SH SHAPING ALGORITHM |
| Shaping works as documented in |
| .B tc-tbf (8). |
| |
| .SH CLASSIFICATION |
| Within the one HRB instance many classes may exist. Each of these classes |
| contains another qdisc, by default |
| .BR tc-pfifo (8). |
| |
| When enqueueing a packet, HTB starts at the root and uses various methods to |
| determine which class should receive the data. |
| |
| In the absence of uncommon configuration options, the process is rather easy. |
| At each node we look for an instruction, and then go to the class the |
| instruction refers us to. If the class found is a barren leaf-node (without |
| children), we enqueue the packet there. If it is not yet a leaf node, we do |
| the whole thing over again starting from that node. |
| |
| The following actions are performed, in order at each node we visit, until one |
| sends us to another node, or terminates the process. |
| .TP |
| (i) |
| Consult filters attached to the class. If sent to a leafnode, we are done. |
| Otherwise, restart. |
| .TP |
| (ii) |
| If none of the above returned with an instruction, enqueue at this node. |
| .P |
| This algorithm makes sure that a packet always ends up somewhere, even while |
| you are busy building your configuration. |
| |
| .SH LINK SHARING ALGORITHM |
| FIXME |
| |
| .SH QDISC |
| The root of a HTB qdisc class tree has the following parameters: |
| |
| .TP |
| parent major:minor | root |
| This mandatory parameter determines the place of the HTB instance, either at the |
| .B root |
| of an interface or within an existing class. |
| .TP |
| handle major: |
| Like all other qdiscs, the HTB can be assigned a handle. Should consist only |
| of a major number, followed by a colon. Optional, but very useful if classes |
| will be generated within this qdisc. |
| .TP |
| default minor-id |
| Unclassified traffic gets sent to the class with this minor-id. |
| |
| .SH CLASSES |
| Classes have a host of parameters to configure their operation. |
| |
| .TP |
| parent major:minor |
| Place of this class within the hierarchy. If attached directly to a qdisc |
| and not to another class, minor can be omitted. Mandatory. |
| .TP |
| classid major:minor |
| Like qdiscs, classes can be named. The major number must be equal to the |
| major number of the qdisc to which it belongs. Optional, but needed if this |
| class is going to have children. |
| .TP |
| prio priority |
| In the round-robin process, classes with the lowest priority field are tried |
| for packets first. Mandatory. |
| |
| .TP |
| rate rate |
| Maximum rate this class and all its children are guaranteed. Mandatory. |
| |
| .TP |
| ceil rate |
| Maximum rate at which a class can send, if its parent has bandwidth to spare. |
| Defaults to the configured rate, which implies no borrowing |
| |
| .TP |
| burst bytes |
| Amount of bytes that can be burst at |
| .B ceil |
| speed, in excess of the configured |
| .B rate. |
| Should be at least as high as the highest burst of all children. |
| |
| .TP |
| cburst bytes |
| Amount of bytes that can be burst at 'infinite' speed, in other words, as fast |
| as the interface can transmit them. For perfect evening out, should be equal to at most one average |
| packet. Should be at least as high as the highest cburst of all children. |
| |
| .SH NOTES |
| Due to Unix timing constraints, the maximum ceil rate is not infinite and may in fact be quite low. On Intel, |
| there are 100 timer events per second, the maximum rate is that rate at which 'burst' bytes are sent each timer tick. |
| From this, the minimum burst size for a specified rate can be calculated. For i386, a 10mbit rate requires a 12 kilobyte |
| burst as 100*12kb*8 equals 10mbit. |
| |
| .SH SEE ALSO |
| .BR tc (8) |
| .P |
| HTB website: http://luxik.cdi.cz/~devik/qos/htb/ |
| .SH AUTHOR |
| Martin Devera <devik@cdi.cz>. This manpage maintained by bert hubert <ahu@ds9a.nl> |
| |
| |