-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello all,
: So, instead of trying to use a prio qdisc alone, try using a
: single HTB class to limit your traffic to a given rate and then
: embed your prio qdisc inside that. There are many other possible
: options for nested qdiscs, and maybe somebody on this list will
: make a recommendation to you for how s/he solved this problem.
This is a correction/clarification for posterity. There is still a
problem with the above, and I'd like to correct it and thank Gustavo
Homem [0] for pointing out my possibly misleading advice here.
Mike indicated that he was willing to let VoIP traffic out
regardless of the cost to other flows. This means that the above
solution might work acceptably for his needs in this situation...
However, this is not a good general solution!
When evaluating a traffic control mechanism for a particular
solution, there are a number of different network characteristics
that we need to keep in mind. The big three are throughput, delay
and jitter.
Each traffic control mechanism that we might employ affects at least
one (and almost always more than one) of the above network
characteristics. Selecting the correct mechanism for a given
application depends on what we are willing to trade.
Some people are willing to trade total throughput for delay (those
of us who like responsive ssh sessions, for example).
Some people MUST trade delay and jitter for throughput (VoIP
applications).
So, to return to the problem of a single PRIO qdisc (a
work-conserving queuing discipline), how can we add some sort of
non-work-conserving mechanism (shaping) and still take advantage of
some prioritization.
There are a number of ways to solve this problem, but let's look at
the following options (+ = good, - = not-so-good):
A. HTB qdisc, one class, with child PRIO qdisc
+ HTB shapes total dequeued traffic rate to the specified
maximum rate.
+ PRIO qdisc ensures that traffic you classify as high
priority always has preferential access to full link
bandwidth (as limited by HTB's rate)
- high priority flows can completely starve low priority
flows
B. PRIO qdisc, each class contains a TBF qdisc specifying
transmisison rate
+ each class gets up to its TBF of throughput before it gets
shaped.
+ each class gets is completely isolated from the other classes
so if the sum of the rates of the TBF qdiscs does not exceed
link bandwidth, you should see predictable delay and jitter
- any given class could become backlogged easily and there's
no sharing between classes
C. HTB qdisc, HTB children classes[, children sfq or fifo qdiscs]
+ HTB shapes total dequeued traffic rate to the specified
maximum rate.
+ HTB children classes can borrow from parent classes, if
some bandwidth goes unused
- must write filters to specify which class receives which
packets
The above is just an outline to point out some of the tradeoffs that
need to be examined and understood when choosing a traffic control
mechanism for any particular situation.
I was probably a bit facile in my answer to Mike, so I hope this
post clears up the ambiguity of the recommendation.
Good luck and happy QoS!
- -Martin
[0] http://mailman.ds9a.nl/pipermail/lartc/2006q3/019232.html
- --
Martin A. Brown
http://linux-ip.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: pgf-0.71 (http://linux-ip.net/sw/pine-gpg-filter/)
iD8DBQFEsxDdHEoZD1iZ+YcRAormAJsGkouYrqoM0q8Zgw0aCaXpZTMKkQCfbc+E
UruTl/GvAVMHqGRqzUwwc0Q=
=Sk64
-----END PGP SIGNATURE-----
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
