On Tuesday 29 July 2003 07:22, Rio Martin. wrote:
> On Saturday 26 July 2003 13:09, Raj Mathur wrote:
> > Hi Rio,
> > Hmm, so if I understand you correctly you're saying that the QUANTUM
> > in each SFQ should be proportional to the bandwidth allocated to that
> > pool. As per the documents I've read, this must also be >= the
> > maximum packet size.
>
> Not quantum value in SFQ, but R2Q ..
> Perhaps Stef have something more about this, i am just user, i am just
> using this HTB without understanding about how this work more deeper ..
Quantum is a number of bytes. It is calculated as rate / r2q. And r2q can be
set when you add a htb qdisc (default = 10). Quamtum is the number of bytes
that each class can send when they are fighting for remaining bandwidth.
The minimum quantum is 1500 (max packet size). So you can send at least 1
packet. The maximum is 60000 and this is hard coded in htb to prevent class
starvation. If a class has a quantum of 1000000000 it will send 1000000000
bytes before other classes are served. So to prevent this, 60000 is the
maximum.
The rate of a class is the minimum bandwidth a class will get. If all classes
are sending theire rate AND the parent has more bandwidth, each class may
send quantum bytes. So quantum is only imporant if the parent has more
bandwidth then the sum of the rate of the active child classes.
I never changed quantum in a test situation to see what's happing, but there
are reports that you can improve your setup by choosing the right quantums.
Just take quantum not too small (5000 so you can send some packets in 1
turn). But for higher rates, take a higher quantum. But don't give 2
classes 2 total different quantums like 2000 and 600000.
I hope this helps. I know what quantum does, but if you get some real
improvements if you change quantum, let me know so I can update the faq page
on docum.org.
Stef
--
stef.coene@xxxxxxxxx
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
