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
Attachment:
pgp00059.pgp
Description: PGP signature
