-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings Y.K. Peng,
: But it confuses me that what is the accurate definition of the
: argument "rate"?
In order to understand the HTB concept of rate, you must understand
buckets. Read about either token buckets (e.g. Linux TBF [0]) or
leaky buckets (the generic idea) [1].
: It seems to be "the minimum rate which is guaranteed for a class"
: in the user guide of HTB Home, but in the manpage of lartc.org it
: is defined as "the maximun rate quaranteed for a class."
The difference is merely a matter of perspective. You may think of
it as you find most fitting for your understanding.
To understand the term in the context of HTB, it helps to understand
the entire borrowing model:
* HTB will always allow a packet in a leaf class to be dequeued
if that class has not yet exceeded its "rate". (This leaf
class is guaranteed a minimum "rate" of packet transmission.)
* HTB may attempt to transmit a packet from a leaf class if that
leaf class is above "rate" but below "ceil". In order to
transmit a packet when transmission of that packet will exceed
"rate", the leaf class will ask its parent class (which may ask
its parent class (which may ask ...) ) if it may borrow
(properly, "use") a token to dequeue the pending packet. If
the entire hierarchy of classes has an available token, then
that token is counted.
* HTB will never attempt to transmit a packet from a leaf class
which has exceeded its "ceil", an administrative absolute
maximum for this leaf class.
This borrowing logic holds true for all intermediate and root
classes, but packets are only dequeued from leaf HTB classes.
: First I setup the qos configuration by tc, and classification is
: done by the u32 classifier. In this case, no matter how the
: classes' rate set, the total bandwidth of 100Mbps will always be
: about 75Mbps and each class is assigned the bandwidth in the
: scale.
:
: To work with some tunnel or random-port transmission, another
: program was applied to set the priority value of the structure
: sk_buff as the classid the packet belongs to. In this case, the
: total bandwidth is limited at the rate we set, so do all the
: classes set.
:
: My question is that, why it differs from the two mechanism? Which
: one will be the correct result?
Unfortunately, I'm unable to interpret what your experiment was, so
will not be able to address this question. I can only guess that
you didn't use the "default" parameter on your HTB qdisc itself:
tc qdisc add dev $DEV root handle 1:0 default $DEFAULT_CLASS
If you do not specify a default class for otherwise unclassified
traffic AND if you do not include a classifier as a catch-all:
# -- catch all classifier
#
tc filter add dev eth0 parent 1:0 protocol ip prio 1 \
u32 match ip src 0.0.0.0/0
then any unclassified traffic will be dequeued as fast as the
hardware allows [2].
Good luck,
- -Martin
[0] http://tldp.org/HOWTO/Traffic-Control-HOWTO/classless-qdiscs.html#qs-tbf
http://lartc.org/howto/lartc.qdisc.classless.html
[1] http://linux-ip.net/gl/tcng/node54.html
http://en.wikipedia.org/wiki/Leaky_bucket
[2] http://www.docum.org/docum.org/docs/htb/
- --
Martin A. Brown
http://linux-ip.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: pgf-0.72 (http://linux-ip.net/sw/pine-gpg-filter/)
iD8DBQFFkuinHEoZD1iZ+YcRAlgCAKC8WUFHfSMpj513SrXk6PXvRFtaEACgtDvV
EaUDBj5i+vPdBjafnq7idLc=
=dg5o
-----END PGP SIGNATURE-----
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
