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

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

[Simo]

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

Hello mailing list,

i stand bevor a mystery and cannot explain it J. I want to do shaping and
prioritization and I have done these following configurations and
simulations. I can´t explain, that the combination of PRIO and TBF is much
better than the  HTB (with the prio parameter) alone or  in combination with
the SFQ.

Here are my example configurations: 2 Traffic Classes http (80 = 0x50) and
ssh (22 = 0x16), and in my example, I want to prioritize the http-Traffic:

HTB: the results of the simulation ist here: 

HTB cumulative: http://simo.mix4web.de/up/htb_cumul.jpg

HTB delay: http://simo.mix4web.de/up/htb_delay.jpg

HTB with prio parameter cumulative:
http://simo.mix4web.de/up/htb_cumul_prio_paramter.jpg

HTB with prio parameter delay:
http://simo.mix4web.de/up/htb_delay_prio_parameter.jpg

 

#define UPLOAD 1000kbps

dev eth0 1000 {

    egress {

        class ( <$high> )  if tcp_dport == 80;

        class(<$low>) if  tcp_dport == 22;

        htb () {

                class ( rate UPLOAD, ceil UPLOAD) {

/* with the prio parameter : $high   = class ( rate 700kbps, ceil UPLOAD,
prio 0); */

                $high   = class ( rate 700kbps, ceil UPLOAD);

                /* with the prio parameter : $low   = class ( rate 300kbps,
ceil UPLOAD, prio 0); */

                $low  = class ( rate 300kbps, ceil UPLOAD, prio 1);

                }

        }

    }

}

 

/* 1Mbit 0.0008 = 100*8/10^6  */

every 0.0008s send TCP_PCK($tcp_dport=22) 0 x 60

/* 800kbit/s  */

every 0.001s send TCP_PCK($tcp_dport=80) 0 x 60

time 2s

 

 

 

 

PRIO and TBF:

PRIO and TBF cumulative: http://simo.mix4web.de/up/prio_tbf_cumul.jpg

PRIO and TBF delay: http://simo.mix4web.de/up/prio_tbf_delay.jpg

 

#define UPLOAD 1000kbps

 

dev eth0 1000 {

    egress {

        class ( <$high> )  if tcp_dport == 80;

        class(<$low>) if  tcp_dport == 22;

        prio{

              $high = class{ tbf (rate 700kbps, burst 1510B, mtu 1510B,
limit 3000B);  }

              $low = class{ tbf (rate 300kbps, burst 1510B, mtu 1510B, limit
3000B); }

             }

        }

 

}

 

/* 1Mbit 0.0008 = 100*8/10^6  */

every 0.0008s send TCP_PCK($tcp_dport=22) 0 x 60

/* 800kbit/s  */

every 0.001s send TCP_PCK($tcp_dport=80) 0 x 60

time 2s

 

 

 

the delay by the combination of PRIO and TBF is much better than by the HTB.
(is it possible that pakets maybe dropped by the combination of PRIO and
TBF, that´s why the latency is so good???)

 

Have you an idea???

 

thanks

simo

 

----------------------------------------------------------------------------
-----------------------------------------------------------------
In a world without walls who needs gates and windows?

 


[-- Attachment #1.2: Type: text/html, Size: 10571 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

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

[Salim S I]

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

HTB’s priority and PRIO qdisc are very different.
 
PRIO qdisc will definitely give better latency for your high priority
traffic, since the qdisc is designed for the purpose of ‘priority’. In
theory it will even starve the low priority traffic, if high prio
traffic is waiting to go out.
 
HTB’s priority is different, it only gives relative priority. High prio
class in a level is de-queued first during the roundrobin/wrr cycle, but
lower priority classes will also be fairly serviced, unlike PRIO qdisc.
 
 
-----Original Message-----
From: lartc-bounces@mailman.ds9a.nl
[mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Simo
Sent: Thursday, May 10, 2007 11:13 PM
To: lartc@mailman.ds9a.nl
Subject: [LARTC] PRIO and TBF is much better than HTB??
 
Hello mailing list,
i stand bevor a mystery and cannot explain it :-). I want to do shaping
and prioritization and I have done these following configurations and
simulations. I can´t explain, that the combination of PRIO and TBF is
much better than the  HTB (with the prio parameter) alone or  in
combination with the SFQ.
Here are my example configurations: 2 Traffic Classes http (80 = 0x50)
and ssh (22 = 0x16), and in my example, I want to prioritize the
http-Traffic:
HTB: the results of the simulation ist here: 
HTB cumulative: http://simo.mix4web.de/up/htb_cumul.jpg
HTB delay: http://simo.mix4web.de/up/htb_delay.jpg
HTB with prio parameter cumulative:
http://simo.mix4web.de/up/htb_cumul_prio_paramter.jpg
HTB with prio parameter delay:
http://simo.mix4web.de/up/htb_delay_prio_parameter.jpg
 
#define UPLOAD 1000kbps
dev eth0 1000 {
    egress {
        class ( <$high> )  if tcp_dport == 80;
        class(<$low>) if  tcp_dport == 22;
        htb () {
                class ( rate UPLOAD, ceil UPLOAD) {
/* with the prio parameter : $high   = class ( rate 700kbps, ceil
UPLOAD, prio 0); */
                $high   = class ( rate 700kbps, ceil UPLOAD);
                /* with the prio parameter : $low   = class ( rate
300kbps, ceil UPLOAD, prio 0); */
                $low  = class ( rate 300kbps, ceil UPLOAD, prio 1);
                }
        }
    }
}
 
/* 1Mbit 0.0008 = 100*8/10^6  */
every 0.0008s send TCP_PCK($tcp_dport=22) 0 x 60
/* 800kbit/s  */
every 0.001s send TCP_PCK($tcp_dport=80) 0 x 60
time 2s
 
 
 
 
PRIO and TBF:
PRIO and TBF cumulative: http://simo.mix4web.de/up/prio_tbf_cumul.jpg
PRIO and TBF delay: http://simo.mix4web.de/up/prio_tbf_delay.jpg
 
#define UPLOAD 1000kbps
 
dev eth0 1000 {
    egress {
        class ( <$high> )  if tcp_dport == 80;
        class(<$low>) if  tcp_dport == 22;
        prio{
              $high = class{ tbf (rate 700kbps, burst 1510B, mtu 1510B,
limit 3000B);  }
              $low = class{ tbf (rate 300kbps, burst 1510B, mtu 1510B,
limit 3000B); }
             }
        }
 
}
 
/* 1Mbit 0.0008 = 100*8/10^6  */
every 0.0008s send TCP_PCK($tcp_dport=22) 0 x 60
/* 800kbit/s  */
every 0.001s send TCP_PCK($tcp_dport=80) 0 x 60
time 2s
 
 
 
the delay by the combination of PRIO and TBF is much better than by the
HTB. (is it possible that pakets maybe dropped by the combination of
PRIO and TBF, that´s why the latency is so good???)
 
Have you an idea???
 
thanks
simo
 
------------------------------------------------------------------------
---------------------------------------------------------------------
In a world without walls who needs gates and windows?
 

[-- Attachment #1.2: Type: text/html, Size: 21830 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

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

[Simo]

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

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: 4386 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

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

[Salim S I]

[-- 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

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

[Andy Furniss]

Simo wrote:

> #define UPLOAD 1000kbps

I've never used tcns/sim if that's what this is kbps means k bytes to 
"normal" tc.


>               $low = class{ tbf (rate 300kbps, burst 1510B, mtu 1510B, limit
> 3000B); }

limit 3000B - not even enough for two packets (1500 mtu = 1514 to tc on 
eth), would hurt performance on a real wan.

> every 0.0008s send TCP_PCK($tcp_dport") 0 x 60
> 
> /* 800kbit/s  */

testing with a stream is not very representative of real tcp.


> the delay by the combination of PRIO and TBF is much better than by the HTB.
> (is it possible that pakets maybe dropped by the combination of PRIO and
> TBF, that´s why the latency is so good???)

Yes unless you add leafs with limit htb uses qlen of nic, default 1000p

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

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

[Simo]

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

Hi, 

Thanks a lot for your explanations. J I ´ve looked for an advantage of HTB
opposite the combination PRIO+TBF , because this combination seemed better
to me. But I´ve forgotten ;) that  with HTB the unused Tokens can be
distributed fairly on the other classes, so that the unused Bandwidth can
fairly distributed on the other classes and that is not the case with the
combination PRIO+TBF. That´s why I would prefer to use the HTB.

 

Simo


[-- Attachment #1.2: Type: text/html, Size: 3238 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

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

[Flechsenhaar, Jon J]

[-- Attachment #1: Type: text/plain, Size: 206 bytes --]

--===============0941138996==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C793E4.0E1A6D14"

This is a multi-part message in MIME format.

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

Just to comment.  Yes you will get better latency with prio and tbf.  However there creation purposes were for different end goals.  HTB has the ability to create a class structure that can break your link bandwidth up into different classes.  The prio setting in HTB is to determine which class will get served if there is additional bandwidth.  However all classes will get there guaranteed rates.  This fits well into DiffServ.
 
Prio is just priority.  A higher prio class will starve out a lower prio class.  There is no guaranteed rates or class structure, only qdiscs.  
 
TBF is purely a rate limitor.  Use it to slow down an interface.  Again no class structure.  
 
http://opalsoft.net/qos/DS.htm
 
The above link is a must if your working with QoS on Linux.  
Jon Flechsenhaar 
Boeing WNW Team 
Network Services 
(714)-762-1231 
202-E7 
 

________________________________

From: Salim S I [mailto:salim.si@cipherium.com.tw] 
Sent: Thursday, May 10, 2007 11:26 PM
To: lartc@mailman.ds9a.nl
Subject: RE: [LARTC] PRIO and TBF is much better than HTB??


HTB's priority and PRIO qdisc are very different.
 
PRIO qdisc will definitely give better latency for your high priority traffic, since the qdisc is designed for the purpose of 'priority'. In theory it will even starve the low priority traffic, if high prio traffic is waiting to go out.
 
HTB's priority is different, it only gives relative priority. High prio class in a level is de-queued first during the roundrobin/wrr cycle, but lower priority classes will also be fairly serviced, unlike PRIO qdisc.
 
 
-----Original Message-----
From: lartc-bounces@mailman.ds9a.nl [mailto:lartc-bounces@mailman.ds9a.nl] On Behalf Of Simo
Sent: Thursday, May 10, 2007 11:13 PM
To: lartc@mailman.ds9a.nl
Subject: [LARTC] PRIO and TBF is much better than HTB??
 
Hello mailing list,
i stand bevor a mystery and cannot explain it :-). I want to do shaping and prioritization and I have done these following configurations and simulations. I can´t explain, that the combination of PRIO and TBF is much better than the  HTB (with the prio parameter) alone or  in combination with the SFQ.
Here are my example configurations: 2 Traffic Classes http (80 = 0x50) and ssh (22 = 0x16), and in my example, I want to prioritize the http-Traffic:
HTB: the results of the simulation ist here: 
HTB cumulative: http://simo.mix4web.de/up/htb_cumul.jpg
HTB delay: http://simo.mix4web.de/up/htb_delay.jpg
HTB with prio parameter cumulative: http://simo.mix4web.de/up/htb_cumul_prio_paramter.jpg
HTB with prio parameter delay: http://simo.mix4web.de/up/htb_delay_prio_parameter.jpg
 
#define UPLOAD 1000kbps
dev eth0 1000 {
    egress {
        class ( <$high> )  if tcp_dport == 80;
        class(<$low>) if  tcp_dport == 22;
        htb () {
                class ( rate UPLOAD, ceil UPLOAD) {
/* with the prio parameter : $high   = class ( rate 700kbps, ceil UPLOAD, prio 0); */
                $high   = class ( rate 700kbps, ceil UPLOAD);
                /* with the prio parameter : $low   = class ( rate 300kbps, ceil UPLOAD, prio 0); */
                $low  = class ( rate 300kbps, ceil UPLOAD, prio 1);
                }
        }
    }
}
 
/* 1Mbit 0.0008 = 100*8/10^6  */
every 0.0008s send TCP_PCK($tcp_dport=22) 0 x 60
/* 800kbit/s  */
every 0.001s send TCP_PCK($tcp_dport=80) 0 x 60
time 2s
 
 
 
 
PRIO and TBF:
PRIO and TBF cumulative: http://simo.mix4web.de/up/prio_tbf_cumul.jpg
PRIO and TBF delay: http://simo.mix4web.de/up/prio_tbf_delay.jpg
 
#define UPLOAD 1000kbps
 
dev eth0 1000 {
    egress {
        class ( <$high> )  if tcp_dport == 80;
        class(<$low>) if  tcp_dport == 22;
        prio{
              $high = class{ tbf (rate 700kbps, burst 1510B, mtu 1510B, limit 3000B);  }
              $low = class{ tbf (rate 300kbps, burst 1510B, mtu 1510B, limit 3000B); }
             }
        }
 
}
 
/* 1Mbit 0.0008 = 100*8/10^6  */
every 0.0008s send TCP_PCK($tcp_dport=22) 0 x 60
/* 800kbit/s  */
every 0.001s send TCP_PCK($tcp_dport=80) 0 x 60
time 2s
 
 
 
the delay by the combination of PRIO and TBF is much better than by the HTB. (is it possible that pakets maybe dropped by the combination of PRIO and TBF, that´s why the latency is so good???)
 
Have you an idea???
 
thanks
simo
 
---------------------------------------------------------------------------------------------------------------------------------------------
In a world without walls who needs gates and windows?
 

[-- Attachment #3: Type: text/html, Size: 24646 bytes --]