What is the difference between the HTB rate and Ceil values?
Best Answer
Rate is the rate they will be allowed to allocate when bandwidth is tight. However, when bandwidth isn't tight, HTB allows classes to "borrow" bandwidth from other classes. Ceil limits how much they can borrow. Lets say you have this:
tc class add dev eth0 parent 1: classid 1:1 htb rate 90kbps ceil 90kbps
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 30kbps ceil 60kbps
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 30kbps ceil 60kbps
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 30kbps ceil 60kbps
If all classes 1:10,1:11,1:12 are trying to send as much as possible, they will be allowed to send their allowed 30kbps. If, in contrast, 1:10 is the only one sending. It would be allowed to borrow some of the parents bandwidth, since its siblings aren't using it, but it won't be able to use all 100kbps, it will only be able to use 60kbps, because it is limited by ceil.
You can think of it this way. You have to spend tokens in order to send bandwidth. The rate is how fast you are given tokens to spend. The ceil is how many of your siblings unused tokens you are allowed to borrow.
Since you didn't include the classifiers it's hard to deduct what traffic you exactly mean in each class.
For instance, outgoing http or ssh traffic is very important for interactivity, incoming http not so much.
I would guarantee certain bandwidth for each service by saying: I have x kbps for incoming httpd traffic, and it gets divided equally among the users. If you have 10 or 100 users, it's fair." If you have high priority users or low priority users in each of these services you need to have additional classes and classifiers for them.
(Also I hope you know you can only shape outgoing traffic from an interface, NOT the incoming. That means if you want to limit the uplink, you have to work either with the outgoing interface to the internet or use the Intermediate Queuing Device. The lartc.org Guide is a very good resource.)
#!/bin/bash
tc qdisc add dev veth1 parent root handle 1: hfsc default 11
tc class add dev veth1 parent 1: classid 1:1 hfsc sc rate 100mbit ul rate 100mbit
tc class add dev veth1 parent 1:1 classid 1:11 hfsc sc rate 50mbit
tc class add dev veth1 parent 1:1 classid 1:12 hfsc sc umax 1500 dmax 50ms rate 10mbit ul rate 10mbit
tc qdisc add dev veth1 parent 1:12 handle 12 netem delay 150ms
tc filter add dev veth1 parent 1: protocol ip u32 match ip sport 22 0xffff flowid 1:12
This creates a 100mbit class, 50mbit of which is in the default class (but can burst up to 100mbit) whilst the other class permits a realtime requirement so that 1500 byte packets must leave the queue within 50ms, the maximum rate of this class is 10mbit at all times.
Finally we added a leaf qdisc onto that class which actually delays packets leaving the queue by 150ms.
Traffic into the realtime class is selected on the basis of it having a source port 22 attribute (so all ssh traffic).
Best Answer
Rate is the rate they will be allowed to allocate when bandwidth is tight. However, when bandwidth isn't tight, HTB allows classes to "borrow" bandwidth from other classes. Ceil limits how much they can borrow. Lets say you have this:
If all classes 1:10,1:11,1:12 are trying to send as much as possible, they will be allowed to send their allowed 30kbps. If, in contrast, 1:10 is the only one sending. It would be allowed to borrow some of the parents bandwidth, since its siblings aren't using it, but it won't be able to use all 100kbps, it will only be able to use 60kbps, because it is limited by ceil.
You can think of it this way. You have to spend tokens in order to send bandwidth. The rate is how fast you are given tokens to spend. The ceil is how many of your siblings unused tokens you are allowed to borrow.