{ "content": [ { "type": "text", "text": "# tc-htb (man)\n\n## NAME\n\nHTB - Hierarchy Token Bucket\n\n## SYNOPSIS\n\ntc qdisc ... dev dev ( parent classid | root) [ handle major: ] htb [ default minor-id ] [\nr2q divisor ] [ offload ]\ntc class ... dev dev parent major:[minor] [ classid major:minor ] htb rate rate [ ceil rate ]\nburst bytes [ cburst bytes ] [ prio priority ] [ quantum bytes ]\n\n## DESCRIPTION\n\nHTB is meant as a more understandable and intuitive replacement for the CBQ qdisc in Linux.\nBoth CBQ and HTB help you to control the use of the outbound bandwidth on a given link. Both\nallow you to use one physical link to simulate several slower links and to send different\nkinds of traffic on different simulated links. In both cases, you have to specify how to di‐\nvide the physical link into simulated links and how to decide which simulated link to use for\na given packet to be sent.\n\n## Sections\n\n- **NAME**\n- **SYNOPSIS**\n- **DESCRIPTION**\n- **SHAPING ALGORITHM**\n- **CLASSIFICATION**\n- **LINK SHARING ALGORITHM**\n- **QDISC**\n- **CLASSES**\n- **NOTES**\n- **SEE ALSO**\n- **AUTHOR**\n\nUse structuredContent.sections for detailed options, examples, and full documentation.\n" } ], "structuredContent": { "command": "tc-htb", "section": "", "mode": "man", "summary": "HTB - Hierarchy Token Bucket", "synopsis": "tc qdisc ... dev dev ( parent classid | root) [ handle major: ] htb [ default minor-id ] [\nr2q divisor ] [ offload ]\ntc class ... dev dev parent major:[minor] [ classid major:minor ] htb rate rate [ ceil rate ]\nburst bytes [ cburst bytes ] [ prio priority ] [ quantum bytes ]", "tldr_summary": null, "tldr_examples": [], "tldr_source": null, "flags": [], "examples": [], "see_also": [ { "name": "tc", "section": "8", "url": "https://www.chedong.com/phpMan.php/man/tc/8/json" } ], "section_outline": [ { "name": "NAME", "lines": 2, "subsections": [] }, { "name": "SYNOPSIS", "lines": 7, "subsections": [] }, { "name": "DESCRIPTION", "lines": 12, "subsections": [] }, { "name": "SHAPING ALGORITHM", "lines": 3, "subsections": [] }, { "name": "CLASSIFICATION", "lines": 23, "subsections": [] }, { "name": "LINK SHARING ALGORITHM", "lines": 3, "subsections": [] }, { "name": "QDISC", "lines": 23, "subsections": [] }, { "name": "CLASSES", "lines": 43, "subsections": [] }, { "name": "NOTES", "lines": 7, "subsections": [] }, { "name": "SEE ALSO", "lines": 4, "subsections": [] }, { "name": "AUTHOR", "lines": 3, "subsections": [] } ], "sections": { "NAME": { "content": "HTB - Hierarchy Token Bucket\n", "subsections": [] }, "SYNOPSIS": { "content": "tc qdisc ... dev dev ( parent classid | root) [ handle major: ] htb [ default minor-id ] [\nr2q divisor ] [ offload ]\n\ntc class ... dev dev parent major:[minor] [ classid major:minor ] htb rate rate [ ceil rate ]\nburst bytes [ cburst bytes ] [ prio priority ] [ quantum bytes ]\n\n", "subsections": [] }, "DESCRIPTION": { "content": "HTB is meant as a more understandable and intuitive replacement for the CBQ qdisc in Linux.\nBoth CBQ and HTB help you to control the use of the outbound bandwidth on a given link. Both\nallow you to use one physical link to simulate several slower links and to send different\nkinds of traffic on different simulated links. In both cases, you have to specify how to di‐\nvide the physical link into simulated links and how to decide which simulated link to use for\na given packet to be sent.\n\nUnlike CBQ, HTB shapes traffic based on the Token Bucket Filter algorithm which does not de‐\npend on interface characteristics and so does not need to know the underlying bandwidth of\nthe outgoing interface.\n\n", "subsections": [] }, "SHAPING ALGORITHM": { "content": "Shaping works as documented in tc-tbf (8).\n\n", "subsections": [] }, "CLASSIFICATION": { "content": "Within the one HTB instance many classes may exist. Each of these classes contains another\nqdisc, by default tc-pfifo(8).\n\nWhen enqueueing a packet, HTB starts at the root and uses various methods to determine which\nclass should receive the data.\n\nIn the absence of uncommon configuration options, the process is rather easy. At each node\nwe look for an instruction, and then go to the class the instruction refers us to. If the\nclass found is a barren leaf-node (without children), we enqueue the packet there. If it is\nnot yet a leaf node, we do the whole thing over again starting from that node.\n\nThe following actions are performed, in order at each node we visit, until one sends us to\nanother node, or terminates the process.\n\n(i) Consult filters attached to the class. If sent to a leafnode, we are done. Otherwise,\nrestart.\n\n(ii) If none of the above returned with an instruction, enqueue at this node.\n\nThis algorithm makes sure that a packet always ends up somewhere, even while you are busy\nbuilding your configuration.\n\n", "subsections": [] }, "LINK SHARING ALGORITHM": { "content": "FIXME\n\n", "subsections": [] }, "QDISC": { "content": "The root of a HTB qdisc class tree has the following parameters:\n\n\nparent major:minor | root\nThis mandatory parameter determines the place of the HTB instance, either at the root\nof an interface or within an existing class.\n\nhandle major:\nLike all other qdiscs, the HTB can be assigned a handle. Should consist only of a ma‐\njor number, followed by a colon. Optional, but very useful if classes will be gener‐\nated within this qdisc.\n\ndefault minor-id\nUnclassified traffic gets sent to the class with this minor-id.\n\nr2q divisor\nDivisor used to calculate quantum values for classes. Classes divide rate by this\nnumber. Default value is 10.\n\noffload\nOffload the HTB algorithm to hardware (requires driver and device support).\n\n", "subsections": [] }, "CLASSES": { "content": "Classes have a host of parameters to configure their operation.\n\n\nparent major:minor\nPlace of this class within the hierarchy. If attached directly to a qdisc and not to\nanother class, minor can be omitted. Mandatory.\n\nclassid major:minor\nLike qdiscs, classes can be named. The major number must be equal to the major number\nof the qdisc to which it belongs. Optional, but needed if this class is going to have\nchildren.\n\nprio priority\nIn the round-robin process, classes with the lowest priority field are tried for pack‐\nets first.\n\n\nrate rate\nMaximum rate this class and all its children are guaranteed. Mandatory.\n\n\nceil rate\nMaximum rate at which a class can send, if its parent has bandwidth to spare. De‐\nfaults to the configured rate, which implies no borrowing\n\n\nburst bytes\nAmount of bytes that can be burst at ceil speed, in excess of the configured rate.\nShould be at least as high as the highest burst of all children.\n\n\ncburst bytes\nAmount of bytes that can be burst at 'infinite' speed, in other words, as fast as the\ninterface can transmit them. For perfect evening out, should be equal to at most one\naverage packet. Should be at least as high as the highest cburst of all children.\n\n\nquantum bytes\nNumber of bytes to serve from this class before the scheduler moves to the next class.\nDefault value is rate divided by the qdisc r2q parameter. If specified, r2q is ig‐\nnored.\n\n", "subsections": [] }, "NOTES": { "content": "Due to Unix timing constraints, the maximum ceil rate is not infinite and may in fact be\nquite low. On Intel, there are 100 timer events per second, the maximum rate is that rate at\nwhich 'burst' bytes are sent each timer tick. From this, the minimum burst size for a speci‐\nfied rate can be calculated. For i386, a 10mbit rate requires a 12 kilobyte burst as\n100*12kb*8 equals 10mbit.\n\n", "subsections": [] }, "SEE ALSO": { "content": "tc(8)\n\nHTB website: http://luxik.cdi.cz/~devik/qos/htb/\n", "subsections": [] }, "AUTHOR": { "content": "Martin Devera . This manpage maintained by bert hubert \n\niproute2 10 January 2002 HTB(8)", "subsections": [] } } } }