Quantum & r2q

Quantum & r2q

Let's assume we have 2 classes with the same parent :

Parent : ceil = rate = 100
class 1 : rate = 40 and ceil = 100
class 2 : rate = 20 and ceil = 100

(the used numbers are just theoretical to explain how it works)

Both classes are sending as much as they can. First, they are allowed to send enough packets to fulfill the rate even if they have different prio's. 
But the parent has some remaining bandwidth : 100 - 40 - 20 = 40. The remaining bandwidth is distributed according to the quantums. Each class can send "quantum" bytes at a turn.

Quantum is calculated as rate (in bytes) / r2q. r2q is by default 10 and can be overruled if you create an htb qdisc. Quantum can be overruled if you create an htb class. Quantum should be bigger then MTU (1500) so you can send the maximum packet in 1 turn and smaller then 60000 (hard coded in htb qdisc to prevent class starvation and too long delays). 
Errors on the quantum will not affect functionality, only precision. They are also logged via syslog so they can eat a lot of file space.

Packets that are sent when the class is allowed to send, are still matched against rate/ceil/burst/cburst. So a big quantum will not create bursts if you don't allow it with the burs/cburst parameters.

Counting packets with quantum can be strange. If we have a low rate class (rate = 5kbit), default quantum = 5000 / 10 = 500 bytes. But most packets are more then 500 bytes. Htb version 1 and 2 uses DRR, so a packet larger then 1000 bytes will be sent and it will remember how much it sent and wait until the packet is paid back before another packet is send. So if you send 1000 byte, next time the class is polled, you will not be allowed to send. 
Htb3 uses the WRR scheduler. When a packet with size > quantum is sent, it will be sent and an error that the quantum is too small will be logged. But there is no pay back. The WRR scheduler is faster then the DRR scheduler. So make sure quantum is bigger then the default packet size. For 15 kbyte/s and default r2q, quantum is 1500 and this is exactly the maximum packet size. If you want to tune htb for rates smaller then 15 kbyte/s, you can manually set the r2q and/or quantum.

An example 
The parent rate is 30 and it has 3 child classes c1, c2 and c3. The rate of the 3 classes is 10. Quantum of class2 = 1 and quantum of class3 = 2. Class 1 sends 4, so it gets 4. C2 and c3 are sending as much as they can so c2 and c3 get 10 (the rate is always satisfied). The parent still has 6 to distribute between c2 and c3. It will distributed according the quantums, so c2 gets 2 and c3 gets 4.

class	rate	traffic	quantum	bandwidth
c1	10	4	?	4
c2	10	+++	1	10+2=12
c3	10	+++	2	10+4=14