LARTC - Sep 2005 - Re:Does HTB consider PRIO or not? 2

Thanks for quick reply Andreas!
> Every class is allowed to use bandwidth as long as it does not have to
> borrow (the specified rate is guaranteed). Prio in HTB only affects
> borrowing bandwidth from other classes... In the example below, the class
> 1:5 should be allowed to borrow bandwidth before 1:14 does.
Thats exactly what I want from HTB to do..to prio the borrowed bandwidth.
>Why are there pacekts in direct_packets_stat?
I really dont know what that parameter means..i have to google...

Well the output is really big . The classes are 1:5 and 1:14...
#########################################QDISC##############################

root@srv1:/etc# tc -s -d qdisc show dev eth1
qdisc htb 1: r2q 10 default 20 direct_packets_stat 119 ver 3.17
 Sent 825410989 bytes 1198046 pkt (dropped 20, overlimits 699638 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 10: parent 1:10 limit 128p quantum 2000b flows 128/1024 perturb
10sec
 Sent 975066 bytes 3184 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 11: parent 1:11 limit 128p quantum 2000b flows 128/1024 perturb
10sec
 Sent 98738318 bytes 107102 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 12: parent 1:12 limit 128p quantum 2000b flows 128/1024 perturb
10sec
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 13: parent 1:13 limit 128p quantum 2000b flows 128/1024 perturb
10sec
 Sent 11567 bytes 39 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 14: parent 1:14 limit 128p quantum 2000b flows 128/1024 perturb
10sec
 Sent 198407443 bytes 155851 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 3: parent 1:3 limit 128p quantum 2000b flows 128/1024 perturb
10sec
 Sent 7376790 bytes 37554 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 4: parent 1:4 limit 128p quantum 2000b flows 128/1024 perturb
10sec
 Sent 93535775 bytes 265442 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 6: parent 1:6 limit 128p quantum 2000b flows 128/1024 perturb
10sec
 Sent 22992561 bytes 33533 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 7: parent 1:7 limit 128p quantum 2000b flows 128/1024 perturb
10sec
 Sent 32697260 bytes 45856 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc sfq 9: parent 1:9 limit 128p quantum 2000b flows 128/1024 perturb
10sec
 Sent 154225412 bytes 167878 pkt (dropped 20, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
########################################CLASSES#############################

root@srv1:/etc# tc -s -d class show dev eth1
class htb 1:11 parent 1:2 leaf 11: prio 0 quantum 1600 rate 128000bit ceil
900000bit burst 6399b/8 mpu 0b overhead 0b cburst 2Kb/8 mpu 0b overhead 0b
level 0
 Sent 96523510 bytes 104979 pkt (dropped 0, overlimits 0 requeues 0)
 rate 48552bit 5pps backlog 0b 0p requeues 0
 lended: 84663 borrowed: 20316 giants: 0
 tokens: 109056 ctokens: -10028

class htb 1:10 parent 1:2 leaf 10: prio 3 quantum 1000 rate 20000bit ceil
512000bit burst 6399b/8 mpu 0b overhead 0b cburst 1855b/8 mpu 0b overhead 0b
level 0
 Sent 907525 bytes 2857 pkt (dropped 0, overlimits 0 requeues 0)
 rate 3616bit 1pps backlog 0b 0p requeues 0
 lended: 2735 borrowed: 122 giants: 0
 tokens: 2601780 ctokens: 28928

class htb 1:2 root rate 10000Kbit ceil 10000Kbit burst 6598b/8 mpu 0b
overhead 0b cburst 6598b/8 mpu 0b overhead 0b level 7
 Sent 809019198 bytes 1164113 pkt (dropped 0, overlimits 0 requeues 0)
 rate 744616bit 139pps backlog 0b 0p requeues 0
 lended: 392463 borrowed: 0 giants: 0
 tokens: 4168 ctokens: 4168

class htb 1:13 parent 1:2 leaf 13: prio 2 quantum 1000 rate 64000bit ceil
512000bit burst 6399b/8 mpu 0b overhead 0b cburst 1855b/8 mpu 0b overhead 0b
level 0
 Sent 11567 bytes 39 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 lended: 39 borrowed: 0 giants: 0
 tokens: 754690 ctokens: 21634

class htb 1:20 parent 1:2 prio 0 quantum 1000 rate 40000bit ceil 40000bit
burst 1619b/8 mpu 0b overhead 0b cburst 1619b/8 mpu 0b overhead 0b level 0
 Sent 347725 bytes 3397 pkt (dropped 0, overlimits 0 requeues 0)
 rate 48bit 0pps backlog 0b 0p requeues 0
 lended: 3397 borrowed: 0 giants: 0
 tokens: 323586 ctokens: 323586

class htb 1:12 parent 1:2 leaf 12: prio 0 quantum 2400 rate 192000bit ceil
900000bit burst 6399b/8 mpu 0b overhead 0b cburst 2Kb/8 mpu 0b overhead 0b
level 0
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
 lended: 0 borrowed: 0 giants: 0
 tokens: 273065 ctokens: 18659

class htb 1:3 parent 1:2 leaf 3: prio 0 quantum 125000 rate 10000Kbit ceil
10000Kbit burst 6598b/8 mpu 0b overhead 0b cburst 6598b/8 mpu 0b overhead 0b
level 0
 Sent 7081918 bytes 36097 pkt (dropped 0, overlimits 0 requeues 0)
 rate 984bit 0pps backlog 0b 0p requeues 0
 lended: 36097 borrowed: 0 giants: 0
 tokens: 679 ctokens: 679

class htb 1:4 parent 1:2 leaf 4: prio 0 quantum 25000 rate 2000Kbit ceil
2000Kbit burst 6399b/8 mpu 0b overhead 0b cburst 6399b/8 mpu 0b overhead 0b
level 0
 Sent 90743505 bytes 255690 pkt (dropped 0, overlimits 0 requeues 0)
 rate 20840bit 25pps backlog 0b 0p requeues 0
 lended: 255690 borrowed: 0 giants: 0
 tokens: 22709 ctokens: 22709

class htb 1:14 parent 1:2 leaf 14: prio 7 quantum 1000 rate 18000bit ceil
900000bit burst 1608b/8 mpu 0b overhead 0b cburst 2Kb/8 mpu 0b overhead 0b
level 0
 Sent 191751670 bytes 151197 pkt (dropped 0, overlimits 0 requeues 0)
 rate 497456bit 42pps backlog 0b 0p requeues 0
 lended: 17413 borrowed: 133784 giants: 0
 tokens: -947087 ctokens: -7717

class htb 1:5 parent 1:2 prio 1 quantum 1600 rate 128000bit ceil 950000bit
burst 1663b/8 mpu 0b overhead 0b cburst 2074b/8 mpu 0b overhead 0b level 0
 Sent 98506773 bytes 91377 pkt (dropped 0, overlimits 0 requeues 0)
 rate 336bit 0pps backlog 0b 0p requeues 0
 lended: 43850 borrowed: 47527 giants: 0
 tokens: 97792 ctokens: 16721

class htb 1:6 parent 1:2 leaf 6: prio 3 quantum 1600 rate 128000bit ceil
256000bit burst 6399b/8 mpu 0b overhead 0b cburst 1727b/8 mpu 0b overhead 0b
level 0
 Sent 22893201 bytes 33231 pkt (dropped 0, overlimits 0 requeues 0)
 rate 1144bit 0pps backlog 0b 0p requeues 0
 lended: 31243 borrowed: 1988 giants: 0
 tokens: 406528 ctokens: 53760

class htb 1:7 parent 1:2 leaf 7: prio 3 quantum 1600 rate 128000bit ceil
256000bit burst 6399b/8 mpu 0b overhead 0b cburst 1727b/8 mpu 0b overhead 0b
level 0
 Sent 32156247 bytes 44778 pkt (dropped 0, overlimits 0 requeues 0)
 rate 1664bit 0pps backlog 0b 0p requeues 0
 lended: 39321 borrowed: 5457 giants: 0
 tokens: 399872 ctokens: 50432

class htb 1:8 parent 1:2 prio 3 quantum 1000 rate 64000bit ceil 256000bit
burst 6399b/8 mpu 0b overhead 0b cburst 1727b/8 mpu 0b overhead 0b level 0
 Sent 114626954 bytes 275856 pkt (dropped 0, overlimits 0 requeues 0)
 rate 77000bit 40pps backlog 0b 0p requeues 0
 lended: 169588 borrowed: 106268 giants: 0
 tokens: -640970 ctokens: -9468

class htb 1:9 parent 1:2 leaf 9: prio 3 quantum 1125 rate 90000bit ceil
256000bit burst 1644b/8 mpu 0b overhead 0b cburst 1727b/8 mpu 0b overhead 0b
level 0
 Sent 153461796 bytes 164615 pkt (dropped 20, overlimits 0 requeues 0)
 rate 68848bit 24pps backlog 0b 0p requeues 0
 lended: 87614 borrowed: 77001 giants: 0
 tokens: 21231 ctokens: 46336




----- Original Message -----
From: "Andreas Klauer" <Andreas.Klauer@metamorpher.de>
To: <lartc@mailman.ds9a.nl>
Sent: Wednesday, September 28, 2005 6:35 PM
Subject: Re: [LARTC] Does HTB consider PRIO or not?

> On Wednesday 28 September 2005 17:18, Oleg R. wrote:
> > I suppose the second is getting the shared bandwidth in the last
> > place..but it is not so.
>
> Every class is allowed to use bandwidth as long as it does not have to
> borrow (the specified rate is guaranteed). Prio in HTB only affects
> borrowing bandwidth from other classes... In the example below, the class
> 1:5 should be allowed to borrow bandwidth before 1:14 does.
>
> > Some output from htb.init list
> >
> > qdisc htb 1: r2q 10 default 20 direct_packets_stat 119
> > class htb 1:5 parent 1:2 prio 1 rate 128000bit ceil 950000bit burst
> > 1663b cburst 2074b
> > class htb 1:14 parent 1:2 leaf 14: prio 7 rate 18000bit ceil 900000bit
> > burst 1608b cburst 2Kb
>
> The complete qdisc/class tree would be interesting. (Output of tc -s -d
> qdisc show and class show). Why are there pacekts in direct_packets_stat?
> Bad filter? What''s 1:2 and 14:?
>
> Andreas
>
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

On Wednesday 28 September 2005 18:03, Oleg R. wrote:
> Well the output is really big . The classes are 1:5 and 1:14...
Easier readable in this format:
http://img251.imageshack.us/img251/9497/dot6ux.png

I think it shows the problem very clearly... you have a root class with a 
total rate of 10000kbit. This class has a lot of children which have to 
share the bandwidth their parent class provides.

But, the child class shown below the root class (1:3) has a rate of 
10000kbit as well! So this class is already taking all of the available 
bandwidth, leaving exactly zero bandwidth for its siblings. However, since 
the siblings use rates greater than zero, you could say that the parent 
class is over-allocated.

HTB will compensate in this case, but the results are hard to predict.
And that''s probably why you are seeing bandwith distributed in a weird
way.

When creating a class tree, you should make sure that the children class 
rates added together match the parent class rate. So in your case, the 
root class 1:2 shouldn''t have a rate of 10000kbit, but 
10000kbit+2000kbit+192000bit+128000bit*4+... = something alot bigger than 
10000kbit.

HTH
Andreas

Hello again! Well, i should maybe post everything related to this problem.
The class 1:3 which has rate as its father 1:2, just because it is the
traffic between the local network and the server itself. I have some
services like mail, http, samba which I want to be accessed from local net
at  maximum speed. Now when you know the details,  could this be the real
problem ? I remember I deleted one time everything , remained only those two
classes , and it was the same thing. I just believe that this problem is
caused by a mistake, but I dont know which one. Its interesting, did anyone
configure the prio in htb and it worked..??

Andreas, how did you create such a descriptive image..is there a tool or
something??

----- Original Message -----
From: "Andreas Klauer" <Andreas.Klauer@metamorpher.de>
To: <lartc@mailman.ds9a.nl>
Sent: Wednesday, September 28, 2005 7:42 PM
Subject: Re: [LARTC] Re:Does HTB consider PRIO or not? 2

> On Wednesday 28 September 2005 18:03, Oleg R. wrote:
> > Well the output is really big . The classes are 1:5 and 1:14...
>
> Easier readable in this format:
> http://img251.imageshack.us/img251/9497/dot6ux.png
>
> I think it shows the problem very clearly... you have a root class with a
> total rate of 10000kbit. This class has a lot of children which have to
> share the bandwidth their parent class provides.
>
> But, the child class shown below the root class (1:3) has a rate of
> 10000kbit as well! So this class is already taking all of the available
> bandwidth, leaving exactly zero bandwidth for its siblings. However, since
> the siblings use rates greater than zero, you could say that the parent
> class is over-allocated.
>
> HTB will compensate in this case, but the results are hard to predict.
> And that''s probably why you are seeing bandwith distributed in a
weird
way.
>
> When creating a class tree, you should make sure that the children class
> rates added together match the parent class rate. So in your case, the
> root class 1:2 shouldn''t have a rate of 10000kbit, but
> 10000kbit+2000kbit+192000bit+128000bit*4+... = something alot bigger than
> 10000kbit.
>
> HTH
> Andreas
> _______________________________________________
> LARTC mailing list
> LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

On Thursday 29 September 2005 07:44, Oleg R. wrote:
> Hello again! Well, i should maybe post everything related to this
> problem. The class 1:3 which has rate as its father 1:2, just because it
> is the traffic between the local network and the server itself. I have
> some services like mail, http, samba which I want to be accessed from
> local net at  maximum speed. Now when you know the details,  could this
> be the real problem ?
I don''t know if that''s the only problem, but I think
it''s a problem. Unless
you really know and understand what HTB is doing when the children class 
rate exceed parent class rate, you shouldn''t do that.
> Its interesting, did anyone configure the prio in htb and it
> worked..??
So far I didn''t notice anything odd about prio (but I admit, I was not 
using it much). I prefer to set appropriate rates instead.
> Andreas, how did you create such a descriptive image..is there a tool or
> something??
Using this perl script: http://www.metamorpher.de/files/tc-graph.pl.txt
Based on Stef Coene''s show.pl which you can get from www.docum.org
This script already managed to cause kernel panics on some systems, so 
please use it at your own risk only.

It parses output from tc (I just used the output you sent instead), and 
creates a graph definition in dot format, which can be rendered to an 
image using the program ''dot'' from the GraphViz package which
you can get
here: http://www.graphviz.org/

Regards,
Andreas

On Thursday 29 September 2005 05:49, Andreas Klauer wrote:
<snip>
> Using this perl script: http://www.metamorpher.de/files/tc-graph.pl.txt
> Based on Stef Coene''s show.pl which you can get from www.docum.org
> This script already managed to cause kernel panics on some systems, so
> please use it at your own risk only.
Yes, I had that problem with earlier 2.6 kernels, but since 2.6.9 it seems to 
be fine.

-- 

Jason Boxman
http://edseek.com/ - Linux and FOSS stuff