We will use this page to assemble Documentation information
* in hfsc, "realtime" is the scheduler used to guarantee upper bound delay
for a class it is valid only for child queues. "Linkshare" shares the bandwidth
between classes if available, and a hard limit for a "linkshare" specification
can be set by "upperlimit".
* if you DO not specify "linkshare", you should specify bandwidth.
* HFSC isn't documented real well, but the bandwidth option is used if
"linkshare" m2 parameter is not specified. The curve is used as a "weight" for bandwidth
distribution, not as a hard limit. So a 25% linkshare for each should
distribute available bandwidth equally among those waiting it.
* The hfsc(upperlimit) option would do hard bandwidth limiting.
* 'realtime' is the maximum guarantee; its m1 parameter will always be satisfied in the
timeframe specified by d and m2 is the maximum that this discipline will allow to be used,
'linkshare' is for sharing the remaining bandwidth, after all realtime' guarantees have been taken care of.
pf also has 'upperlimit' for a hard limit. So a queue will get "bandwidth = 'realtime'
than 'linkshare', if it qualifies for it, in the bounds specified by 'upperlimit'.
* 'upperlimit' m1 parameter can even be used as limiting the bursting option.
It means that in the timeframe(d) you will not get more than packet size(m1) service.
Example researched by Leon (leoandru (at) gmail (dot) com):
root (4Mbps) | +---------------+---------------+ | | | A (1.5Mbps) B (1.5Mbps) C (1Mbps) | | | +---+---+ +---+---+ +---+---+ | | | | | | video music http game voice ssh (1Mbps) (500kbps) (1Mbps)(500Kbps)(500Kbps) (500Kbps)
Say that the hierarchy is your setup used for you office, with bandwidth assigned to departments A,B,C accordingly. using CBQ you assign the priorities of 7, 4, 1 to A,B and C respectively. Bill in department A decided to stream tom & jerry cartoon :) during work hours and GeekGod in department B is pulling the latest version of pfSense over http. and I'm trying to talk to customers on the phone and ssh to client's machine over the net in department C. Because both department has a higher priority than my department C, their traffic will get preference over mine in most cases (not fair), this may delay the packets in my voice and ssh session long enough to make them fall below acceptable levels, my voice call gets choppy and ssh unresponsive (high latency). Because the priority is static there is nothing to be done about it.
Lets say you use HFSC instead, replace the priorities with some realtime values. (realtime is only done on leaf queues) to my voice of 500Kb/s and same to ssh. hfsc calculates a minimum deadline on every single packet in my session, when Bill and Scott starts to endanger the deadline on my packets the priority on my session starts to increase the longer they stay in the queue or as time gets closer to the each packet's deadline. If and when that deadline is reached hfsc realize that my service curve (guaranteed bandwidth) is going to be broken and switches to realtime scheduling and sends my packet out over both Bill's and Scott's packets. Dynamic priority as the algorithm puts it. CBQ can guarantee the session bandwidth but cannot guarantee the delay (think of a satellite link).
An easy way of thinking about this is an algorithm that queues up 500 1Kb packets and send them all within 1 second, the bandwidth is met but there is a delay of 1 second between each transmission. In this case the HFSC algorithm will make sure to send each of the 500 packet with an average delayed 1/500s on each packet, guaranteeing the delay and the bandwidth allocation at the same time. This is something very important as my ssh session will not use its 500Kbps of the bandwidth if it sends one packet per second, the delay on that one packet is what really matters here. While CBQ priority can do the same its weakness lies where the queueing hierarchy becomes nested, like the hierarchy above.