Hello, I''m using HTB (through htb.init :) and it''s nearly perfect, but the CEIL directive seems to have no effect. The relevant lines are: tc qdisc add dev eth1 root handle 1 htb default 10 r2q 100 tc class add dev eth1 parent 1: classid 1:2 htb rate 5Mbit burst 15k tc class add dev eth1 parent 1:2 classid 1:40 htb rate 256Kbit ceil 512Kbit burst 15k tc qdisc add dev eth1 parent 1:40 handle 40 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 10.0.0.2 classid 1:40 - this allows 10.0.0.2 to download at 256Kbit, even when it is the only machine doing any downloading. I can affect this speed by changing the $rate, but changing $ceil has no effect whatsoever. Platform: RH7.2, 2.4.9-31 (patched for htb) tc patched for htb iproute2-ss001007 (Tried the patch for htb, but compilation failed with /usr/include/arpa/inet.h:74: warning: data definition has no type or storage class /usr/include/arpa/inet.h:78: parse error before `__net'' ) Is there something wrong with the above commands? Thanks, Gavin http://www.raha.com
On Friday 05 April 2002 10:19, Gavin wrote:> Hello, > > I''m using HTB (through htb.init :) and it''s nearly perfect, but the CEIL > directive seems to have no effect. > > The relevant lines are: > > tc qdisc add dev eth1 root handle 1 htb default 10 r2q 100 > tc class add dev eth1 parent 1: classid 1:2 htb rate 5Mbit burst 15k > tc class add dev eth1 parent 1:2 classid 1:40 htb rate 256Kbit ceil 512Kbit > burst 15k > tc qdisc add dev eth1 parent 1:40 handle 40 sfq perturb 10 > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst > 10.0.0.2 classid 1:40 > > - this allows 10.0.0.2 to download at 256Kbit, even when it is the only > machine doing any downloading. I can affect this speed by changing the > $rate, but changing $ceil has no effect whatsoever.The ceil will prevent 10.0.0.2 to download faster then 512 kbit. The rate will say how much 10.0.0.2 can download compare to the other classes (so the other lines are also relevant :). As example : If you have a second class : tc class add dev eth1 parent 1:2 classid 1:50 htb rate 256Kbit ceil 512Kbit burst 15k Then both classes will get 50% of the bandwidth if they are both downloading. If they are alone, they can get the 512 Kbit. Second example : tc class add dev eth1 parent 1:2 classid 1:50 htb rate 128Kbit ceil 512Kbit burst 15k Class 1:50 and class 1:40 are downloading -> class 1:40 will get 256 * (512/(256+128)) = 341 kbit and class 1:50 : 128 * (512/(256+128)) = 171 Kbit (they will devide the bandwidth compared to the rates). I hope you understand what you want I want to say and I hope it''s an answer on your question :) Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net
The full output of htp.init compile is this: tc qdisc del dev eth1 root tc qdisc add dev eth1 root handle 1 htb default 10 r2q 100 tc class add dev eth1 parent 1:2 classid 1:10 htb rate 2Mbit ceil 2Mbit burst 15k tc qdisc add dev eth1 parent 1:10 handle 10 sfq perturb 10 tc class add dev eth1 parent 1:2 classid 1:20 htb rate 1Mbit ceil 5Mbit burst 15k tc qdisc add dev eth1 parent 1:20 handle 20 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dport 25 0xffff classid 1:20 tc class add dev eth1 parent 1:2 classid 1:30 htb rate 512Kbit ceil 1Mbit burst 15k tc qdisc add dev eth1 parent 1:30 handle 30 sfq perturb 10 tc class add dev eth1 parent 1:2 classid 1:40 htb rate 256Kbit ceil 512Kbit burst 15k tc qdisc add dev eth1 parent 1:40 handle 40 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 10.0.0.2 classid 1:40 tc class add dev eth1 parent 1:2 classid 1:50 htb rate 128Kbit ceil 256Kbit burst 15k tc qdisc add dev eth1 parent 1:50 handle 50 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 10.0.0.150 classid 1:50 tc class add dev eth1 parent 1:2 classid 1:60 htb rate 64bit ceil 128bit burst 15k tc qdisc add dev eth1 parent 1:60 handle 60 sfq perturb 10 tc class add dev eth1 parent 1:2 classid 1:70 htb rate 32Kbit ceil 64Kbit burst 15k tc qdisc add dev eth1 parent 1:70 handle 70 sfq perturb 10 tc class add dev eth1 parent 1:2 classid 1:80 htb rate 16bit ceil 32bit burst 15k tc qdisc add dev eth1 parent 1:80 handle 80 sfq perturb 10 tc class add dev eth1 parent 1:2 classid 1:90 htb rate 8Kbit ceil 16Kbit burst 15k tc qdisc add dev eth1 parent 1:90 handle 90 sfq perturb 10 tc class add dev eth1 parent 1: classid 1:2 htb rate 5Mbit burst 15k - the only classes with any filters are 1:40(256Kbit/512kKbit) for 10.0.0.2 and 1:50(128Kbit/256Kbit) for 10.0.0.150. I just ran some more tests, and 10.0.0.150 can still only get 128Kbit Am I seriously misunderstanding how this works? ----- Original Message ----- From: "Stef Coene" <stef.coene@docum.org> To: "Gavin" <gavin@raha.com>; <LARTC@mailman.ds9a.nl> Sent: Friday, April 05, 2002 11:42 AM Subject: Re: [LARTC] htb ceiling On Friday 05 April 2002 10:19, Gavin wrote:> Hello, > > I''m using HTB (through htb.init :) and it''s nearly perfect, but the CEIL > directive seems to have no effect. > > The relevant lines are: > > tc qdisc add dev eth1 root handle 1 htb default 10 r2q 100 > tc class add dev eth1 parent 1: classid 1:2 htb rate 5Mbit burst 15k > tc class add dev eth1 parent 1:2 classid 1:40 htb rate 256Kbit ceil512Kbit> burst 15k > tc qdisc add dev eth1 parent 1:40 handle 40 sfq perturb 10 > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst > 10.0.0.2 classid 1:40 > > - this allows 10.0.0.2 to download at 256Kbit, even when it is the only > machine doing any downloading. I can affect this speed by changing the > $rate, but changing $ceil has no effect whatsoever.The ceil will prevent 10.0.0.2 to download faster then 512 kbit. The rate will say how much 10.0.0.2 can download compare to the other classes (so the other lines are also relevant :). As example : If you have a second class : tc class add dev eth1 parent 1:2 classid 1:50 htb rate 256Kbit ceil 512Kbit burst 15k Then both classes will get 50% of the bandwidth if they are both downloading. If they are alone, they can get the 512 Kbit. Second example : tc class add dev eth1 parent 1:2 classid 1:50 htb rate 128Kbit ceil 512Kbit burst 15k Class 1:50 and class 1:40 are downloading -> class 1:40 will get 256 * (512/(256+128)) = 341 kbit and class 1:50 : 128 * (512/(256+128)) = 171 Kbit (they will devide the bandwidth compared to the rates). I hope you understand what you want I want to say and I hope it''s an answer on your question :) Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net
> > tc qdisc add dev eth1 root handle 1 htb default 10 r2q 100 > > tc class add dev eth1 parent 1: classid 1:2 htb rate 5Mbit burst 15k > > tc class add dev eth1 parent 1:2 classid 1:40 htb rate 256Kbit ceil 512Kbit > > burst 15k > > tc qdisc add dev eth1 parent 1:40 handle 40 sfq perturb 10 > > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst > > 10.0.0.2 classid 1:40 > > > > - this allows 10.0.0.2 to download at 256Kbit, even when it is the only > > machine doing any downloading. I can affect this speed by changing the > > $rate, but changing $ceil has no effect whatsoever. > The ceil will prevent 10.0.0.2 to download faster then 512 kbit. The rate > will say how much 10.0.0.2 can download compare to the other classes (so the > other lines are also relevant :).No Stef, the rate is really measured - it is used as source for DRR weight (here it is used relative to other classes) and to see whether we need to borrow from parent - here absolute value matters. So that the example above should work and give 512k. Gavin, did you tried with only these classes present ? (to have maximaly simplified configuration which exhibits it). If yes and it really does only 256k then post tc -s {qdisc,class} show dev ethXX outputs ... as usual devik
I tried it with a minimal config - two classes, each with rate: 256Kbit and ceiling: 512Kbit and one dest. IP address in each, as well as a default class. Each specified machine could only pull 256Kbit maximum, either alone or with the other downloading as well. Output of tc -s qdisc show dev eth1: qdisc sfq 50: quantum 1514b perturb 10sec Sent 7506464 bytes 4984 pkts (dropped 0, overlimits 0) backlog 6p qdisc sfq 40: quantum 1514b perturb 10sec Sent 4275617 bytes 2829 pkts (dropped 0, overlimits 0) backlog 3p qdisc sfq 10: quantum 1514b perturb 10sec Sent 287102 bytes 542 pkts (dropped 0, overlimits 0) qdisc htb 1: r2q 100 default 10 dcache 0 deq_util 1/1000000 deq_rate 125 trials_per_deq 0 dcache_hits 0 direct_packets 0 Sent 12069183 bytes 8355 pkts (dropped 0, overlimits 15537) backlog 9p Output of tc -s class show dev eth1: class htb 1:10 root leaf 10: prio 0 rate 2Mbit ceil 2Mbit burst 15Kb cburst 4220b Sent 331368 bytes 678 pkts (dropped 0, overlimits 32) rate 107bps lended: 678 borrowed: 0 giants: 0 injects: 0 tokens: 47825 ctokens: 13015 class htb 1:2 root prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 8151b Sent 0 bytes 0 pkts (dropped 0, overlimits 0) lended: 0 borrowed: 0 giants: 0 injects: 0 tokens: 19199 ctokens: 10190 class htb 1:40 root leaf 40: prio 0 rate 256Kbit ceil 512Kbit burst 15Kb cburst 2254b Sent 4275671 bytes 2830 pkts (dropped 0, overlimits 0) rate 226bps lended: 2830 borrowed: 0 giants: 0 injects: 0 tokens: 382801 ctokens: 27588 class htb 1:50 root leaf 50: prio 0 rate 256Kbit ceil 512Kbit burst 15Kb cburst 2254b Sent 8214460 bytes 5467 pkts (dropped 0, overlimits 0) rate 546bps lended: 5467 borrowed: 0 giants: 0 injects: 0 tokens: 382801 ctokens: 27588 Output of htb.init compile: tc qdisc del dev eth1 root tc qdisc add dev eth1 root handle 1 htb default 10 r2q 100 tc class add dev eth1 parent 1:2 classid 1:10 htb rate 2Mbit ceil 2Mbit burst 15k tc qdisc add dev eth1 parent 1:10 handle 10 sfq perturb 10 tc class add dev eth1 parent 1:2 classid 1:40 htb rate 256Kbit ceil 512Kbit burst 15k tc qdisc add dev eth1 parent 1:40 handle 40 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 10.0.0.20 classid 1:40 tc class add dev eth1 parent 1:2 classid 1:50 htb rate 256Kbit ceil 512Kbit burst 15k tc qdisc add dev eth1 parent 1:50 handle 50 sfq perturb 10 tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst 10.0.0.150 classid 1:50 tc class add dev eth1 parent 1: classid 1:2 htb rate 5Mbit burst 15k Gavin ----- Original Message ----- From: "Martin Devera" <devik@cdi.cz> To: "Stef Coene" <stef.coene@docum.org> Cc: "Gavin" <gavin@raha.com>; <LARTC@mailman.ds9a.nl> Sent: Friday, April 05, 2002 1:40 PM Subject: Re: [LARTC] htb ceiling> > > tc qdisc add dev eth1 root handle 1 htb default 10 r2q 100 > > > tc class add dev eth1 parent 1: classid 1:2 htb rate 5Mbit burst 15k > > > tc class add dev eth1 parent 1:2 classid 1:40 htb rate 256Kbit ceil512Kbit> > > burst 15k > > > tc qdisc add dev eth1 parent 1:40 handle 40 sfq perturb 10 > > > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ipdst> > > 10.0.0.2 classid 1:40 > > > > > > - this allows 10.0.0.2 to download at 256Kbit, even when it is theonly> > > machine doing any downloading. I can affect this speed by changingthe> > > $rate, but changing $ceil has no effect whatsoever. > > The ceil will prevent 10.0.0.2 to download faster then 512 kbit. Therate> > will say how much 10.0.0.2 can download compare to the other classes (sothe> > other lines are also relevant :). > > No Stef, > the rate is really measured - it is used as source for DRR weight > (here it is used relative to other classes) and to see whether we > need to borrow from parent - here absolute value matters. > So that the example above should work and give 512k. > > Gavin, did you tried with only these classes present ? (to have > maximaly simplified configuration which exhibits it). > If yes and it really does only 256k then post > tc -s {qdisc,class} show dev ethXX outputs ... as usual > devik > >
you have error in conf. As you can see class 1:40 and 1:50 are added to the root not as 1:2 children. The output of htb.init is wrong - you can see that it uses 1:2 class before it demands its create ... I don''t know htb.init - you will have to contact maintainer with bugrerport probably ;) devik On Fri, 5 Apr 2002, Gavin wrote:> I tried it with a minimal config - two classes, each with rate: 256Kbit and > ceiling: 512Kbit and one dest. IP address in each, as well as a default > class. Each specified machine could only pull 256Kbit maximum, either alone > or with the other downloading as well. > > Output of tc -s qdisc show dev eth1: > > qdisc sfq 50: quantum 1514b perturb 10sec > Sent 7506464 bytes 4984 pkts (dropped 0, overlimits 0) > backlog 6p > > qdisc sfq 40: quantum 1514b perturb 10sec > Sent 4275617 bytes 2829 pkts (dropped 0, overlimits 0) > backlog 3p > > qdisc sfq 10: quantum 1514b perturb 10sec > Sent 287102 bytes 542 pkts (dropped 0, overlimits 0) > > qdisc htb 1: r2q 100 default 10 dcache 0 > deq_util 1/1000000 deq_rate 125 trials_per_deq 0 > dcache_hits 0 direct_packets 0 > Sent 12069183 bytes 8355 pkts (dropped 0, overlimits 15537) > backlog 9p > > > Output of tc -s class show dev eth1: > > class htb 1:10 root leaf 10: prio 0 rate 2Mbit ceil 2Mbit burst 15Kb cburst > 4220b > Sent 331368 bytes 678 pkts (dropped 0, overlimits 32) > rate 107bps > lended: 678 borrowed: 0 giants: 0 injects: 0 > tokens: 47825 ctokens: 13015 > > class htb 1:2 root prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 8151b > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > lended: 0 borrowed: 0 giants: 0 injects: 0 > tokens: 19199 ctokens: 10190 > > class htb 1:40 root leaf 40: prio 0 rate 256Kbit ceil 512Kbit burst 15Kb > cburst 2254b > Sent 4275671 bytes 2830 pkts (dropped 0, overlimits 0) > rate 226bps > lended: 2830 borrowed: 0 giants: 0 injects: 0 > tokens: 382801 ctokens: 27588 > > class htb 1:50 root leaf 50: prio 0 rate 256Kbit ceil 512Kbit burst 15Kb > cburst 2254b > Sent 8214460 bytes 5467 pkts (dropped 0, overlimits 0) > rate 546bps > lended: 5467 borrowed: 0 giants: 0 injects: 0 > tokens: 382801 ctokens: 27588 > > Output of htb.init compile: > > tc qdisc del dev eth1 root > tc qdisc add dev eth1 root handle 1 htb default 10 r2q 100 > > tc class add dev eth1 parent 1:2 classid 1:10 htb rate 2Mbit ceil 2Mbit > burst 15k > tc qdisc add dev eth1 parent 1:10 handle 10 sfq perturb 10 > > tc class add dev eth1 parent 1:2 classid 1:40 htb rate 256Kbit ceil 512Kbit > burst 15k > tc qdisc add dev eth1 parent 1:40 handle 40 sfq perturb 10 > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst > 10.0.0.20 classid 1:40 > > tc class add dev eth1 parent 1:2 classid 1:50 htb rate 256Kbit ceil 512Kbit > burst 15k > tc qdisc add dev eth1 parent 1:50 handle 50 sfq perturb 10 > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst > 10.0.0.150 classid 1:50 > > tc class add dev eth1 parent 1: classid 1:2 htb rate 5Mbit burst 15k > > > > Gavin > > > ----- Original Message ----- > From: "Martin Devera" <devik@cdi.cz> > To: "Stef Coene" <stef.coene@docum.org> > Cc: "Gavin" <gavin@raha.com>; <LARTC@mailman.ds9a.nl> > Sent: Friday, April 05, 2002 1:40 PM > Subject: Re: [LARTC] htb ceiling > > > > > > tc qdisc add dev eth1 root handle 1 htb default 10 r2q 100 > > > > tc class add dev eth1 parent 1: classid 1:2 htb rate 5Mbit burst 15k > > > > tc class add dev eth1 parent 1:2 classid 1:40 htb rate 256Kbit ceil > 512Kbit > > > > burst 15k > > > > tc qdisc add dev eth1 parent 1:40 handle 40 sfq perturb 10 > > > > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip > dst > > > > 10.0.0.2 classid 1:40 > > > > > > > > - this allows 10.0.0.2 to download at 256Kbit, even when it is the > only > > > > machine doing any downloading. I can affect this speed by changing > the > > > > $rate, but changing $ceil has no effect whatsoever. > > > The ceil will prevent 10.0.0.2 to download faster then 512 kbit. The > rate > > > will say how much 10.0.0.2 can download compare to the other classes (so > the > > > other lines are also relevant :). > > > > No Stef, > > the rate is really measured - it is used as source for DRR weight > > (here it is used relative to other classes) and to see whether we > > need to borrow from parent - here absolute value matters. > > So that the example above should work and give 512k. > > > > Gavin, did you tried with only these classes present ? (to have > > maximaly simplified configuration which exhibits it). > > If yes and it really does only 256k then post > > tc -s {qdisc,class} show dev ethXX outputs ... as usual > > devik > > > > > > >
> No Stef, > the rate is really measured - it is used as source for DRR weight > (here it is used relative to other classes) and to see whether we > need to borrow from parent - here absolute value matters. > So that the example above should work and give 512k.So each class gets it''s rate if it can by borrowing from the parent ? But what if the parent has more bandwidth then the rate of the classes? Isn''t the remaining bandwith given to the classes compared with the rates ? What happens of the sum of the rates of the child classes is bigger then the rate of the parent or even the ceil of the parent ? Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net
On Friday 05 April 2002 14:10, Martin Devera wrote:> you have error in conf. As you can see class 1:40 and 1:50 are > added to the root not as 1:2 children. > The output of htb.init is wrong - you can see that it uses 1:2 > class before it demands its create ... > I don''t know htb.init - you will have to contact maintainer > with bugrerport probably ;)I know it neither, but I think there is a parent option so you can specify the parent of the class. In your case this is 1:2 Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net
Ah, sweet. I just ran htb.init compile and moved the last line (tc class add dev eth1 parent 1: classid 1:2 htb rate 5Mbit burst 15k) to the third line, then ran it, and all was well. Thanks Martin and Stef, Gavin ----- Original Message ----- From: "Martin Devera" <devik@cdi.cz> To: "Gavin" <gavin@raha.com> Cc: "Stef Coene" <stef.coene@docum.org>; <LARTC@mailman.ds9a.nl> Sent: Friday, April 05, 2002 3:10 PM Subject: Re: [LARTC] htb ceiling> you have error in conf. As you can see class 1:40 and 1:50 are > added to the root not as 1:2 children. > The output of htb.init is wrong - you can see that it uses 1:2 > class before it demands its create ... > I don''t know htb.init - you will have to contact maintainer > with bugrerport probably ;) > devik > > On Fri, 5 Apr 2002, Gavin wrote: > > > I tried it with a minimal config - two classes, each with rate: 256Kbitand> > ceiling: 512Kbit and one dest. IP address in each, as well as a default > > class. Each specified machine could only pull 256Kbit maximum, eitheralone> > or with the other downloading as well. > > > > Output of tc -s qdisc show dev eth1: > > > > qdisc sfq 50: quantum 1514b perturb 10sec > > Sent 7506464 bytes 4984 pkts (dropped 0, overlimits 0) > > backlog 6p > > > > qdisc sfq 40: quantum 1514b perturb 10sec > > Sent 4275617 bytes 2829 pkts (dropped 0, overlimits 0) > > backlog 3p > > > > qdisc sfq 10: quantum 1514b perturb 10sec > > Sent 287102 bytes 542 pkts (dropped 0, overlimits 0) > > > > qdisc htb 1: r2q 100 default 10 dcache 0 > > deq_util 1/1000000 deq_rate 125 trials_per_deq 0 > > dcache_hits 0 direct_packets 0 > > Sent 12069183 bytes 8355 pkts (dropped 0, overlimits 15537) > > backlog 9p > > > > > > Output of tc -s class show dev eth1: > > > > class htb 1:10 root leaf 10: prio 0 rate 2Mbit ceil 2Mbit burst 15Kbcburst> > 4220b > > Sent 331368 bytes 678 pkts (dropped 0, overlimits 32) > > rate 107bps > > lended: 678 borrowed: 0 giants: 0 injects: 0 > > tokens: 47825 ctokens: 13015 > > > > class htb 1:2 root prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 8151b > > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > > lended: 0 borrowed: 0 giants: 0 injects: 0 > > tokens: 19199 ctokens: 10190 > > > > class htb 1:40 root leaf 40: prio 0 rate 256Kbit ceil 512Kbit burst 15Kb > > cburst 2254b > > Sent 4275671 bytes 2830 pkts (dropped 0, overlimits 0) > > rate 226bps > > lended: 2830 borrowed: 0 giants: 0 injects: 0 > > tokens: 382801 ctokens: 27588 > > > > class htb 1:50 root leaf 50: prio 0 rate 256Kbit ceil 512Kbit burst 15Kb > > cburst 2254b > > Sent 8214460 bytes 5467 pkts (dropped 0, overlimits 0) > > rate 546bps > > lended: 5467 borrowed: 0 giants: 0 injects: 0 > > tokens: 382801 ctokens: 27588 > > > > Output of htb.init compile: > > > > tc qdisc del dev eth1 root > > tc qdisc add dev eth1 root handle 1 htb default 10 r2q 100 > > > > tc class add dev eth1 parent 1:2 classid 1:10 htb rate 2Mbit ceil 2Mbit > > burst 15k > > tc qdisc add dev eth1 parent 1:10 handle 10 sfq perturb 10 > > > > tc class add dev eth1 parent 1:2 classid 1:40 htb rate 256Kbit ceil512Kbit> > burst 15k > > tc qdisc add dev eth1 parent 1:40 handle 40 sfq perturb 10 > > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst > > 10.0.0.20 classid 1:40 > > > > tc class add dev eth1 parent 1:2 classid 1:50 htb rate 256Kbit ceil512Kbit> > burst 15k > > tc qdisc add dev eth1 parent 1:50 handle 50 sfq perturb 10 > > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst > > 10.0.0.150 classid 1:50 > > > > tc class add dev eth1 parent 1: classid 1:2 htb rate 5Mbit burst 15k > > > > > > > > Gavin > > > > > > ----- Original Message ----- > > From: "Martin Devera" <devik@cdi.cz> > > To: "Stef Coene" <stef.coene@docum.org> > > Cc: "Gavin" <gavin@raha.com>; <LARTC@mailman.ds9a.nl> > > Sent: Friday, April 05, 2002 1:40 PM > > Subject: Re: [LARTC] htb ceiling > > > > > > > > > tc qdisc add dev eth1 root handle 1 htb default 10 r2q 100 > > > > > tc class add dev eth1 parent 1: classid 1:2 htb rate 5Mbit burst15k> > > > > tc class add dev eth1 parent 1:2 classid 1:40 htb rate 256Kbitceil> > 512Kbit > > > > > burst 15k > > > > > tc qdisc add dev eth1 parent 1:40 handle 40 sfq perturb 10 > > > > > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 matchip> > dst > > > > > 10.0.0.2 classid 1:40 > > > > > > > > > > - this allows 10.0.0.2 to download at 256Kbit, even when it isthe> > only > > > > > machine doing any downloading. I can affect this speed bychanging> > the > > > > > $rate, but changing $ceil has no effect whatsoever. > > > > The ceil will prevent 10.0.0.2 to download faster then 512 kbit.The> > rate > > > > will say how much 10.0.0.2 can download compare to the other classes(so> > the > > > > other lines are also relevant :). > > > > > > No Stef, > > > the rate is really measured - it is used as source for DRR weight > > > (here it is used relative to other classes) and to see whether we > > > need to borrow from parent - here absolute value matters. > > > So that the example above should work and give 512k. > > > > > > Gavin, did you tried with only these classes present ? (to have > > > maximaly simplified configuration which exhibits it). > > > If yes and it really does only 256k then post > > > tc -s {qdisc,class} show dev ethXX outputs ... as usual > > > devik > > > > > > > > > > > > > >
> > the rate is really measured - it is used as source for DRR weight > > (here it is used relative to other classes) and to see whether we > > need to borrow from parent - here absolute value matters. > > So that the example above should work and give 512k.> So each class gets it''s rate if it can by borrowing from the parent ? > But what if the parent has more bandwidth then the rate of the classes? > Isn''t the remaining bandwith given to the classes compared with the rates ? > > What happens of the sum of the rates of the child classes is bigger then the > rate of the parent or even the ceil of the parent ?You can view it as system where all of these hold: 1. each class first uses all of its (absolute) "rate" 2. if there is no such class then each class can use part of parents rate if ceil allows for it and 3. the "parts" of the same parent are balanced according to relative values of children rates Now, Gavin''s conf: C1[r,c=2000]-->C2[r=256,c=512] is simple to explain: According to rule 1. C2 will always use at least 256k (even if C1''s rate were accidentaly 0). If it already uses 256k and there is still demand for more then 2. allows you to use up to 512k. There is no competiting child of C1 so C2 will get 512k forever. Clear ? devik
> You can view it as system where all of these hold: > > 1. each class first uses all of its (absolute) "rate" > 2. if there is no such class then each class can use part > of parents rate if ceil allows for it and > 3. the "parts" of the same parent are balanced according > to relative values of children rates > > Now, Gavin''s conf: C1[r,c=2000]-->C2[r=256,c=512] is simple > to explain: > According to rule 1. C2 will always use at least 256k (even > if C1''s rate were accidentaly 0). If it already uses 256k > and there is still demand for more then 2. allows you to > use up to 512k. There is no competiting child of C1 so > C2 will get 512k forever. > > Clear ?Very clear :) Thx Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.openprojects.net
Lubomir Bulej has now released v0.8.3 of his excellent htb.init script which fixes the problem with the ordering of the output. Gavin ----- Original Message ----- From: "Martin Devera" <devik@cdi.cz> To: "Gavin" <gavin@raha.com> Cc: "Stef Coene" <stef.coene@docum.org>; <LARTC@mailman.ds9a.nl> Sent: Friday, April 05, 2002 3:10 PM Subject: Re: [LARTC] htb ceiling> you have error in conf. As you can see class 1:40 and 1:50 are > added to the root not as 1:2 children. > The output of htb.init is wrong - you can see that it uses 1:2 > class before it demands its create ... > I don''t know htb.init - you will have to contact maintainer > with bugrerport probably ;) > devik > > On Fri, 5 Apr 2002, Gavin wrote: > > > I tried it with a minimal config - two classes, each with rate: 256Kbitand> > ceiling: 512Kbit and one dest. IP address in each, as well as a default > > class. Each specified machine could only pull 256Kbit maximum, eitheralone> > or with the other downloading as well. > > > > Output of tc -s qdisc show dev eth1: > > > > qdisc sfq 50: quantum 1514b perturb 10sec > > Sent 7506464 bytes 4984 pkts (dropped 0, overlimits 0) > > backlog 6p > > > > qdisc sfq 40: quantum 1514b perturb 10sec > > Sent 4275617 bytes 2829 pkts (dropped 0, overlimits 0) > > backlog 3p > > > > qdisc sfq 10: quantum 1514b perturb 10sec > > Sent 287102 bytes 542 pkts (dropped 0, overlimits 0) > > > > qdisc htb 1: r2q 100 default 10 dcache 0 > > deq_util 1/1000000 deq_rate 125 trials_per_deq 0 > > dcache_hits 0 direct_packets 0 > > Sent 12069183 bytes 8355 pkts (dropped 0, overlimits 15537) > > backlog 9p > > > > > > Output of tc -s class show dev eth1: > > > > class htb 1:10 root leaf 10: prio 0 rate 2Mbit ceil 2Mbit burst 15Kbcburst> > 4220b > > Sent 331368 bytes 678 pkts (dropped 0, overlimits 32) > > rate 107bps > > lended: 678 borrowed: 0 giants: 0 injects: 0 > > tokens: 47825 ctokens: 13015 > > > > class htb 1:2 root prio 0 rate 5Mbit ceil 5Mbit burst 15Kb cburst 8151b > > Sent 0 bytes 0 pkts (dropped 0, overlimits 0) > > lended: 0 borrowed: 0 giants: 0 injects: 0 > > tokens: 19199 ctokens: 10190 > > > > class htb 1:40 root leaf 40: prio 0 rate 256Kbit ceil 512Kbit burst 15Kb > > cburst 2254b > > Sent 4275671 bytes 2830 pkts (dropped 0, overlimits 0) > > rate 226bps > > lended: 2830 borrowed: 0 giants: 0 injects: 0 > > tokens: 382801 ctokens: 27588 > > > > class htb 1:50 root leaf 50: prio 0 rate 256Kbit ceil 512Kbit burst 15Kb > > cburst 2254b > > Sent 8214460 bytes 5467 pkts (dropped 0, overlimits 0) > > rate 546bps > > lended: 5467 borrowed: 0 giants: 0 injects: 0 > > tokens: 382801 ctokens: 27588 > > > > Output of htb.init compile: > > > > tc qdisc del dev eth1 root > > tc qdisc add dev eth1 root handle 1 htb default 10 r2q 100 > > > > tc class add dev eth1 parent 1:2 classid 1:10 htb rate 2Mbit ceil 2Mbit > > burst 15k > > tc qdisc add dev eth1 parent 1:10 handle 10 sfq perturb 10 > > > > tc class add dev eth1 parent 1:2 classid 1:40 htb rate 256Kbit ceil512Kbit> > burst 15k > > tc qdisc add dev eth1 parent 1:40 handle 40 sfq perturb 10 > > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst > > 10.0.0.20 classid 1:40 > > > > tc class add dev eth1 parent 1:2 classid 1:50 htb rate 256Kbit ceil512Kbit> > burst 15k > > tc qdisc add dev eth1 parent 1:50 handle 50 sfq perturb 10 > > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 match ip dst > > 10.0.0.150 classid 1:50 > > > > tc class add dev eth1 parent 1: classid 1:2 htb rate 5Mbit burst 15k > > > > > > > > Gavin > > > > > > ----- Original Message ----- > > From: "Martin Devera" <devik@cdi.cz> > > To: "Stef Coene" <stef.coene@docum.org> > > Cc: "Gavin" <gavin@raha.com>; <LARTC@mailman.ds9a.nl> > > Sent: Friday, April 05, 2002 1:40 PM > > Subject: Re: [LARTC] htb ceiling > > > > > > > > > tc qdisc add dev eth1 root handle 1 htb default 10 r2q 100 > > > > > tc class add dev eth1 parent 1: classid 1:2 htb rate 5Mbit burst15k> > > > > tc class add dev eth1 parent 1:2 classid 1:40 htb rate 256Kbitceil> > 512Kbit > > > > > burst 15k > > > > > tc qdisc add dev eth1 parent 1:40 handle 40 sfq perturb 10 > > > > > tc filter add dev eth1 parent 1:0 protocol ip prio 100 u32 matchip> > dst > > > > > 10.0.0.2 classid 1:40 > > > > > > > > > > - this allows 10.0.0.2 to download at 256Kbit, even when it isthe> > only > > > > > machine doing any downloading. I can affect this speed bychanging> > the > > > > > $rate, but changing $ceil has no effect whatsoever. > > > > The ceil will prevent 10.0.0.2 to download faster then 512 kbit.The> > rate > > > > will say how much 10.0.0.2 can download compare to the other classes(so> > the > > > > other lines are also relevant :). > > > > > > No Stef, > > > the rate is really measured - it is used as source for DRR weight > > > (here it is used relative to other classes) and to see whether we > > > need to borrow from parent - here absolute value matters. > > > So that the example above should work and give 512k. > > > > > > Gavin, did you tried with only these classes present ? (to have > > > maximaly simplified configuration which exhibits it). > > > If yes and it really does only 256k then post > > > tc -s {qdisc,class} show dev ethXX outputs ... as usual > > > devik > > > > > > > > > > > > > >
Hi,
We are testing some hybrid Diffserv-Intserv architectures and due to
problems with some testing, we eventually tried to do a very simple test -
Send traffic between the two machines (M1, M2) with an ingress policer on
the destination machine.
However there is a catch:
1. M1 is a high speed machine (PIII, 1 Ghz, 1Gb RAM)
2. M2 is a low speed machine (PPro, 200Mhz, 128 Mb RAM)
We are sending about 7.8 Mbps of traffic with 1472 byte packets (we are
using realtime patches to Linux for this)
This is our policer config string:
$TC filter add dev $DEVICE parent ffff: protocol ip prio 50 rsvp ipproto
udp session 129.237.125.147/9001 police rate 1043872bps burst 1515 drop
flowid :1
Scenario 1: M2 sending to M1
----------------------------
Many packets (22%) are marked as ''out of profile'' and dropped
by the
policer on M1
Scenario 2: M1 sending to M2
----------------------------
M2 recieves about 98% packets, but those that are recieved are
''in-profile''
These results are a little puzzling, since in Scenario 1, if anything, we
would have expected M2 to be able to process everything quickly.
And in Scenario 2, if anything, we would have expected out-of-profile
packets since M2 would get swamped (being a slower machine)
Can anybody explain reasons for this behaviour? Anybody with benchmarks on
CPU/Mem usage for different kinds of traffic?
Regards,
Amit
--
I''m an angel!!! Honest!
The horns are just there to hold the halo up straight.
^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^
Amit Kucheria
EECS Grad. Research Assistant
University of Kansas @ Lawrence
(R)+1-(785)-830 8521 ||| (O)+1-(785)-864 7774
____________________________________________________
Amit Kucheria
2002-Apr-19 18:39 UTC
exchange of pkts between devices on the same machine (crosspost)
Hi,
Sorry for the crosspost, since this seems to concern all lists.
I know that when two network devices exist on the same machine, then pkts
with dev1 as source and dev2 as destination are resolved at the IP layer,
without sending them down to the link layer through traffic control.
What could i do, if i wanted such packets to go down to the Traffic
control layer before coming back up? Has anybody implemented this?
I have two software devices on the same machine which want to exchange
pkts *but* after passing the traffic control code.
TIA.
ciao,
Amit
--
I''m an angel!!! Honest!
The horns are just there to hold the halo up straight.
^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^-^
Amit Kucheria
EECS Grad. Research Assistant
University of Kansas @ Lawrence
(R)+1-(785)-830 8521 ||| (O)+1-(785)-864 7774
____________________________________________________