[LARTC] htb3 & imq

[LARTC] htb3 & imq

[Arindam Haldar]

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/

Re: [LARTC] htb3 & imq

[Stef Coene]

> $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/

Re: [LARTC] htb3 & imq

[Arindam Haldar]

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

Re: [LARTC] htb3 & imq

[Stef Coene]

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/

Re: [LARTC] htb3 & imq

[Arindam Haldar]

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/

Re: [LARTC] htb3 & imq

[Tobias Geiger]

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/

Re: [LARTC] htb3 & imq

[Stef Coene]

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/

Re: [LARTC] htb3 & imq

[Arindam Haldar]

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 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 .. :)
A.H

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] htb3 & imq

[Stef Coene]

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