Hi!
HTB questions:
1. why is quantum not always: quantum=mtu?
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
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 for 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 = <major>:<minor> and all the
<major>
numbers of classes within a qdisc must be the same as the qdisc (which have
<minor> = 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>
.
.
.
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?
--
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
On Thursday 28 November 2002 14:40, Abraham van der Merwe wrote:> Hi! > > HTB questions: > > 1. why is quantum not always: quantum=mtu? > > 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 having a > bigger quantum?First you need the know why quantum exists. You can find more info on www.docum.org on the faq page. BAsically, quantum is used when 2 or more classes are asking for extra (so more then the rate) bandwidth from the same parent. Then they may send "quantum" bytes at each turn.> 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 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?Prio in filters is used to know the order the filters are checked. So filters 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 excess 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 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?)Nothing will happen. All the traffic from class 1:10 is considered as 1 data stream for the parent of 1:10. The same for class 1:20. So splitting the data between 1:10 and 1:20 has nothing to do with the child classes they may have.> 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?Then the parent will throttle the bandwidth to it''s rate. Again, the traffic of all the child classes is considered as one 1 data stream for the parent class.> 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 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?The parent ceil is never respected due to performance problems. Doing so will create a lot of overhead. So the ceil of the child class can never be higher then the ceil of the parent. Of course you can take a higher value, but the 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 just > can''t figure out how you''re supposed to represent a hierarchy of classes > with classid''s. > > The way I understand it classid = <major>:<minor> and all the <major> > numbers of classes within a qdisc must be the same as the qdisc (which have > <minor> = 0), i.e.x:0 can also be a class, but a qdisc is always x:0. For htb, class x:0 is a 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 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?Choose what ever number you want as long as the minor number is unique within 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, then > the second or what?You can only have 1 root qdisc. The root qdisc controls the queue of the 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 eat CPU cycles. 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/
Hi Stef!> > HTB questions: > > > > 1. why is quantum not always: quantum=mtu? > > > > 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 having a > > bigger quantum? > First you need the know why quantum exists. You can find more info on > www.docum.org on the faq page. BAsically, quantum is used when 2 or more > classes are asking for extra (so more then the rate) bandwidth from the same > 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 classes 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 = 1600 bytes rate 32kbit r2q 2 # quantum = 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 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} ... 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 = 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?> > > 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? > Prio in filters is used to know the order the filters are checked. So filters > 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 excess > 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 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? > The parent ceil is never respected due to performance problems. Doing so will > create a lot of overhead. So the ceil of the child class can never be higher > then the ceil of the parent. Of course you can take a higher value, but the > 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) | | | +-- 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, then > > the second or what? > You can only have 1 root qdisc. The root qdisc controls the queue of the > 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? -- 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
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, but > 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 is > still larger than the mtu (1500 bytes), so you can do > > rate 64kbit r2q 5 # quantum = 1600 bytes > rate 32kbit r2q 2 # quantum = 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 > 1500. What do I do in this case?Quantum is used for bandwdith that exceeds the rate. So I should go for the options where the smallest classes are ok. If you have a class with ceil = 100 and rate = 1, then you have a big change that you need quantum. If you have a class with rate = 99 and ceil = 100, quantum is less important. On the other hand, the rule that quantum > mtu is only needed for packets that are mtu bytes. If you have packets that are maximum 1000byte, you can take 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 = 1600 by default.Of course it depends on where the mtu is used in the calculatins. Maybe it''s parameter that''s not so important in the calculations.> 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?I think with the frame header. When htb kicks in, the packets are ready to 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 filters > are matched?Indeed.> 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) > | +-- 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)?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 128kbit. Class 2.1 and class 2.2 are better, they can share the same 64kbit, but they never can ask for more then the parent ceil because there own ceil don''t 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 possible?Yes, buy creating a smart htb setup. Not all of this is possible, classes 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 may use 64kbit together. There is a work around. You can create multiple imq devices and redirect the traffic to it. So you can shape on the imq device and the real device. But it will also introduce extra delays because the packets have to travel though 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 happen. 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/
> 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 = 1600 by default.I did a quick search in the source of iproute2 and kernel, and as for as I can 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 space */ if (!buffer) buffer = opt.rate.rate / HZ + mtu; if (!cbuffer) cbuffer = opt.ceil.rate / HZ + mtu; 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/
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 possible? > Yes, buy creating a smart htb setup. Not all of this is possible, classes > 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 > may use 64kbit together. > There is a work around. You can create multiple imq devices and redirect the > traffic to it. So you can shape on the imq device and the real device. But > it will also introduce extra delays because the packets have to travel though > 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? -- 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
All right. What about when no borrowing takes place (classes are not trying to use more than their base rate)? Is the quantum parameter unused in this case?> www.docum.org on the faq page. BAsically, quantum is used when 2 or more > classes are asking for extra (so more then the rate) bandwidth from the same > parent. Then they may send "quantum" bytes at each turn. >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> > Prio in htb classes is used to give a) one class the first choice in excess > bandwidth and b) to give the class lower delays.About b) above, will HTB just "do its best" to give classes with lower prio a better delay, or will it truly work like a priority queuing mechanism (up to the rate, of course)? In other words, how does the scheduling algorithm deals with "prio" in HTB ? I think the answer to this question is a very inportant for anyone who is considering to have EF traffic in HTB. I was not able to find a technical and precise answer to it up to now. Mathieu. _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Friday 29 November 2002 13:56, Mathieu Deziel wrote:> All right. What about when no borrowing takes place (classes are not > trying to use more than their base rate)? Is the quantum parameter unused > in this case?Indeed. If a parent has to divide traffic, it will first give a class it''s rate. If it''s not asking for more, nothing happens. If each class receive the rate and the classes wants more and the parent has some bandwidth left, the remaining bandwidth is divided proportional to the rate. See www.docum.org on the faq page for more information. 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/
On Friday 29 November 2002 14:25, Mathieu Deziel wrote:> > Prio in htb classes is used to give a) one class the first choice in > > excess bandwidth and b) to give the class lower delays. > > About b) above, will HTB just "do its best" to give classes with lower prio > a better delay, or will it truly work like a priority queuing mechanism (up > to the rate, of course)?That''s one of the things I have to figure out. Htb will give the class with the highest priority the lowest delay. BUT if this class is overlimited (if it sends more then it''s rate), the underlimited part (the other classes) are serverd first and the delays increases a lot. See htb "USer Guid" on the htb homepage. So if you want a class with very low delays, you can give it a lower prio, BUT make sure the class is never overlimited or the delay will increase a lot. I''m planning to do some tests. I think it''s possible to use the policer in the filters to make sure the class is never overlimited.> In other words, how does the scheduling algorithm deals with "prio" in HTB > ? I think the answer to this question is a very inportant for anyone who is > considering to have EF traffic in HTB. I was not able to find a technical > and precise answer to it up to now.Me neither. I''m planning to do some tests and read some sources around the problem so I can clear it out. I did the same with the quantum parameter and Devik was so nice to answer all my mails. But I promised him some good Belgium beer, so he had no choice :) 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/