From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Simo" Date: Fri, 11 May 2007 08:36:31 +0000 Subject: RE: [LARTC] PRIO and TBF is much better than HTB?? Message-Id: <001501c793a7$7c3d4480$74b7cd80$@de> MIME-Version: 1 Content-Type: multipart/mixed; boundary="===============0805219015==" List-Id: References: <001401c79315$b1732c60$14598520$@de> In-Reply-To: <001401c79315$b1732c60$14598520$@de> To: lartc@vger.kernel.org Dies ist eine mehrteilige Nachricht im MIME-Format. --===============0805219015== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01C793B8.3FC61480" Content-Language: de Dies ist eine mehrteilige Nachricht im MIME-Format. ------=_NextPart_000_0016_01C793B8.3FC61480 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_0016_01C793B8.3FC61480 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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://sim= o.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://si= mo.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

 

------=_NextPart_000_0016_01C793B8.3FC61480-- --===============0805219015== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc --===============0805219015==--