我阅读了有关 HFSC的原始SIGCOMM '97 PostScript 论文，它在技术上非常技术性，但我了解基本概念。您可以指定凸或凹的服务曲线，而不是提供线性服务曲线（与几乎所有其他调度算法一样），因此可以解耦带宽和延迟。然而，即使这篇论文提到了正在使用的调度算法（实时和链路共享），它总是只提到每个调度类的一条曲线（通过指定这条曲线来完成解耦，只需要一条曲线） ）。
现在已经使用ALTQ调度框架为BSD（OpenBSD、FreeBSD等）实现了HFSC，并且已经使用TC调度框架（iproute2的一部分）在Linux上实现了HFSC。这两种实现方式增加了两个额外的服务曲线，这是不是在原来的文件！实时服务曲线和上限服务曲线。再次请注意，原始论文提到了两种调度算法（实时和链接共享），但在那篇论文中，它们都适用于一条服务曲线。您目前在 BSD 和 Linux 中发现的任何一条都没有两条独立的服务曲线。
更糟糕的是，某些版本的 ALTQ 似乎为 HSFC 添加了额外的队列优先级（原始论文中也没有优先级这样的东西）。我发现几个 BSD HowTo 提到了这个优先级设置（即使最新的 ALTQ 版本的手册页知道 HSFC 没有这样的参数，所以官方它甚至不存在）。
这一切都使得 HFSC 调度比原始论文中描述的算法更加复杂，互联网上有大量教程经常相互矛盾，一个声称与另一个相反。这可能是为什么似乎没有人真正了解 HFSC 调度的真正工作原理的主要原因。在我提出问题之前，我们需要某种设置示例。我将使用一个非常简单的方法，如下图所示：
替代文字 http://f.imagehost.org/0177/hfsc-test-setup.png
以下是一些我无法回答的问题，因为教程相互矛盾：
为什么我需要实时曲线？假设 A1、A2、B1、B2 都是 128 kbit/s 的链路共享（任何一个都没有实时曲线），那么如果根有 512 kbit/s 的分配（和A和B当然都是256 kbit/s），对吗？为什么我还要给 A1 和 B1 一条 128 kbit/s 的实时曲线？这有什么用？给这两个更高的优先级？根据原始论文，我可以通过使用曲线给他们更高的优先级，这毕竟是 HFSC 的全部内容。通过给这两个类一个 [256kbit/s 20ms 128kbit/s] 的曲线，它们都会自动获得比 A2 和 B2 两倍的优先级（平均仍然只有 128 kbit/s）
实时带宽是否计入链路共享带宽？例如，如果 A1 和 B1 都只有 64kbit/s 实时带宽和 64kbit/s 链路共享带宽，这是否意味着一旦它们通过实时 64kbit/s …
我想为我们的互联网线路添加某种流量管理。看了很多文档后，我觉得HFSC对我来说太复杂了（我不了解所有曲线的东西，恐怕我永远不会弄对），不推荐CBQ，基本上HTB是方法去大多数人。
我们的内部网络有三个“网段”，我想在这些网段之间或多或少平均地共享带宽（至少在开始时）。此外，我必须根据至少三种流量（实时流量、标准流量和批量流量）对流量进行优先级排序。带宽共享并不像实时流量应始终被视为优质流量这一事实重要，但当然也没有其他流量类别可能会饿死。
问题是，什么更有意义并且还能保证更好的实时吞吐量：
每个段创建一个类，每个类都具有相同的速率（根据 HTB 开发人员的说法，对于没有叶子的类，优先级无关紧要）并且这些类中的每一个都有三个子类（叶子），用于 3 个优先级（具有不同的优先级）和不同的费率）。
每个优先级有一个类，每个类都有不同的速率（同样优先级无关紧要），每个有 3 个子类，每个段一个，而实时类中的所有 3 个都具有最高的优先级，批量中的最低优先级类，等等。
我将尝试使用以下 ASCII 艺术图像更清楚地说明这一点：
Case 1:
root --+--> Segment A
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment B
| +--> High Prio
| +--> Normal Prio
| +--> Low Prio
|
+--> Segment C
+--> High Prio
+--> Normal Prio
+--> Low Prio
Case 2:
root --+--> High Prio
| +--> Segment A
| +--> Segment B
| +--> Segment …