hi all, am testing htb3 with imq. i have read the mannuals & have the follwoing script for a test bed. $htb qdisc add dev imq0 root handle 2: htb $htb class add dev imq0 parent 2: classid 2:1 htb rate 10mbit $htb class add dev imq0 parent 2:1 classid 2:10 htb rate 64kbit ceil 72kbit $htb class add dev imq0 parent 2:1 classid 2:20 htb rate 64kbit ceil 70kbit ##### -- define for groupA $htb class add dev imq0 parent 2:10 classid 2:1010 htb quantum 40960 rate 36kbit ceil 44kbit $htb class add dev imq0 parent 2:10 classid 2:1011 htb quantum 4096 rate 36kbit ceil 46kbit ##### -- define for groupB $htb class add dev imq0 parent 2:20 classid 2:2020 htb quantum 1096 rate 36kbit ceil 42kbit $htb class add dev imq0 parent 2:20 classid 2:2021 htb quantum 1096 rate 36kbit ceil 46kbit $htb qdisc add dev imq0 parent 2:1010 handle 20 sfq perturb 5 $htb qdisc add dev imq0 parent 2:1011 handle 21 sfq perturb 5 $htb qdisc add dev imq0 parent 2:2020 handle 22 pfifo limit 2 $htb qdisc add dev imq0 parent 2:2021 handle 23 pfifo limit 2 the quantum were added as the default taken reported error to be *TOO* small... am getting this errors in log file... Aug 10 01:05:32 Lr1 kernel: HTB init, kernel part version 3.6 Aug 10 01:05:32 Lr1 kernel: HTB: quantum of class 20010 is small. Consider r2q change.<4>HTB: quantum of class 20020 is small. Consider r2q change.nf_hook: Verdict = QUEUE. Aug 10 01:05:32 Lr1 kernel: nf_hook: Verdict = QUEUE. Aug 10 01:06:03 Lr1 last message repeated 2297 times the mannual says >>> "..Normaly you don''t need to specify quantums manualy as HTB chooses precomputed values. It computes classe''s quantum (when you add or change it) as its rate divided by r2q global parameter... " why in thiscase the default quabum reported error/taken too small ? can u please elaborate on r2q... how is it calculated, as the mannual says default value 10 ! what does these error signifies?.. thanking in advance A.H _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> $htb class add dev imq0 parent 2:20 classid 2:2020 htb quantum 1096 rate > 36kbit ceil 42kbit > $htb class add dev imq0 parent 2:20 classid 2:2021 htb quantum 1096 rate > 36kbit ceil 46kbit> the mannual says >>> "..Normaly you don''t need to specify quantums > manualy as HTB chooses precomputed values. It computes classe''s quantum > (when you add or change it) as its rate divided by r2q global parameter... > " why in thiscase the default quabum reported error/taken too small ? can u > please elaborate on r2q... how is it calculated, as the mannual says > default value 10 ! > what does these error signifies?..Each class can send quantum bytes at a time. You specified quantum = 1096 wich is bigger then the MTU (mostly 1500). If you have a big packet of 1500 byte and a quantum of 1096 byte, you are only allowed to send 1096 byte. But the packet is sended anyway and a warning message is logged. Quantum is calculated as rate / r2q. r2q iq by default 10 and can be overruled if you create the heb qdisc. Quantum can be overruled when you add a class. You should choose r2q so that the class with the smallest rate has a quantum equal to MTU. Because quantum is used by each class to send quantum bytes at a time, you should take quantum proportional to the rate so each class is getting the bandwidth you want to get it. So leaving quantum untouched, but changing r2q is a good choice. Taking too big quantums can cause delays. All classes can send it''s quantum bytes before the first class may send again. So how bigger the quantum, the longer it takes before a class can send again. I have some more info about it on www.docum.org on the faq page. But not so much as I typed now :) Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> Each class can send quantum bytes at a time. You specified quantum = 1096 > wich is bigger then the MTU (mostly 1500). If you have a big packet of 1500 > byte and a quantum of 1096 byte, you are only allowed to send 1096 byte. But > the packet is sended anyway and a warning message is logged. > > Quantum is calculated as rate / r2q. r2q iq by default 10 and can be > overruled if you create the heb qdisc. Quantum can be overruled when you add > a class.Stef thanx to you so much.. whats an "heb qdisc". am sorry but i really dont know anything about it. if u can give a little more detail pls. :) log message generated now is--> Aug 10 04:12:05 Lr1 kernel: nf_hook: Verdict = QUEUE. Aug 10 04:12:36 Lr1 last message repeated 5614 times Aug 10 04:13:37 Lr1 last message repeated 12355 times Aug 10 04:14:38 Lr1 last message repeated 12845 times why this log message appears every minute ??.. is it due to packets are being send to the imq QUEUE ie its queueing ?? thanking in advance A.H _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Saturday 10 August 2002 06:46, Arindam Haldar wrote:> > Each class can send quantum bytes at a time. You specified quantum > > 1096 wich is bigger then the MTU (mostly 1500). If you have a big packet > > of 1500 byte and a quantum of 1096 byte, you are only allowed to send > > 1096 byte. But the packet is sended anyway and a warning message is > > logged. > > > > Quantum is calculated as rate / r2q. r2q iq by default 10 and can be > > overruled if you create the heb qdisc. Quantum can be overruled when you > > add a class. > > Stef thanx to you so much.. > whats an "heb qdisc". am sorry but i really dont know anything about it. > if u can give a little more detail pls. :)It''s a typo :) I meant the disc.> > log message generated now is--> > Aug 10 04:12:05 Lr1 kernel: nf_hook: Verdict = QUEUE. > Aug 10 04:12:36 Lr1 last message repeated 5614 times > Aug 10 04:13:37 Lr1 last message repeated 12355 times > Aug 10 04:14:38 Lr1 last message repeated 12845 times > > why this log message appears every minute ??.. is it due to packets are > being send to the imq QUEUE ie its queueing ??I think so. I''m not sure. Maybe you can search the imq page for a way to disabling this message or for an explanation of the message. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hello Arindam, See imq faq http://luxik.cdi.cz/~patrick/imq/faq.html Saturday, August 10, 2002, 9:46:00 AM, you wrote:>> Each class can send quantum bytes at a time. You specified quantum = 1096 >> wich is bigger then the MTU (mostly 1500). If you have a big packet of 1500 >> byte and a quantum of 1096 byte, you are only allowed to send 1096 byte. But >> the packet is sended anyway and a warning message is logged. >> >> Quantum is calculated as rate / r2q. r2q iq by default 10 and can be >> overruled if you create the heb qdisc. Quantum can be overruled when you add >> a class.AH> Stef thanx to you so much.. AH> whats an "heb qdisc". am sorry but i really dont know anything about it. AH> if u can give a little more detail pls. :) AH> log message generated now is--> AH> Aug 10 04:12:05 Lr1 kernel: nf_hook: Verdict = QUEUE. AH> Aug 10 04:12:36 Lr1 last message repeated 5614 times AH> Aug 10 04:13:37 Lr1 last message repeated 12355 times AH> Aug 10 04:14:38 Lr1 last message repeated 12845 times AH> why this log message appears every minute ??.. is it due to packets are AH> being send to the imq QUEUE ie its queueing ?? AH> thanking in advance AH> A.H AH> _______________________________________________ AH> LARTC mailing list / LARTC@mailman.ds9a.nl AH> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ ----------------------------------- mailto:alexey_talikov@texlab.com.uz BR Alexey Talikov FORTEK ----------------------------------- _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
hi Alex, thanx so much.. :) .. thanx to all my IMQ & htb3 test rules are working ok.. the best part--> imq handling both in & out traffic now.. :) Alexey Talikov wrote:> Hello Arindam, > See imq faq http://luxik.cdi.cz/~patrick/imq/faq.html > Saturday, August 10, 2002, 9:46:00 AM, you wrote: >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Arindam Haldar wrote:> hi Alex, > thanx so much.. :) .. thanx to all > my IMQ & htb3 test rules are working ok.. the best part--> imq handling > both in & out traffic now.. :)I also had this setup, and i also thought of it as a "cool thing" :) but then Patrick told me, that it''s not so clever: the incoming traffic must pass 2 qdiscs (interface-qdisc and imq-qdisc) and this is bad/not good because 1) cpu - overhead (but this could be negleted) AND 2) these 2 qdiscs COULD drop packets and no one would know of the other having dropped s.th. -> retransmit ok. case 2 is not so realistic, as the qdisc on the interface normaly is the qfifo but nevertheless point 1) and the possibility of 2) made me think that queing double unnecessary.> > Alexey Talikov wrote: > >> Hello Arindam, >> See imq faq http://luxik.cdi.cz/~patrick/imq/faq.html >> Saturday, August 10, 2002, 9:46:00 AM, you wrote: >> > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Tuesday 13 August 2002 01:07, Tobias Geiger wrote:> Arindam Haldar wrote: > > hi Alex, > > thanx so much.. :) .. thanx to all > > my IMQ & htb3 test rules are working ok.. the best part--> imq handling > > both in & out traffic now.. :) > > I also had this setup, and i also thought of it as a "cool thing" :) > but then Patrick told me, that it''s not so clever: the incoming traffic > must pass 2 qdiscs (interface-qdisc and imq-qdisc) and this is bad/not > good because > 1) cpu - overhead (but this could be negleted) AND > 2) these 2 qdiscs COULD drop packets and no one would know of the other > having dropped s.th. -> retransmit > ok. case 2 is not so realistic, as the qdisc on the interface normaly > is the qfifo but nevertheless point 1) and the possibility of 2) made me > think that queing double unnecessary.Basic incoming shaping can be done with the ingress qdisc and the policers. This is not a real qdisc with a queue, but it can throttle down incoming packets without creating extra delays. It just droppes incoming packets untill the wanted rate is reached. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Stef Coene wrote:> On Tuesday 13 August 2002 01:07, Tobias Geiger wrote: > >>Arindam Haldar wrote: >> >>>hi Alex, >>>thanx so much.. :) .. thanx to all >>>my IMQ & htb3 test rules are working ok.. the best part--> imq handling >>>both in & out traffic now.. :) >> >>I also had this setup, and i also thought of it as a "cool thing" :) >>but then Patrick told me, that it''s not so clever: the incoming traffic >>must pass 2 qdiscs (interface-qdisc and imq-qdisc) and this is bad/not >>good because >>1) cpu - overhead (but this could be negleted) AND >>2) these 2 qdiscs COULD drop packets and no one would know of the other >>having dropped s.th. -> retransmit >>ok. case 2 is not so realistic, as the qdisc on the interface normaly >>is the qfifo but nevertheless point 1) and the possibility of 2) made me >>think that queing double unnecessary. > > Basic incoming shaping can be done with the ingress qdisc and the policers. > This is not a real qdisc with a queue, but it can throttle down incoming > packets without creating extra delays. It just droppes incoming packets > untill the wanted rate is reached. > > Stefi have acheived restrictinng both in&out trafic using imq0.. i havemarked the packets on different ineterface, hence sending them to the rules i want & then used **FORWARD** to imq .!.. it works pretty good, though done in a test bed of 4 ip.. i want to scale it to our running linux box handling about 250 ip''s with 1.5mbps link.. the question now i have start thinking, after Tobias Geiger''smail is --> what will be the cpu overhead when the linix box also runs squid in it.. withh htb3 & imq show the same result as shown in the test ? i hope & feel it will .. :) A.H _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> i have acheived restrictinng both in&out trafic using imq0.. i have > marked the packets on different ineterface, hence sending them to the > rules i want & then used **FORWARD** to imq .!.. it works pretty good, > though done in a test bed of 4 ip.. i want to scale it to our running > linux box handling about 250 ip''s with 1.5mbps link.. > the question now i have start thinking, after Tobias Geiger''smail is --> > what will be the cpu overhead when the linix box also runs squid in it.. > withh htb3 & imq show the same result as shown in the test ? > i hope & feel it will .. :)I think the CPU is not so important. I think there are other problems with shaping incoming bandwidth with imq. First of all, you can create an extra queue and so extra delays. But using a "shared" structure to manage incoming problems can also be a problem. Imagine a setup where 100 kbps is split in 2 parts of 50 and they can borrow from each other. One class is empty and one class is filled. When there is suddenly a burst in the empty class of 50 kbps, it will take some time before the traffic in the full class will throttle down to 50kbps. And don''t forget the extra delay introduced by the imq device, so the response will even be slower. It''s better to be sure the 50kbps is available for the bursty traffic. Of cours, you waste some bandwidth, but a few kbps is enough to make telnet more responsive. So you can do some shaping on incoming traffic, but bursty traffic is not so easy to mange. To be honest, I just start reading and thinking about shaping incoming traffic, so any suggestions are welcome. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/