HFSC Queue Types
real-time: guarantee service curves of all leaf classes
link-sharing: guarantee service curves of interior classes and distribute excess service fairly
upperlimit: not part of HFSC. implemented when HFSC was imported into ALTQ/PF. recommend against using.
real-time and link-share overlap each other
whenever there is a potential of conflict, real-time criteria is used
- Official documentation on HFSC [1]
Notes on HFSC and its syntax within PF+ALTQ
realtime
- method: guaranteed rate
- designed for traffic which has precise latency or throughput requirements
- all realtime values take from total of root queue. (ie. does not inheret from any parent queues)
- maximum value is 75% of total bandwidth in root queue (I've seen it as 80% on newer versions in PF)
linkshare
- method: best-effort
- works with the bandwidth left over after realtime rates have been met.
- all linkshare values take from total of parent queue
- maximum bandwidth is 100%
bandwidth
- pf-specific variable, redundant for linkshare
- recommend setting this to 0Kb when linkshare is explicitly set
queue testqueue bandwidth 0Kb hfsc( linkshare 128Kb )
- or set to linkshare value, if linkshare is omitted
queue testqueue bandwidth 128Kb hfsc( )
- if you omit bandwidth all together, this value PF will complain of syntax errors!!!
( explaination of this redundancy is quoted below from the mailing list)
"q: Who needs two config parameters to control one variable"?
"a: HFSC has 2 distinct bandwidth parameters; one for the realtime scheduling and the other for the linksharing scheduling. So, the bandwidth parameter is redundant but the current implementation is less surprising for those who don't understand hfsc. (I agree that it's confusing for those who knows hfsc, though.)"
Recommendations
Realtime and Linkshare are separate from each other
For services which have a static ceiling (like VoIP) and require a guaranteed throughput rate; give the service a fixed realtime rate and and 0Kb of linkshare.
queue o_voip priority 7 bandwidth 0Kb hfsc(realtime 110Kb )
- The service will get as much bandwidth as it wants, if nothing else is using it
- If other services are fightnig over the available bandwidth. the service will always get 110Kbit/s but nothing more.
For services which dynamically grow in demand, I recommend providing a minimum guarantee in realtime, and a fair part of linkshare.
queue oDly bandwidth 0Kb hfsc( realtime 160Kb linkshare 135Kb )
- The service will get as much bandwidth as it wants, if nothing else is using it.
- If other services are fighting over the available bandwidth:
- The service will always get 160Kb of guaranteed throughput
- The service will get up to an additional 135Kb of the remaining linkshare
For services which are very bursty such as HTTP; I recommend using timed reductions
queue oBrst bandwidth 0Kb hfsc( realtime (160Kb 6000 94Kb) linkshare (135Kb 6000 84Kb))
- The service will get as much bandwidth as it wants, if nothing else is using it.
- If other services are fighting over the available bandwidth:
- The service will always get 160Kb of guaranteed throughput for the first 6 seconds, then drop to 94Kb for any remaining time left
- The service will get up to an additional 135Kb of throughput for the first 6 second, then drop to up to 84Kb for any remaining time left
You can also do this the other way: a rate of 0Kb, then raising to a higher speed after a sec number of milliseconds (when done this way, you can only start at 0)
This may be handy for giving a service a realtime date for the first so many milliseconds, then transferring it to linkshare after that.
queue oBrst bandwidth 0Kb hfsc( realtime (160Kb 6000 1Kb) linkshare (0Kb 6000 135Kb)
(I could not set 0Kb on realtime, it forced me to use at least 1Kb)
Notes
Any traffic which exceeds the assignedrealtime threshhold will reach into linkshare if it is to gain any further bandwidth.
