--pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! HTB questions: 1. why is quantum not always: quantum=3Dmtu? =46rom http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm: ------------< snip <------< snip <------< snip <------------ It is important to know that for precise operation quantums need to be as small as possible and larger than MTU ------------< snip <------< snip <------< snip <------------ Why isn't quantum just set to MTU then? Is there any advantages to having a bigger quantum? 2. why is mtu not just derived from the interface (you always have to specify the interface, so tc can just do a SIOCGIFMTU on the interface to get the MTU size)? 3. what is the difference between the priority which you can specify on the leaf nodes of the classes and the priorities you can specify in u32 match filters? does the one override the other? it seems that you have to specify the priority in a u32 match (to avoid the double display bug), so can you just specify prio 1 in all the u32 filters and then prioritize using classes - will that work or will the u32 priorities override the others? 4. could somebody please explain exactly what happens if the rates of children/subclasses within a root class exceed that of the root class/parent? does that influence other classes/qdiscs that does not fall within that hierarchy? (e.g. two classes 1:10 and 1:20 each have some classes below them - class 1:10 have more children in it than its rate, but 1:20 has less children / rate than its own rate - does the "oversold" rates in 1:10 influence 1:20?) 5. what happens if none of the rates of each class in a parent class exceed the parent's rate/ceil, but the total (i.e. sum of all the rates of the child classes) does exceed the parent's rate/ceil? 6. lets say I have a line with a certain rate - e.g. 512kbit, but I know fo= r a fact that I can get a higher throughput through this line, lets say 768kbit. Now if I add a root qdisc with a root class in it rated at 512kbit and then add another child class in it with rate 512kbit and ceil 768kbit and then all my classes within that class - will the subclasses still respect their rate/ceil's? TC questions: 1. how does the classid's work? I must be stupid or something, but I just can't figure out how you're supposed to represent a hierarchy of classes with classid's. The way I understand it classid =3D <major>:<minor> and all the <major> numbers of classes within a qdisc must be the same as the qdisc (which have <minor> =3D 0), i.e. tc qdisc ... handle <x>: ... # root class in this qdisc tc class ... parent <x>: classid <x>:<y> tc class ... parent <x>:<y> classid <x>:<z> =2E =2E =2E So the qdisc handle is easy (just choose a unique major number), the root class in the qdisc is easy (just choose a unique minor number), but what do you use for the classes within the root class if you want multiple levels of classes, e.g. qdisc | +-- root class | +-- class 1 | | | +-- class 1.1 | | | +-- class 1.2 | +-- class 2 | +-- class 2.1 in above diagram, what would the classid's of classes 1, 2, 1.x, and 2.x be? 2. what happens if you have multiple root qdiscs? e.g. tc qdisc ... handle 1: root htb ... tc qdisc ... handle 2: root htb ... with some classes in each. Does the first qdisc get evaluated first, then the second or what? 3. what happens if you have qdiscs in non-leaf nodes within classes? --=20 Regards Abraham "Your butt is mine." -- Michael Jackson, Bad ___________________________________________________ Abraham vd Merwe [ZR1BBQ] - Frogfoot Networks P.O. Box 3472, Matieland, Stellenbosch, 7602 Cell: +27 82 565 4451 Http: http://www.frogfoot.net Email: abz@frogfoot.net --pWyiEgJYm5f9v55/ Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE95hy70jJV70h31dERArPaAJ91vi1UlX/aaeiSTimqzrbIJQ0qaQCgqCOM iYNeHvkVyAtcI78dbzhGxOE= =/7AH -----END PGP SIGNATURE----- --pWyiEgJYm5f9v55/--
On Thursday 28 November 2002 14:40, Abraham van der Merwe wrote: > Hi! > > HTB questions: > > 1. why is quantum not always: quantum=3Dmtu? > > From http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm: > > ------------< snip <------< snip <------< snip <------------ > It is important to know that for precise operation quantums need to be = as > small as possible and larger than MTU > ------------< snip <------< snip <------< snip <------------ > > Why isn't quantum just set to MTU then? Is there any advantages to havi= ng a > bigger quantum? First you need the know why quantum exists. You can find more info on=20 www.docum.org on the faq page. BAsically, quantum is used when 2 or more= =20 classes are asking for extra (so more then the rate) bandwidth from the s= ame=20 parent. Then they may send "quantum" bytes at each turn. =20 > 2. why is mtu not just derived from the interface (you always have to > specify the interface, so tc can just do a SIOCGIFMTU on the interface = to > get the MTU size)? When do you have to specify mtu if you use htb ?? > 3. what is the difference between the priority which you can specify on= the > leaf nodes of the classes and the priorities you can specify in u32 mat= ch > filters? does the one override the other? it seems that you have to spe= cify > the priority in a u32 match (to avoid the double display bug), so can y= ou > just specify prio 1 in all the u32 filters and then prioritize using > classes - will that work or will the u32 priorities override the others= ? Prio in filters is used to know the order the filters are checked. So fi= lters=20 with the same parent are ordered based on the prio setting. Prio in htb classes is used to give a) one class the first choice in exce= ss=20 bandwidth and b) to give the class lower delays. > 4. could somebody please explain exactly what happens if the > rates of children/subclasses within a root class exceed that of the roo= t > class/parent? does that influence other classes/qdiscs that does not fa= ll > within that hierarchy? (e.g. two classes 1:10 and 1:20 each have some > classes below them - class 1:10 have more children in it than its rate,= but > 1:20 has less children / rate than its own rate - does the "oversold" r= ates > in 1:10 influence 1:20?) Nothing will happen. All the traffic from class 1:10 is considered as 1 = data=20 stream for the parent of 1:10. The same for class 1:20. So splitting th= e=20 data between 1:10 and 1:20 has nothing to do with the child classes they = may=20 have. > 5. what happens if none of the rates of each class in a parent class ex= ceed > the parent's rate/ceil, but the total (i.e. sum of all the rates of the > child classes) does exceed the parent's rate/ceil? Then the parent will throttle the bandwidth to it's rate. Again, the tra= ffic=20 of all the child classes is considered as one 1 data stream for the paren= t=20 class. > 6. lets say I have a line with a certain rate - e.g. 512kbit, but I kno= w > for a fact that I can get a higher throughput through this line, lets s= ay > 768kbit. Now if I add a root qdisc with a root class in it rated at 512= kbit > and then add another child class in it with rate 512kbit and ceil 768kb= it > and then all my classes within that class - will the subclasses still > respect their rate/ceil's? The parent ceil is never respected due to performance problems. Doing so= will=20 create a lot of overhead. So the ceil of the child class can never be hi= gher=20 then the ceil of the parent. Of course you can take a higher value, but = the=20 ceil of the parent class will not be respected. > TC questions: > > 1. how does the classid's work? I must be stupid or something, but I ju= st > can't figure out how you're supposed to represent a hierarchy of classe= s > with classid's. > > The way I understand it classid =3D <major>:<minor> and all the <major> > numbers of classes within a qdisc must be the same as the qdisc (which = have > <minor> =3D 0), i.e. x:0 can also be a class, but a qdisc is always x:0. For htb, class x:0 i= s a=20 pass-thru class that will send the packets as fast as possible. > tc qdisc ... handle <x>: ... > > # root class in this qdisc > tc class ... parent <x>: classid <x>:<y> > > tc class ... parent <x>:<y> classid <x>:<z> > > > So the qdisc handle is easy (just choose a unique major number), the ro= ot > class in the qdisc is easy (just choose a unique minor number), but wha= t do > you use for the classes within the root class if you want multiple leve= ls > of classes, e.g. > > qdisc > > +-- root class > +-- class 1 > | +-- class 1.1 > | +-- class 1.2 > +-- class 2 > +-- class 2.1 > > in above diagram, what would the classid's of classes 1, 2, 1.x, and 2.= x > be? Choose what ever number you want as long as the minor number is unique wi= thin=20 the qdisc. > 2. what happens if you have multiple root qdiscs? > > e.g. > > tc qdisc ... handle 1: root htb ... > tc qdisc ... handle 2: root htb ... > > with some classes in each. Does the first qdisc get evaluated first, th= en > the second or what? You can only have 1 root qdisc. The root qdisc controls the queue of the= =20 outgoing packets and there is only 1 queue. > 3. what happens if you have qdiscs in non-leaf nodes within classes? It depends. Most of the time it will only generate extra overhead and it= will=20 eat CPU cycles. Stef --=20 stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net
--dDRMvlgZJXvWKvBx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Stef! > > HTB questions: > > > > 1. why is quantum not always: quantum=3Dmtu? > > > > From http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm: > > > > ------------< snip <------< snip <------< snip <------------ > > It is important to know that for precise operation quantums need to be = as > > small as possible and larger than MTU > > ------------< snip <------< snip <------< snip <------------ > > > > Why isn't quantum just set to MTU then? Is there any advantages to havi= ng a > > bigger quantum? > First you need the know why quantum exists. You can find more info on=20 > www.docum.org on the faq page. BAsically, quantum is used when 2 or more= =20 > classes are asking for extra (so more then the rate) bandwidth from the s= ame=20 > parent. Then they may send "quantum" bytes at each turn. Ok, so it is important to make the quantum proportional to the rate, but what happens if you have different ratios, e.g. you have the following clas= ses rate 512kbit rate 256kbit rate 64kbit rate 32kbit For the last two, you obviously need to tweak r2q so that the quantum is still larger than the mtu (1500 bytes), so you can do rate 64kbit r2q 5 # quantum =3D 1600 bytes rate 32kbit r2q 2 # quantum =3D 2000 bytes Now you don't actually have quanta that's proportional to the rate so theoretically this is going to be worse than just making all the quanta =3D 1500. What do I do in this case? > > 2. why is mtu not just derived from the interface (you always have to > > specify the interface, so tc can just do a SIOCGIFMTU on the interface = to > > get the MTU size)? > When do you have to specify mtu if you use htb ?? You don't have to, but HTB assumes a mtu of 1600 by default which is a) wrong in most cases b) not always the same (e.g. loopback default is 16436) ------------< snip <------< snip <------< snip <------------ root@oasis:~# tc class add dev eth0 parent 1:1 htb help Usage: ... qdisc add ... htb [default N] [r2q N] default minor id of class to which unclassified packets are sent {0} r2q DRR quantums are computed as rate in Bps/r2q {10} debug string of 16 numbers each 0-3 {0} =2E.. class add ... htb rate R1 burst B1 [prio P] [slot S] [pslot PS] [ceil R2] [cburst B2] [mtu MTU] [quantum Q] rate rate allocated to this class (class can still borrow) burst max bytes burst which can be accumulated during idle period {computed} ceil definite upper class rate (no borrows) {rate} cburst burst but for ceil {computed} mtu max packet size we create rate map for {1600} prio priority of leaf; lower are served first {0} quantum how much bytes to serve from leaf at once {use r2q} TC HTB version 3.3 root@oasis:~# ------------< snip <------< snip <------< snip <------------ See, mtu =3D 1600 by default. While I'm on the topic of mtu's - should the mtu which you specify include the frame header (i.e. 1500 + 14 bytes for ethernet) or without the frame header? >=20 > > 3. what is the difference between the priority which you can specify on= the > > leaf nodes of the classes and the priorities you can specify in u32 mat= ch > > filters? does the one override the other? it seems that you have to spe= cify > > the priority in a u32 match (to avoid the double display bug), so can y= ou > > just specify prio 1 in all the u32 filters and then prioritize using > > classes - will that work or will the u32 priorities override the others? > Prio in filters is used to know the order the filters are checked. So fi= lters=20 > with the same parent are ordered based on the prio setting. > Prio in htb classes is used to give a) one class the first choice in exce= ss=20 > bandwidth and b) to give the class lower delays. Ah thanks. So for all practical purposes you can just set the priority of all filters to the same value if you don't mind in which order the filters are matched? > > 6. lets say I have a line with a certain rate - e.g. 512kbit, but I know > > for a fact that I can get a higher throughput through this line, lets s= ay > > 768kbit. Now if I add a root qdisc with a root class in it rated at 512= kbit > > and then add another child class in it with rate 512kbit and ceil 768kb= it > > and then all my classes within that class - will the subclasses still > > respect their rate/ceil's? > The parent ceil is never respected due to performance problems. Doing so= will=20 > create a lot of overhead. So the ceil of the child class can never be hi= gher=20 > then the ceil of the parent. Of course you can take a higher value, but = the=20 > ceil of the parent class will not be respected. I'm not sure I understand what you're saying. Can't you specify a parent ceil or can't you specify a child ceil that is higher than the parents? Which one is it or is it both? If it is the first, I take it means you can't have | | +-- class 1 (rate 64kbit ceil 128kbit) | | | +-- class 1.1 (rate 32kbit) | | =20 | +-- class 1.2 (rate 48kbit) | +-- class 2 (rate 64kbit ceil 128kbit) | +-- class 1.1 (rate 64kbit) in other words class 1 & 2 can't borrow from each other. Is that correct (would be a bummer if that is the case)? > > 2. what happens if you have multiple root qdiscs? > > > > e.g. > > > > tc qdisc ... handle 1: root htb ... > > tc qdisc ... handle 2: root htb ... > > > > with some classes in each. Does the first qdisc get evaluated first, th= en > > the second or what? > You can only have 1 root qdisc. The root qdisc controls the queue of the= =20 > outgoing packets and there is only 1 queue. Hmm, lets say I want to do this: 1. shape/prioritize some subnets according to some rules 2. shape/prioritize some protocols according to some rules (1) should be evaluated and then the data stream should be passed on to (2) and be evaluated again according to that set of criteria. is this possible? One more thing which I'm not completely clear about yet: What happens when you have a child class which have a higher rate/ceil than the parent? Is this illegal or not? If not, what happens? --=20 Regards Abraham Forgetfulness, n.: A gift of God bestowed upon debtors in compensation for their destitution of conscience. ___________________________________________________ Abraham vd Merwe [ZR1BBQ] - Frogfoot Networks P.O. Box 3472, Matieland, Stellenbosch, 7602 Cell: +27 82 565 4451 Http: http://www.frogfoot.net Email: abz@frogfoot.net --dDRMvlgZJXvWKvBx Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE95kgY0jJV70h31dERApHXAJ9a2puYY391v4b/Dvygj6Zf6cjSZQCfcSNk Bt0xVyxtGY5jkpUFjmomzMY= =/n1P -----END PGP SIGNATURE----- --dDRMvlgZJXvWKvBx--
On Thursday 28 November 2002 17:45, Abraham van der Merwe wrote:
> Ok, so it is important to make the quantum proportional to the rate, bu=
t
> what happens if you have different ratios, e.g. you have the following
> classes
>
> rate 512kbit
> rate 256kbit
> rate 64kbit
> rate 32kbit
>
> For the last two, you obviously need to tweak r2q so that the quantum i=
s
> still larger than the mtu (1500 bytes), so you can do
>
> rate 64kbit r2q 5 # quantum =3D 1600 bytes
> rate 32kbit r2q 2 # quantum =3D 2000 bytes
>
> Now you don't actually have quanta that's proportional to the rate so
> theoretically this is going to be worse than just making all the quanta=
=3D
> 1500. What do I do in this case?
Quantum is used for bandwdith that exceeds the rate. So I should go for =
the=20
options where the smallest classes are ok. If you have a class with ceil=
=3D=20
100 and rate =3D 1, then you have a big change that you need quantum. If=
you=20
have a class with rate =3D 99 and ceil =3D 100, quantum is less important=
=2E
On the other hand, the rule that quantum > mtu is only needed for packets=
that=20
are mtu bytes. If you have packets that are maximum 1000byte, you can ta=
ke=20
quantum > 1000.
> You don't have to, but HTB assumes a mtu of 1600 by default which is
>
> a) wrong in most cases
> b) not always the same (e.g. loopback default is 16436)
>
> ------------< snip <------< snip <------< snip
<------------
> root@oasis:~# tc class add dev eth0 parent 1:1 htb help
> Usage: ... qdisc add ... htb [default N] [r2q N]
> default minor id of class to which unclassified packets are sent {0}
> r2q DRR quantums are computed as rate in Bps/r2q {10}
> debug string of 16 numbers each 0-3 {0}
>
> ... class add ... htb rate R1 burst B1 [prio P] [slot S] [pslot PS]
> [ceil R2] [cburst B2] [mtu MTU] [quantum Q]
> rate rate allocated to this class (class can still borrow)
> burst max bytes burst which can be accumulated during idle period
> {computed}
> ceil definite upper class rate (no borrows) {rate}
> cburst burst but for ceil {computed}
> mtu max packet size we create rate map for {1600}
> prio priority of leaf; lower are served first {0}
> quantum how much bytes to serve from leaf at once {use r2q}
>
> TC HTB version 3.3
> root@oasis:~#
> ------------< snip <------< snip <------< snip
<------------
>
> See, mtu =3D 1600 by default.
Of course it depends on where the mtu is used in the calculatins. Maybe =
it's=20
parameter that's not so important in the calculations. =20
> While I'm on the topic of mtu's - should the mtu which you specify incl=
ude
> the frame header (i.e. 1500 + 14 bytes for ethernet) or without the fra=
me
> header?
I think with the frame header. When htb kicks in, the packets are ready =
to=20
send so the header is already included.
> Ah thanks. So for all practical purposes you can just set the priority =
of
> all filters to the same value if you don't mind in which order the filt=
ers
> are matched?
Indeed.
> I'm not sure I understand what you're saying. Can't you specify a paren=
t
> ceil or can't you specify a child ceil that is higher than the parents?
> Which one is it or is it both?
>
> If it is the first, I take it means you can't have
>
>
>
> +-- class 1 (rate 64kbit ceil 128kbit)
> | +-- class 1.1 (rate 32kbit)
> | +-- class 1.2 (rate 48kbit)
> +-- class 2 (rate 64kbit ceil 128kbit)
> +-- class 1.1 (rate 64kbit)
>
> in other words class 1 & 2 can't borrow from each other. Is that
correc=
t
> (would be a bummer if that is the case)?
They can borrow from each other, but I miss some ceil paramters :
+-- class 1 (rate 64kbit ceil 128kbit)
| +-- class 1.1 (rate 32kbit ceil 256kbit)
| +-- class 1.2 (rate 48kbit ceil 256kbit)
+-- class 2 (rate 64kbit ceil 128kbit)
+-- class 2.1 (rate 32kbit ceil 128kbit)
+-- class 2.2 (rate 32kbit ceil 128kbit)
Class 1.1 and class 1.2 can use 256 kbit, even if the parent ceil is 128k=
bit. =20
Class 2.1 and class 2.2 are better, they can share the same 64kbit, but t=
hey=20
never can ask for more then the parent ceil because there own ceil don't=20
allows this.
> Hmm, lets say I want to do this:
>
> 1. shape/prioritize some subnets according to some rules
> 2. shape/prioritize some protocols according to some rules
>
> (1) should be evaluated and then the data stream should be passed on to=
(2)
> and be evaluated again according to that set of criteria. is this possi=
ble?
Yes, buy creating a smart htb setup. Not all of this is possible, classe=
s=20
with different parents can't share the same bandwidth :
+-- class 1 (rate 64kbit ceil 128kbit)
| +-- class 1.1 (rate 32kbit ceil 256kbit)
| +-- class 1.2 (rate 48kbit ceil 256kbit)
+-- class 2 (rate 64kbit ceil 128kbit)
+-- class 2.1 (rate 32kbit ceil 128kbit)
+-- class 2.2 (rate 32kbit ceil 128kbit)
You can not say that class 1.2 and 2.2 are sharing the same bandwidth or =
they=20
may use 64kbit together.
There is a work around. You can create multiple imq devices and redirect=
the=20
traffic to it. So you can shape on the imq device and the real device. =
But=20
it will also introduce extra delays because the packets have to travel th=
ough=20
an extra queue.
> One more thing which I'm not completely clear about yet:
>
> What happens when you have a child class which have a higher rate/ceil =
than
> the parent? Is this illegal or not? If not, what happens?
It's not illegal. But it will be less clear to figure out what will happ=
en.
Stef
--=20
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
--IJpNTDwzlM2Ie8A6 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi Stef! > > Hmm, lets say I want to do this: > > > > 1. shape/prioritize some subnets according to some rules > > 2. shape/prioritize some protocols according to some rules > > > > (1) should be evaluated and then the data stream should be passed on to= (2) > > and be evaluated again according to that set of criteria. is this possi= ble? > Yes, buy creating a smart htb setup. Not all of this is possible, classe= s=20 > with different parents can't share the same bandwidth : >=20 > +-- class 1 (rate 64kbit ceil 128kbit) > | +-- class 1.1 (rate 32kbit ceil 256kbit) > | +-- class 1.2 (rate 48kbit ceil 256kbit) > +-- class 2 (rate 64kbit ceil 128kbit) > +-- class 2.1 (rate 32kbit ceil 128kbit) > +-- class 2.2 (rate 32kbit ceil 128kbit) >=20 > You can not say that class 1.2 and 2.2 are sharing the same bandwidth or = they=20 > may use 64kbit together. > There is a work around. You can create multiple imq devices and redirect= the=20 > traffic to it. So you can shape on the imq device and the real device. = But=20 > it will also introduce extra delays because the packets have to travel th= ough > an extra queue. I thought about the imq, but I'm not sure how I can redirect traffic from one device to another, other than creating a bunch of different networks and then routing traffic from one to the other. Is there a better/faster way to do this? Also, isn't there a limit on the number of imq devices which you can use? --=20 Regards Abraham There is always one thing to remember: writers are always selling somebody = out. -- Joan Didion, "Slouching Towards Bethlehem" ___________________________________________________ Abraham vd Merwe [ZR1BBQ] - Frogfoot Networks P.O. Box 3472, Matieland, Stellenbosch, 7602 Cell: +27 82 565 4451 Http: http://www.frogfoot.net Email: abz@frogfoot.net --IJpNTDwzlM2Ie8A6 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.5 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE95ll50jJV70h31dERAmZZAJwNNVex0hcNgQrEW5eP3FxTdS2JXQCeKTIv TGMiGHc5GrAU1fH6ufAANg8= =8dDy -----END PGP SIGNATURE----- --IJpNTDwzlM2Ie8A6--
> You don't have to, but HTB assumes a mtu of 1600 by default which is
>
> a) wrong in most cases
> b) not always the same (e.g. loopback default is 16436)
>
> ------------< snip <------< snip <------< snip
<------------
> root@oasis:~# tc class add dev eth0 parent 1:1 htb help
> Usage: ... qdisc add ... htb [default N] [r2q N]
> default minor id of class to which unclassified packets are sent {0}
> r2q DRR quantums are computed as rate in Bps/r2q {10}
> debug string of 16 numbers each 0-3 {0}
>
> ... class add ... htb rate R1 burst B1 [prio P] [slot S] [pslot PS]
> [ceil R2] [cburst B2] [mtu MTU] [quantum Q]
> rate rate allocated to this class (class can still borrow)
> burst max bytes burst which can be accumulated during idle period
> {computed}
> ceil definite upper class rate (no borrows) {rate}
> cburst burst but for ceil {computed}
> mtu max packet size we create rate map for {1600}
> prio priority of leaf; lower are served first {0}
> quantum how much bytes to serve from leaf at once {use r2q}
>
> TC HTB version 3.3
> root@oasis:~#
> ------------< snip <------< snip <------< snip
<------------
>
> See, mtu =3D 1600 by default.
I did a quick search in the source of iproute2 and kernel, and as for as =
I can=20
see is mtu used to calculate the minimal burst :
/* compute minimal allowed burst from rate; mtu is added here to =
make
sute that buffer is larger than mtu and to have some safeguard=
=20
space */
if (!buffer) buffer =3D opt.rate.rate / HZ + mtu;
if (!cbuffer) cbuffer =3D opt.ceil.rate / HZ + mtu;
Stef
--=20
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net