RE: [LARTC] PRIO and TBF is much better than HTB??

["Salim S I" <salim.si@cipherium.com.tw>]

[-- Attachment #1.1: Type: text/plain, Size: 2697 bytes --]

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. :-)
 
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-----
From: Simo [mailto:simo@mix4web.de] 
Sent: Friday, May 11, 2007 4:37 PM
To: 'Salim S I'; lartc@mailman.ds9a.nl
Subject: RE: [LARTC] PRIO and TBF is much better than HTB??
 
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: 
HTB with prio parameter cumulative:
http://simo.mix4web.de/up/htb_cumul_prio_paramter.jpg
PRIO and TBF cumulative: http://simo.mix4web.de/up/prio_tbf_cumul.jpg

>
> theory it will even starve the low priority traffic, if high prio
traffic is waiting to go out.
>

In the first illustration you can see that  the low priority traffic
also has been served (nearly exactly the same as with HTB). Because of
the use of PRIO in combination with TBF.
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
PRIO and TBF delay: http://simo.mix4web.de/up/prio_tbf_delay.jpg

I think that the overhead with the HTB algorithm is larger and the
scheduler keeps the packets a little longer in the queues.

Simo
 

[-- Attachment #1.2: Type: text/html, Size: 11608 bytes --]

[-- Attachment #2: Type: text/plain, Size: 143 bytes --]

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc