1HTB(8)                               Linux                              HTB(8)
2
3
4

NAME

6       HTB - Hierarchy Token Bucket
7

SYNOPSIS

9       tc  qdisc  ... dev dev ( parent classid | root) [ handle major: ] htb [
10       default minor-id ]
11
12       tc class ... dev dev parent major:[minor] [ classid major:minor  ]  htb
13       rate rate [ ceil rate ] burst bytes [ cburst bytes ] [ prio priority ]
14
15

DESCRIPTION

17       HTB is meant as a more understandable and intuitive replacement for the
18       CBQ qdisc in Linux. Both CBQ and HTB help you to control the use of the
19       outbound  bandwidth on a given link. Both allow you to use one physical
20       link to simulate several slower links and to send  different  kinds  of
21       traffic  on different simulated links. In both cases, you have to spec‐
22       ify how to divide the physical link into simulated  links  and  how  to
23       decide which simulated link to use for a given packet to be sent.
24
25       Unlike  CBQ,  HTB shapes traffic based on the Token Bucket Filter algo‐
26       rithm which does not depend on interface characteristics  and  so  does
27       not need to know the underlying bandwidth of the outgoing interface.
28
29

SHAPING ALGORITHM

31       Shaping works as documented in tc-tbf (8).
32
33

CLASSIFICATION

35       Within  the  one  HRB  instance  many  classes may exist. Each of these
36       classes contains another qdisc, by default tc-pfifo(8).
37
38       When enqueueing a packet, HTB starts at the root and uses various meth‐
39       ods to determine which class should receive the data.
40
41       In the absence of uncommon configuration options, the process is rather
42       easy.  At each node we look for an instruction,  and  then  go  to  the
43       class  the  instruction  refers  us  to. If the class found is a barren
44       leaf-node (without children), we enqueue the packet there. If it is not
45       yet  a  leaf  node, we do the whole thing over again starting from that
46       node.
47
48       The following actions are performed, in order at each  node  we  visit,
49       until one sends us to another node, or terminates the process.
50
51       (i)    Consult filters attached to the class. If sent to a leafnode, we
52              are done.  Otherwise, restart.
53
54       (ii)   If none of the above returned with an  instruction,  enqueue  at
55              this node.
56
57       This  algorithm makes sure that a packet always ends up somewhere, even
58       while you are busy building your configuration.
59
60
62       FIXME
63
64

QDISC

66       The root of a HTB qdisc class tree has the following parameters:
67
68
69       parent major:minor | root
70              This  mandatory  parameter  determines  the  place  of  the  HTB
71              instance, either at the root of an interface or within an exist‐
72              ing class.
73
74       handle major:
75              Like all other qdiscs, the HTB can be assigned a handle.  Should
76              consist  only  of a major number, followed by a colon. Optional,
77              but very useful if classes will be generated within this qdisc.
78
79       default minor-id
80              Unclassified traffic gets sent to the class with this minor-id.
81
82

CLASSES

84       Classes have a host of parameters to configure their operation.
85
86
87       parent major:minor
88              Place of this class within the hierarchy. If  attached  directly
89              to  a  qdisc  and  not  to  another class, minor can be omitted.
90              Mandatory.
91
92       classid major:minor
93              Like qdiscs, classes can be named.  The  major  number  must  be
94              equal  to  the  major  number  of the qdisc to which it belongs.
95              Optional, but needed if this class is going to have children.
96
97       prio priority
98              In the round-robin process, classes  with  the  lowest  priority
99              field are tried for packets first. Mandatory.
100
101
102       rate rate
103              Maximum  rate  this  class  and all its children are guaranteed.
104              Mandatory.
105
106
107       ceil rate
108              Maximum rate at which a class can send, if its parent has  band‐
109              width  to spare.  Defaults to the configured rate, which implies
110              no borrowing
111
112
113       burst bytes
114              Amount of bytes that can be burst at ceil speed,  in  excess  of
115              the  configured rate.  Should be at least as high as the highest
116              burst of all children.
117
118
119       cburst bytes
120              Amount of bytes that can be burst at 'infinite' speed, in  other
121              words,  as  fast as the interface can transmit them. For perfect
122              evening out, should be equal to  at  most  one  average  packet.
123              Should  be  at  least as high as the highest cburst of all chil‐
124              dren.
125
126

NOTES

128       Due to Unix timing constraints, the maximum ceil rate is  not  infinite
129       and  may in fact be quite low. On Intel, there are 100 timer events per
130       second, the maximum rate is that rate at which 'burst' bytes  are  sent
131       each  timer  tick.   From  this, the mininum burst size for a specified
132       rate can be calculated. For i386, a 10mbit rate requires a 12  kilobyte
133       burst as 100*12kb*8 equals 10mbit.
134
135

SEE ALSO

137       tc(8)
138
139       HTB website: http://luxik.cdi.cz/~devik/qos/htb/
140

AUTHOR

142       Martin  Devera  <devik@cdi.cz>.  This manpage maintained by bert hubert
143       <ahu@ds9a.nl>
144
145
146
147
148
149iproute2                        10 January 2002                         HTB(8)
Impressum