~ubuntu-branches/ubuntu/karmic/iproute/karmic

« back to all changes in this revision

Viewing changes to debian/manpages/tc-htb.8

  • Committer: Bazaar Package Importer
  • Author(s): Joshua Kwan
  • Date: 2004-05-16 20:28:43 UTC
  • Revision ID: james.westby@ubuntu.com-20040516202843-kvaahy5s8mmstjid
Tags: 20010824-13.1
* NMU for a security fix.
* [CAN-2003-0856] Fix a local denial of service vulnerability via
  spoofed messages to the kernel's Netlink interface. (Closes: #242994)

Show diffs side-by-side

added added

removed removed

Lines of Context:
 
1
.TH HTB 8 "10 January 2002" "iproute2" "Linux"
 
2
.SH NAME
 
3
HTB \- Hierarchy Token Bucket
 
4
.SH SYNOPSIS
 
5
.B tc qdisc ... dev
 
6
dev
 
7
.B  ( parent
 
8
classid 
 
9
.B | root) [ handle 
 
10
major: 
 
11
.B ] htb [ default 
 
12
minor-id
 
13
.B ] 
 
14
 
 
15
.B tc class ... dev
 
16
dev
 
17
.B parent 
 
18
major:[minor]
 
19
.B [ classid 
 
20
major:minor
 
21
.B ] htb rate
 
22
rate
 
23
.B [ ceil
 
24
rate 
 
25
.B ] burst 
 
26
bytes
 
27
.B [ cburst
 
28
bytes
 
29
.B ] [ prio
 
30
priority
 
31
.B ] 
 
32
 
 
33
.SH DESCRIPTION
 
34
HTB is meant as a more understandable and intuitive replacement for
 
35
the CBQ qdisc in Linux. Both CBQ and HTB help you to control the use
 
36
of the outbound bandwidth on a given link. Both allow you to use one
 
37
physical link to simulate several slower links and to send different
 
38
kinds of traffic on different simulated links. In both cases, you have
 
39
to specify how to divide the physical link into simulated links and
 
40
how to decide which simulated link to use for a given packet to be sent. 
 
41
 
 
42
Unlike CBQ, HTB shapes traffic based on the Token Bucket Filter algorithm 
 
43
which does not depend on interface characteristics and so does not need to
 
44
know the underlying bandwidth of the outgoing interface.
 
45
 
 
46
.SH SHAPING ALGORITHM
 
47
Shaping works as documented in
 
48
.B tc-tbf (8).
 
49
 
 
50
.SH CLASSIFICATION
 
51
Within the one HRB instance many classes may exist. Each of these classes
 
52
contains another qdisc, by default 
 
53
.BR tc-pfifo (8).
 
54
 
 
55
When enqueueing a packet, HTB starts at the root and uses various methods to 
 
56
determine which class should receive the data. 
 
57
 
 
58
In the absence of uncommon configuration options, the process is rather easy. 
 
59
At each node we look for an instruction, and then go to the class the 
 
60
instruction refers us to. If the class found is a barren leaf-node (without 
 
61
children), we enqueue the packet there. If it is not yet a leaf node, we do 
 
62
the whole thing over again starting from that node. 
 
63
 
 
64
The following actions are performed, in order at each node we visit, until one 
 
65
sends us to another node, or terminates the process.
 
66
.TP
 
67
(i)
 
68
Consult filters attached to the class. If sent to a leafnode, we are done. 
 
69
Otherwise, restart.
 
70
.TP
 
71
(ii)
 
72
If none of the above returned with an instruction, enqueue at this node.
 
73
.P
 
74
This algorithm makes sure that a packet always ends up somewhere, even while
 
75
you are busy building your configuration. 
 
76
 
 
77
.SH LINK SHARING ALGORITHM
 
78
FIXME
 
79
 
 
80
.SH QDISC
 
81
The root of a HTB qdisc class tree has the following parameters:
 
82
 
 
83
.TP 
 
84
parent major:minor | root
 
85
This mandatory parameter determines the place of the HTB instance, either at the
 
86
.B root
 
87
of an interface or within an existing class.
 
88
.TP
 
89
handle major:
 
90
Like all other qdiscs, the HTB can be assigned a handle. Should consist only
 
91
of a major number, followed by a colon. Optional, but very useful if classes
 
92
will be generated within this qdisc.
 
93
.TP 
 
94
default minor-id
 
95
Unclassified traffic gets sent to the class with this minor-id.
 
96
 
 
97
.SH CLASSES
 
98
Classes have a host of parameters to configure their operation.
 
99
 
 
100
.TP 
 
101
parent major:minor
 
102
Place of this class within the hierarchy. If attached directly to a qdisc 
 
103
and not to another class, minor can be omitted. Mandatory.
 
104
.TP 
 
105
classid major:minor
 
106
Like qdiscs, classes can be named. The major number must be equal to the
 
107
major number of the qdisc to which it belongs. Optional, but needed if this 
 
108
class is going to have children.
 
109
.TP 
 
110
prio priority
 
111
In the round-robin process, classes with the lowest priority field are tried 
 
112
for packets first. Mandatory.
 
113
 
 
114
.TP 
 
115
rate rate
 
116
Maximum rate this class and all its children are guaranteed. Mandatory.
 
117
 
 
118
.TP
 
119
ceil rate
 
120
Maximum rate at which a class can send, if its parent has bandwidth to spare. 
 
121
Defaults to the configured rate, which implies no borrowing
 
122
 
 
123
.TP 
 
124
burst bytes
 
125
Amount of bytes that can be burst at 
 
126
.B ceil
 
127
speed, in excess of the configured
 
128
.B rate. 
 
129
Should be at least as high as the highest burst of all children.
 
130
 
 
131
.TP 
 
132
cburst bytes
 
133
Amount of bytes that can be burst at 'infinite' speed, in other words, as fast
 
134
as the interface can transmit them. For perfect evening out, should be equal to at most one average
 
135
packet. Should be at least as high as the highest cburst of all children.
 
136
 
 
137
.SH NOTES
 
138
Due to Unix timing constraints, the maximum ceil rate is not infinite and may in fact be quite low. On Intel, 
 
139
there are 100 timer events per second, the maximum rate is that rate at which 'burst' bytes are sent each timer tick.
 
140
From this, the mininum burst size for a specified rate can be calculated. For i386, a 10mbit rate requires a 12 kilobyte 
 
141
burst as 100*12kb*8 equals 10mbit.
 
142
 
 
143
.SH SEE ALSO
 
144
.BR tc (8)
 
145
.P
 
146
HTB website: http://luxik.cdi.cz/~devik/qos/htb/
 
147
.SH AUTHOR
 
148
Martin Devera <devik@cdi.cz>. This manpage maintained by bert hubert <ahu@ds9a.nl>
 
149
 
 
150