mirror of https://github.com/tLDP/LDP
306 lines
11 KiB
XML
306 lines
11 KiB
XML
<!-- start of file -->
|
|
|
|
<!-- This .xml file is part of the Traffic-Control-HOWTO document -->
|
|
|
|
<!-- $Id$ -->
|
|
|
|
<!--
|
|
|
|
The article was authored by Martin A. Brown <martin@linux-ip.net>
|
|
for the linux community, and has been released under the GNU Free
|
|
Documentation License (GFDL) through The Linux Documentation
|
|
Project (TLDP).
|
|
|
|
This was initially authored while Martin A. Brown worked for
|
|
SecurePipe, Inc.
|
|
|
|
This HOWTO is likely available at the following address:
|
|
|
|
http://tldp.org/HOWTO/Traffic-Control-HOWTO/
|
|
|
|
-->
|
|
|
|
<!-- conventions used in this documentation....
|
|
|
|
- each section is a separate file
|
|
|
|
-->
|
|
|
|
<section id="classless-qdiscs">
|
|
|
|
<title>Classless Queuing Disciplines (&linux-qdisc;s)</title>
|
|
<para>
|
|
Each of these queuing disciplines can be used as the primary qdisc on an
|
|
interface, or can be used inside a leaf class of a &classful-qdiscs;.
|
|
These are the fundamental schedulers used under Linux. Note that the
|
|
default scheduler is the &link-sch_pfifo_fast;.
|
|
</para>
|
|
<para>
|
|
</para>
|
|
|
|
<section id="qs-fifo">
|
|
<title>FIFO, First-In First-Out (&sch_pfifo; and &sch_bfifo;)</title>
|
|
<note>
|
|
This is not the default qdisc on Linux interfaces. Be certain to see
|
|
<xref linkend="qs-pfifo_fast"/> for the full details on the default
|
|
(&sch_pfifo_fast;) qdisc.
|
|
</note>
|
|
<para>
|
|
The FIFO algorithm forms the basis for the default qdisc on all Linux
|
|
network interfaces (&link-sch_pfifo_fast;). It performs no shaping or
|
|
rearranging of packets. It simply transmits packets as soon as it can
|
|
after receiving and queuing them. This is also the qdisc used inside
|
|
all newly created classes until another qdisc or a class replaces the
|
|
&sch_fifo;.
|
|
</para>
|
|
<mediaobject id="img-qs-fifo">
|
|
<imageobject>
|
|
<imagedata fileref="images/fifo-qdisc.eps" format="EPS"/>
|
|
</imageobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/fifo-qdisc.png" format="PNG"/>
|
|
</imageobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/fifo-qdisc.jpg" format="JPG"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
<para>
|
|
A real FIFO qdisc must, however, have a size limit (a buffer size) to
|
|
prevent it from overflowing in case it is unable to dequeue packets as
|
|
quickly as it receives them. Linux implements two basic FIFO
|
|
&linux-qdisc;s, one based on bytes, and one on packets. Regardless of
|
|
the type of FIFO used, the size of the queue is defined by the parameter
|
|
<parameter>limit</parameter>. For a &sch_pfifo; the unit is understood
|
|
to be packets and for a &sch_bfifo; the unit is understood to be bytes.
|
|
</para>
|
|
<example id="ex-qs-fifo-limit">
|
|
<title>Specifying a <parameter>limit</parameter> for a packet
|
|
or byte FIFO</title>
|
|
<programlisting>
|
|
<prompt>[root@leander]# </prompt><userinput>cat bfifo.tcc</userinput>
|
|
<computeroutput>/*
|
|
* make a FIFO on eth0 with 10kbyte queue size
|
|
*
|
|
*/
|
|
|
|
dev eth0 {
|
|
egress {
|
|
fifo (limit 10kB );
|
|
}
|
|
}</computeroutput>
|
|
<prompt>[root@leander]# </prompt><userinput>tcc < bfifo.tcc</userinput>
|
|
<computeroutput># ================================ Device eth0 ================================
|
|
|
|
tc qdisc add dev eth0 handle 1:0 root dsmark indices 1 default_index 0
|
|
tc qdisc add dev eth0 handle 2:0 parent 1:0 bfifo limit 10240</computeroutput>
|
|
<prompt>[root@leander]# </prompt><userinput>cat pfifo.tcc</userinput>
|
|
<computeroutput>/*
|
|
* make a FIFO on eth0 with 30 packet queue size
|
|
*
|
|
*/
|
|
|
|
dev eth0 {
|
|
egress {
|
|
fifo (limit 30p );
|
|
}
|
|
}</computeroutput>
|
|
<prompt>[root@leander]# </prompt><userinput>tcc < pfifo.tcc</userinput>
|
|
<computeroutput># ================================ Device eth0 ================================
|
|
|
|
tc qdisc add dev eth0 handle 1:0 root dsmark indices 1 default_index 0
|
|
tc qdisc add dev eth0 handle 2:0 parent 1:0 pfifo limit 30</computeroutput>
|
|
</programlisting>
|
|
</example>
|
|
</section>
|
|
|
|
<section id="qs-pfifo_fast">
|
|
<title>&sch_pfifo_fast;, the default Linux qdisc</title>
|
|
<para>
|
|
The &sch_pfifo_fast; qdisc is the default qdisc for all interfaces under
|
|
Linux. Based on a conventional &link-sch_fifo; qdisc, this qdisc also
|
|
provides some prioritization. It provides three different bands
|
|
(individual FIFOs) for separating traffic. The highest priority traffic
|
|
(interactive flows) are placed into band 0 and are always serviced
|
|
first. Similarly, band 1 is always emptied of pending packets before
|
|
band 2 is dequeued.
|
|
</para>
|
|
<mediaobject id="img-qs-pfifo_fast">
|
|
<imageobject>
|
|
<imagedata fileref="images/pfifo_fast-qdisc.eps" format="EPS"/>
|
|
</imageobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/pfifo_fast-qdisc.png" format="PNG"/>
|
|
</imageobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/pfifo_fast-qdisc.jpg" format="JPG"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
<para>
|
|
There is nothing configurable to the end user about the &sch_pfifo_fast;
|
|
qdisc. For exact details on the <constant>priomap</constant> and use of
|
|
the ToS bits, see the &url-lartc-howto-pfifo_fast;.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="qs-sfq">
|
|
<title>&sch_sfq;, Stochastic Fair Queuing</title>
|
|
<para>
|
|
The &sch_sfq; qdisc attempts to fairly distribute opportunity to
|
|
transmit data to the network among an arbitrary number of
|
|
&concepts-flows;. It accomplishes this by using a hash function to
|
|
separate the traffic into separate (internally maintained) &sch_fifo;s
|
|
which are dequeued in a round-robin fashion. Because there is the
|
|
possibility for unfairness to manifest in the choice of hash function,
|
|
this function is altered periodically. Perturbation (the parameter
|
|
<parameter>perturb</parameter>) sets this periodicity.
|
|
</para>
|
|
<mediaobject id="img-qs-sfq">
|
|
<imageobject>
|
|
<imagedata fileref="images/sfq-qdisc.eps" format="EPS"/>
|
|
</imageobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/sfq-qdisc.png" format="PNG"/>
|
|
</imageobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/sfq-qdisc.jpg" format="JPG"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
<example id="ex-qs-sfq">
|
|
<title>Creating an &sch_sfq;</title>
|
|
<programlisting>
|
|
<prompt>[root@leander]# </prompt><userinput>cat sfq.tcc</userinput>
|
|
<computeroutput>/*
|
|
* make an SFQ on eth0 with a 10 second perturbation
|
|
*
|
|
*/
|
|
|
|
dev eth0 {
|
|
egress {
|
|
sfq( perturb 10s );
|
|
}
|
|
}</computeroutput>
|
|
<prompt>[root@leander]# </prompt><userinput>tcc < sfq.tcc</userinput>
|
|
<computeroutput># ================================ Device eth0 ================================
|
|
|
|
tc qdisc add dev eth0 handle 1:0 root dsmark indices 1 default_index 0
|
|
tc qdisc add dev eth0 handle 2:0 parent 1:0 sfq perturb 10</computeroutput>
|
|
</programlisting>
|
|
</example>
|
|
<para>
|
|
Unfortunately, some clever software (⪚ Kazaa and eMule among others)
|
|
obliterate the benefit of this attempt at fair queuing by opening as
|
|
many TCP sessions (&concepts-flows;) as can be sustained. In many
|
|
networks, with well-behaved users, &sch_sfq; can adequately distribute
|
|
the network resources to the contending flows, but other measures may be
|
|
called for when obnoxious applications have invaded the network.
|
|
</para>
|
|
<para>
|
|
See also
|
|
<xref linkend="qs-esfq"/> for an &sch_sfq; qdisc with more exposed
|
|
parameters for the user to manipulate.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="qs-esfq">
|
|
<title>&sch_esfq;, Extended Stochastic Fair Queuing</title>
|
|
<para>
|
|
Conceptually, this qdisc is no different than &sch_sfq; although it
|
|
allows the user to control more parameters than its simpler cousin.
|
|
This qdisc was conceived to overcome the shortcoming of &sch_sfq;
|
|
identified above. By allowing the user to control which hashing
|
|
algorithm is used for distributing access to network bandwidth, it
|
|
is possible for the user to reach a fairer real distribution of
|
|
bandwidth.
|
|
</para>
|
|
<example id="ex-qs-esfq-usage">
|
|
<title>&sch_esfq; usage</title>
|
|
<programlisting>
|
|
Usage: ... esfq [ perturb SECS ] [ quantum BYTES ] [ depth FLOWS ]
|
|
[ divisor HASHBITS ] [ limit PKTS ] [ hash HASHTYPE]
|
|
|
|
Where:
|
|
HASHTYPE := { classic | src | dst }
|
|
</programlisting>
|
|
</example>
|
|
<para>
|
|
FIXME; need practical experience and/or attestation here.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="qs-gred">
|
|
<title>GRED, Generic Random Early Drop</title>
|
|
<para>
|
|
FIXME; I have never used this. Need practical experience or
|
|
attestation.
|
|
</para>
|
|
<para>
|
|
Theory declares that a RED algorithm is useful on a backbone or core
|
|
network, but not as useful near the end-user. See the section on
|
|
&concepts-flows; to see a general discussion of the thirstiness of TCP.
|
|
</para>
|
|
</section>
|
|
|
|
<section id="qs-tbf">
|
|
<title>TBF, Token Bucket Filter</title>
|
|
<para>
|
|
This qdisc is built on &concepts-tokens; and &concepts-buckets;. It
|
|
simply shapes traffic transmitted on an interface. To limit the speed
|
|
at which packets will be dequeued from a particular interface, the
|
|
&sch_tbf; qdisc is the perfect solution. It simply slows down
|
|
transmitted traffic to the specified rate.
|
|
</para>
|
|
<para>
|
|
Packets are only transmitted if there are sufficient tokens available.
|
|
Otherwise, packets are deferred. Delaying packets in this fashion will
|
|
introduce an artificial latency into the packet's round trip time.
|
|
</para>
|
|
<mediaobject id="img-qs-tbf">
|
|
<imageobject>
|
|
<imagedata fileref="images/tbf-qdisc.eps" format="EPS"/>
|
|
</imageobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/tbf-qdisc.png" format="PNG"/>
|
|
</imageobject>
|
|
<imageobject>
|
|
<imagedata fileref="images/tbf-qdisc.jpg" format="JPG"/>
|
|
</imageobject>
|
|
</mediaobject>
|
|
<example id="ex-qs-tbf">
|
|
<title>Creating a 256kbit/s &sch_tbf;</title>
|
|
<programlisting>
|
|
<prompt>[root@leander]# </prompt><userinput>cat tbf.tcc</userinput>
|
|
<computeroutput>/*
|
|
* make a 256kbit/s TBF on eth0
|
|
*
|
|
*/
|
|
|
|
dev eth0 {
|
|
egress {
|
|
tbf( rate 256 kbps, burst 20 kB, limit 20 kB, mtu 1514 B );
|
|
}
|
|
}</computeroutput>
|
|
<prompt>[root@leander]# </prompt><userinput>tcc < tbf.tcc</userinput>
|
|
<computeroutput># ================================ Device eth0 ================================
|
|
|
|
tc qdisc add dev eth0 handle 1:0 root dsmark indices 1 default_index 0
|
|
tc qdisc add dev eth0 handle 2:0 parent 1:0 tbf burst 20480 limit 20480 mtu 1514 rate 32000bps</computeroutput>
|
|
</programlisting>
|
|
</example>
|
|
<para>
|
|
</para>
|
|
</section>
|
|
|
|
<!--
|
|
<section id="qs-wrr">
|
|
<title>WRR, Weighted Round Robin</title>
|
|
<para>
|
|
</para>
|
|
<para>
|
|
</para>
|
|
</section>
|
|
-->
|
|
|
|
</section>
|
|
|
|
<!-- end of file -->
|