最後更新: 2024-10-30

介紹

Hierarchical Fair Service Curve

A network packet scheduling algorithm

This allows bulk transfer streams to use the maximum available bandwidth
 without affecting the latency of non-bulk (e.g. interactive) streams.

In short HFSC aims to:

1) guarantee precise bandwidth and delay allocation for all leaf classes
    (realtime criterion) [e.g. VoIP] <= The main "selling" point

2) allocate excess bandwidth fairly as specified by class hierarchy
    (linkshare & upperlimit criterion)

Help: tc-hfcs

Example

Diagram

                         +1:0---------+
                         |    qdisc   |         # Step 1
                         +------------+
                                |
                         +1:1---------+
                         | Root class |         # Step 2
                         |  1500kbit  |
                         +------------+
                        /              \
                  +-1:10------+  +-1:20------+
                  |  User A   |  |  User B   |  # Step 3
                  | 50% share |  | 50% share |
                  | Unlimited |  | 1000kbit  |
                  +-----------+  +-----------+
                 /             \
         +-1:11-------+  +-1:12---------+
         |     Web    |  |     VOIP     |
         | 100% share |  | 20ms Latency |
         | Unlimited  |  |   100kbit    |
         +------------+  +--------------+
            # Step 4        # Step 5

Script

# Save typing when creating classes.
function ca {
  par=$1; class=$2; shift 2
  tc class add dev eth0 parent 1:$par classid 1:$class hfsc "$@"
}

# Step 1
# Create the qdisc. Send unclassified traffic to 1:11.
# If "default" isn't given unclassified traffic is dropped.
tc qdisc add dev eth0 root handle 1:0 hfsc default 11

# Step 2
# Stop link flooding. That class will be the root, of course.
ca 0 1 ls m2 1500kbit ul m2 1500kbit

# Step 3 - Create classes representing each user.
ca 1 10 ls m2 750kbit                       # User A
ca 1 20 ls m2 750kbit ul m2 1000kbit        # User B

# Step 4 - User A's web traffic
ca 10 11 ls m2 1500kbit

# Step 5 - User A VOIP
ca 10 12 rt m1 250kbit d 8ms m2 100kbit

Step 5 - User A VOIP 說明

We said VOIP uses 100kbit, and required 20ms latency.

We also know that HFSC can break its rt latency guarantees by one MTU packet.

Assuming MTU is 1500 bytes, it takes 12 msec to send an MTU sized packet.

1500 [byte] * 8 [bits/byte] / 100000 [bits/sec] = 12 msec

That means we must send the

VOIP packet within 8ms (= 20ms - 12ms) to meet the latency requirements.

The requirements didn't say how big a VOIP packet is,
  but given it has to send a new packet every 20ms the biggest it could be is:

100000 [bit/sec] / 8 [bit/byte] * 0.02 [sec/pkt] = 250 byte/pkt

So, we have 8ms to send 250 bytes, which works out to be:

250 [bytes] * 8 [bit/byte] / 0.008 [sec] = 250kbit

另外寫法

ca 10 12 sc umax 1500b dmax 30ms rate 100kbit

Usage

SC = service curve

tc qdisc add dev $dev root handle $ID: hfsc [default $classID ]
tc add class dev $dev parent parentID classid $ID hfsc [ [ rt  SC ] [ ls  SC ] | [ sc  SC ] ]  [ ul  SC ]

 * If default is not specified, unclassified packets will be dropped.
 * at least one of rt, ls or sc must be specified
 * ul It can only be used if the class has a link share defined.(ls or sc)

curve
ul = upper limit             # The maximum speed link share can send at.
rt = real-time curve
ls = link-sharing curve      # inner classes can only have a link-sharing curve
sc = single service curve    # setting both "rt" and "ls" to the same thing.

rt
This amount of bandwidth is always available to it
 regardless of the other classes use of the link or
 the maximum bandwidth allowed by this class or its parents.(ul & ls)

share the excess capacity
links capacity after real time to the total bandwidth consumed
this class and all it's offspring is equal to the ratio the classes bandwidth to the sum.

ul
set the maximum bandwidth this class and its children are permitted to use.
This only effects sending packets under the "ls".

ls
Apportions how much of a backlogged link's spare capacity
 should be allocated to this class and its children.

dmax & umax

SC = [ umax bytes  dmax ms ] rate BPS

the maximum delay(dmax) at a certain transmission rate(umax)
"d"max : maximum delay
"u"max = unit of work

m1 & d

SC := [ [ m1 BPS ] d SEC ] m2 BPS

a bandwidth assigned for certain amount of time.

m1 : slope of the first segment(start burst state)
d  : x-coordinate of intersection(x-coordinate=time)
m2 : slope of the second segment(steady state)

m1 is simply umax/dmax.
If you omit '[ m1 BPS ] d SEC',  you  will  specify  linear service curve.

BURST-SEC

measured from the last time this class was backlogged.
(ie had packets waiting to be transmitted)

參考

• https://linux-tc-notes.sourceforge.net/tc/doc/sch_hfsc.txt
• https://serverfault.com/questions/105014/does-anyone-really-understand-h...
• https://manpages.ubuntu.com/manpages/oracular/en/man7/tc-hfsc.7.html