This commit was manufactured by cvs2svn to create branch
[iproute2.git] / tc-htb.8
diff --git a/tc-htb.8 b/tc-htb.8
new file mode 100644 (file)
index 0000000..f61b818
--- /dev/null
+++ b/tc-htb.8
@@ -0,0 +1,150 @@
+.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 mininum 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>
+
+