|
That is why I said ‘in theory’.
Using PRIO qdisc, I have never been able to achieve starvation
of low priority traffic. I have tested with same rates for both high and low prio traffic, and did not see high priority traffic really
dominating. Maybe a high rate of high prio traffic
combined with a low rate of low prio traffic will achieve
this, I don’t know. The cumulative effect you see is more
likely due to the errant behavior, not the intended behavior of PRIO qdisc. I may be wrong here; I am speaking only from my experience.
You make a decision whether to depend on this unintentional, but very common,
behavior or not. Another thing is, PRIO qdisc lists a known bug: High rate of low priority traffic
will starve High priority traffic. So if all goes according to the known
documentation, ‘some’ of your traffic will starve under ‘some’
condition. J But yes, TBF+PRIO is
the preferred solution for latency sensitive applications, like Voice/Video. In
such cases, one doesn’t care if the non-realtime
traffic is starved or not. The PRIO algorithm is designed to ‘empty’
high priority queue first. HTB only ensures that high priority queue is ‘serviced’
first. HTB has a fair queuing algorithm. It is
not really suited for prioritizing traffic, i.e to
give absolute priority. Still, you may take a look at the wondershaper
script, which prioritizes some traffic using HTB. -----Original Message----- Hi, Thanks for your
answer. You are right
concerning the PRIO QDisc, but which I did not understand is that the
combination (PRIO+TBF) made a Shaping nearly exactly the same as with HTB only
with better latency. One sees this with the comparison of the two following
illustrations of my simulation:
But the latency is
much better, if you compares the following illustrations: HTB with prio parameter delay: http://simo.mix4web.de/up/htb_delay_prio_parameter.jpg |
_______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
