Quantum & r2q | ||||||||||||||||||||
Let's assume we have 2 classes with the same parent : Parent : ceil = rate = 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. 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). 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. An example
|
相关文章
- 02-09quantum sets
- 02-09quantum theory
- 02-09Quantum & r2q
- 02-09量子力学与广义相对论的统一——用广义相对论解释海森堡测不准原理 Unification of Quantum Mechanics and General Relativity: Explaining
- 02-09quantum使用中发现一个OVS信息,不知原因
- 02-09resmgr:cpu quantum等待事件 触发的bug问题
- 02-09Quantum search algorithms
- 02-09搬家第13天-记一次quantum PLC升级unity架构遇到的模拟量输入模板的问题
- 02-09TensorFlow Quantum 使用心得
- 02-09How to remember the definition of Quantum Groups