有人真的了解Linux / BSD中的HFSC调度如何工作吗？

我阅读了有关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

以下是一些我无法回答的问题，因为这些教程相互矛盾：

1. 我到底需要什么实时曲线？假设A1，A2，B1，B2都是128 kbit / s的链路共享（任何一个都没有实时曲线），那么如果根要分配512 kbit / s，则每个共享将获得128 kbit / s。 A和B当然都是256 kbit / s，对吗？为什么还要另外给A1和B1实时速率为128 kbit / s的曲线？这有什么好处？给予这两个更高的优先级？根据原始论文，我可以通过使用曲线来给它们更高的优先级，这毕竟是HFSC的全部意义所在。通过给两个类别提供[256kbit / s 20ms 128kbit / s]的曲线，它们的优先级都自动达到A2和B2的两倍（平均仍然仅获得128 kbit / s）

2. 实时带宽是否计入链路共享带宽？例如，如果A1和B1都仅具有64kbit / s的实时和64kbit / s的链路共享带宽，那是否意味着一旦通过实时为64kbit / s提供服务，它们的链路共享要求也将得到满足（它们可能会获得多余的带宽，但请忽略一秒钟），或者这意味着它们通过链路共享又获得了64 kbit / s？那么，每个类别是否都具有实时和链接共享的带宽“需求”？或者，如果某个类别的要求比实时曲线更高，那么它的链接份额曲线要比实时曲线高（当前的链接份额要求等于指定的链接份额要求减去已为此提供的实时带宽）类）？

3. 上限曲线是否也适用于实时，仅适用于链接共享或两者都适用？有些教程说一种方式，有些说另一种方式。甚至有人声称上限是实时带宽+链路共享带宽的最大值？真相是什么？

4. 假设A2和B2均为128 kbit / s，如果A1和B1仅是128 kbit / s链路共享，或者是64 kbit / s实时和128 kbit / s链路共享，是否有任何区别？ ，有什么区别？

5. 如果我使用单独的实时曲线来增加类的优先级，为什么我根本不需要“曲线”？为什么实时不统一值和链接共享也不统一值？为什么两条曲线都是？在原始论文中很明显需要曲线，因为每个类只有一个这样的属性。但是现在，有了三个属性（实时，链接共享和上限），我仍然需要在每个属性上绘制曲线吗？为什么我要让曲线形状（不是平均带宽，而是斜率）对于实时流量和链路共享流量而言有所不同？

6. 根据现有的少量文档，对于内部类（类A和B），实时曲线值被完全忽略，它们仅应用于叶子类（A1，A2，B1，B2）。如果是这样，为什么ALTQ HFSC样本配置（搜索3.3样本配置）设置内部类的实时曲线，并声称那些设置了这些内部类的保证率？这不是完全没有意义的吗？（注意：pshare在ALTQ中设置链接共享曲线并磨碎实时曲线；您可以在示例配置上方的段落中看到它）。

7. 一些教程说所有实时曲线的总和可能不高于线速度的80％，另一些教程则说它不得大于线速度的70％。哪一个是对的，或者它们都错了？

8. 一篇教程说您将忘记所有理论。不管实际情况如何（计划程序和带宽分配），都可以根据以下“简化的思维模型”来想象这三个曲线：实时是此类将始终获得的保证带宽。链路共享是此类想要完全满足的带宽，但是不能保证满足。如果有多余的带宽，则该类甚至可能会获得超出满足要求所必需的带宽，但它可能永远不会使用超出上限的带宽。为了使所有这些工作正常进行，所有实时带宽的总和可能不超过线路速度的xx％（请参阅上面的问题，百分比会有所不同）。问题：这对HSFC或多或少是准确的还是完全误解了？

9. 如果上述假设确实正确，那么该模型的优先级在哪里？例如，每个类别都可能具有实时带宽（保证），链路共享带宽（未保证）和上限，但是某些类别的优先级需求仍然高于其他类别。在那种情况下，即使在这些类的实时流量中，我仍然必须以某种方式确定优先级。我会优先考虑曲线的斜率吗？如果是这样，哪条曲线？实时曲线？链接份额曲线？上限曲线？他们都是？我要给所有人一个相同的坡度，还是给每个坡度一个不同的坡度，以及如何找出合适的坡度？

我仍然不希望在这个世界上至少有一群人真正了解HFSC，并能够准确回答所有这些问题。而且这样做不会在答案中互相矛盾；-)

阅读有关HFSC及其表亲的论文不是理解它的好方法。HFSC论文的主要目的是提供对其主张的严格数学证明，而不是解释其工作原理。确实，您不能仅从HFSC论文中了解其工作原理，还必须阅读其引用的论文。如果您对索赔或其证据有任何疑问，那么与论文的作者联系可能是一个好主意，否则我怀疑他们是否会对您的来信感兴趣。

我已经为HFSC编写了教程。如果我下面的解释不清楚，请阅读。

我到底需要什么实时曲线？假设A1，A2，B1，B2都是128 kbit / s的链路共享（任何一个都没有实时曲线），那么如果根要分配512 kbit / s，则每个共享将获得128 kbit / s。 A和B当然都是256 kbit / s，对吗？为什么还要另外给A1和B1实时速率为128 kbit / s的曲线？这有什么好处？给予这两个更高的优先级？根据原始论文，我可以通过使用曲线为它们赋予更高的优先级，这毕竟是HFSC的全部意义所在。通过给两个类别提供[256kbit / s 20ms 128kbit / s]的曲线，它们的优先级都自动地比A2和B2的两倍（仍然平均仅获得128 kbit / s）

实时曲线和链接共享曲线的评估方式不同。实时曲线考虑了一个班级在其整个历史中所做的事情。它必须这样做以提供准确的带宽和延迟分配。不利的一面不是大多数人直觉上认为的公平。在实时情况下，如果某个班级在没有其他人想要它的时候借用带宽，那么当其他人稍后再希望使用它时，它将受到惩罚。这意味着在实时保证下，一个类在很长一段时间内都不会获得带宽，因为它在没有人希望的时候就更早地使用了它。

链接共享是公平的，因为它不会因为使用备用带宽而对类产生不利影响。但是，这意味着它不能提供强大的延迟保证。

将链接共享与提供延迟保证分开是HFSC带来的新成果，该论文在开篇中也说了很多：在本文中，我们研究了支持链接共享和保证的分层资源管理模型和算法。具有解耦的延迟（优先级）和带宽分配的实时服务。 该句子中的关键字已解耦。经过翻译，这意味着您应该说出如何与ls共享未使用的带宽，并指定rt需要哪些实时保证（也称为延迟保证）。两者是正交的。

实时带宽是否计入链路共享带宽？

是。在HFSC论文中，它们根据类已积压后发送的类（即，有等待发送的数据包）来定义带宽。rt和ls之间的唯一区别是，每次类被积压后，rt都会向前看，并从该集合计算出最低的保证带宽，而链路共享仅从类被积压的最后一次开始。因此，rt比ls考虑更多的字节，但是rt也考虑ls考虑的每个字节。

上限曲线是否也适用于实时，仅适用于链接共享或两者都适用？

上限不会阻止发送数据包以满足实时条件。在实时条件下发送的数据包仍然计入上限，因此将来可能会延迟在链路共享条件下发送的数据包。这是实时和链接共享之间的另一个区别。

假设A2和B2均为128 kbit / s，如果A1和B1仅是128 kbit / s链路共享，或者是64 kbit / s实时和128 kbit / s链路共享，是否有任何区别？ ，有什么区别？

是的，确实有所作为。如上文所述，如果您使用实时，则可以保证延迟，但不会公平地共享链接（特别是该类可能会出现带宽不足的情况），并且不执行上限。如果使用链接共享，则不能保证延迟，但是链接共享是公平的，不会出现饥饿的风险，并且会强制执行上限。始终在链接共享之前检查实时性，但这并不是必需的，这意味着链接共享将被忽略。这是因为数据包的计数方式不同。由于历史记录是实时考虑的，因此数据包可能不需要满足实时保证（因为从历史记录中算出一个计数），但是需要满足链路共享，因为它会忽略历史数据包。

如果我使用单独的实时曲线来增加类的优先级，为什么我根本不需要“曲线”？为什么实时不统一值和链接共享也不统一值？为什么两条曲线都是？在原始论文中很明显需要曲线，因为每个类只有一个这样的属性。但是现在，有了三个属性（实时，链接共享和上限），我仍然需要在每个属性上绘制曲线吗？为什么我要让曲线形状（不是平均带宽，而是斜率）对于实时流量和链路共享流量而言有所不同？

实时控制的曲线使您可以将一种特定流量类别（例如VOIP）的紧密延迟换为其他流量类别（例如电子邮件）的较差延迟。当决定在实时约束下发送哪个数据包时，HFSC选择将首先完成发送的数据包。但是，它不使用链接的带宽来计算带宽，而是使用实时曲线分配的带宽。因此，如果我们具有相同长度的VOIP和电子邮件数据包，并且VOIP数据包具有凸曲线，如果该曲线比电子邮件的凹曲线提高了10倍，则将在第一个电子邮件数据包之前发送10个VOIP数据包。但这仅发生在突发时间上，突发时间最多应该是发送几个数据包所花费的时间，即毫秒。此后，VOIP曲线应平坦化，除非暂时退出，否则VOIP不会得到进一步的提升（鉴于V​​OIP是一种低带宽应用程序，它应该这样做）。所有这些的最终结果是确保第一对VOIP数据包的发送速度比其他任何方式都要快，从而使VOIP的延迟时间短，而电子邮件的等待时间则变长。

如前所述，由于链接共享不会查看历史记录，因此无法提供延迟保证。像VOIP这样的实时流量需要坚如磐石的保证。但是，平均而言，链接共享的凸曲线仍将为其流量带来延迟。只是不能保证。这对大多数情况都很好，例如通过电子邮件的网络流量。

根据现有的少量文档，对于内部类（类A和B），实时曲线值被完全忽略，它们仅应用于叶子类（A1，A2，B1，B2）。如果是这样，为什么ALTQ HFSC样本配置（搜索3.3样本配置）为何设置内部类的实时曲线，并声称那些设置了这些内部类的保证率？这不是完全没有意义的吗？（注意：pshare在ALTQ中设置链接共享曲线并磨碎实时曲线；您可以在示例配置上方的段落中看到它）。

该文档是正确的。层次结构（以及内部节点）对实时计算没有任何影响。我不能告诉你为什么ALTQ显然会这样。

一些教程说所有实时曲线的总和可能不高于线速度的80％，另一些教程则说它不得大于线速度的70％。哪一个是对的，或者它们都错了？

两者都是错的。如果您有70％或80％的流量具有必须实时指定的硬延迟要求，那么现实情况是您几乎可以肯定您无法通过所使用的链接满足它们。您需要一个更快的链接。

有人认为指定80％的流量应该是实时的唯一方法是，如果他们将实时作为优先级提升的话。是的，为了提供延迟保证，实际上是在提高某些数据包的优先级。但这只能是毫秒。这就是链接可以应付的所有条件，并且仍然可以提供延迟保证。

需要等待时间保证的流量很少。VOIP是一个，NTP是另一个。其余的都应该通过链接共享来完成。如果您希望Web快速运行，可以通过分配大部分链接容量来使其快速运行。从长期来看，这一份额是有保证的。如果您希望它具有低延迟（平均），请在链接共享下给它一个凸曲线。

一篇教程说您将忘记所有理论。不管实际情况如何（计划程序和带宽分配），都可以根据以下“简化的思维模型”来想象这三个曲线：实时是此类将始终获得的保证带宽。链路共享是此类想要完全满足的带宽，但是不能保证满足。如果有多余的带宽，则该类甚至可能会获得超出满足要求所必需的带宽，但它可能永远不会使用超出上限的带宽。为了使所有这些工作正常进行，所有实时带宽的总和可能不超过线路速度的xx％（请参阅上面的问题，百分比会有所不同）。问题：这对HSFC或多或少是准确的还是完全误解了？

这是一个很好的描述上限。尽管链接共享描述严格准确，但却具有误导性。虽然真正的链路共享不会像实时那样提供硬延迟保证，但与同类产品（如CBQ和HTB）相比，在为该类分配带宽方面做得更好。因此，在说链接共享“不提供保证”时，它会将其保持在任何其他调度程序都可以提供的更高标准上。

实时的描述确实很准确，但是误导我会说错了。顾名思义，实时的目的不是提供有保证的带宽。这是为了提供有保证的等待时间-即，立即发送数据包，而不是稍后根据链接的使用方式随机发送一些时间。大多数流量不需要保证的延迟。

也就是说，实时也不能提供完美的延迟保证。如果也不是通过链接共享来管理链接，则可以这样做，但是大多数用户都希望拥有两者的附加灵活性，而且它不是免费提供的。实时可能错过发送一个MTU数据包所花费的时间。（如果发生这种情况，那是因为这是一个MTU数据包链路共享，而实时保留了该链路的空闲状态，以防它被迫在短期限内收到了必须立即发送的数据包。这是链路共享之间的另一个区别为了提供其保证，即使有要发送的数据包，实时也可以故意使线路保持空闲，因此提供了不到100％的链路利用率。链路共享始终使用100％的链路可用容量。 ，

可以说实时提供硬延迟保证的原因是延迟有限。因此，如果您试图在1Mbit / sec的链路上提供20ms的延迟保证，并且链路共享正在发送MTU大小（1500字节）的数据包，则您会知道其中一个数据包将花费12ms的时间发送。因此，如果您实时告知您想要8ms的延迟，您仍然可以在20ms的期限内完成-绝对有保证。

如果上述假设确实正确，那么该模型的优先级在哪里？例如，每个类别都可能具有实时带宽（保证），链路共享带宽（未保证）和上限，但是某些类别的优先级需求仍然高于其他类别。在那种情况下，即使在这些类的实时流量中，我仍然必须以某种方式确定优先级。我会优先考虑曲线的斜率吗？如果是这样，哪条曲线？实时曲线？链接份额曲线？上限曲线？他们都是？我要给所有人一个相同的坡度，还是给每个坡度一个不同的坡度，以及如何找出合适的坡度？

没有优先级模型。说真的 如果要为流量提供绝对优先级，请使用pfifo。那就是它的目的。而且要注意，如果你给Web流量的绝对优先于电子邮件流量，那就是让网络流量饱和的链接，因此没有电子邮件包打通，在所有。然后，您所有的电子邮件连接都会消失。

实际上，没有人希望获得这种优先权。他们想要的是HFSC所提供的。如果您实际上有实时流量，则HFSC可以提供。但这将是全部。对于其余的内容，HFSC允许您说“在拥塞的链接上，将90％的资源分配到Web上，让电子邮件以10％的速度滴加，哦，快速发送奇数DNS数据包，但不要让别人用它来DOS。”

您可以使用不同的名称定义曲线：

• rt，实时曲线，带宽/延迟保证。
• ls，链路共享曲线，带宽/延迟共享（基于邻居叶子的配置）
• ul，上限曲线，可能达到的最大带宽/延迟。

我到底需要什么实时曲线？假设A1，A2，B1，B2都是128 kbit / s的链路共享（任何一个都没有实时曲线），那么如果根要分配512 kbit / s，则每个共享将获得128 kbit / s。 A和B当然都是256 kbit / s，对吗？为什么还要另外给A1和B1实时速率为128 kbit / s的曲线？这有什么好处？给予这两个更高的优先级？根据原始论文，我可以通过使用曲线为它们赋予更高的优先级，这毕竟是HFSC的全部意义所在。通过给两个类别提供[256kbit / s 20ms 128kbit / s]的曲线，它们的优先级都自动地比A2和B2的两倍（仍然平均仅获得128 kbit / s）

当您在仅使用费率的HFSC中进行定义时，它将自动将“ dmax”设置为0。这基本上意味着它不考虑延迟。良好的HFSC配置应同时包括要用于您的班级的带宽和延迟边界，否则算法将无法准确确定班级应获得的优先级。

每当您为数据包赋予优先级时，其他数据包的优先级都必须降低。基于“ dmax”和“ rate”值，将使用虚拟计时器对所有类别进行多路复用。有关更多信息，请参考tc-hfsc（7）。

实时带宽是否计入链路共享带宽？例如，如果A1和B1都仅具有64kbit / s的实时和64kbit / s的链路共享带宽，那是否意味着一旦通过实时为64kbit / s提供服务，它们的链路共享要求也将得到满足（它们可能会获得多余的带宽，但请忽略一秒钟），或者这意味着它们通过链路共享又获得了64 kbit / s？那么，每个类别是否都具有实时和链接共享的带宽“需求”？或者，如果某个类别的要求比实时曲线更高，那么它的链接份额曲线要比实时曲线高（当前的链接份额要求等于指定的链接份额要求减去已为此提供的实时带宽）类）？

如果流没有超出类的链接共享定义的边界，则永远不会使用实时曲线。在这种情况下，定义实时曲线可以使您例如：保证一定的“ dmax”。

如果您的链接共享定义完美无缺，那么您就不需要实时曲线。您可以只定义服务曲线（sc），但这会使您的配置工作更加困难。

上限曲线是否也适用于实时，仅适用于链接共享或两者都适用？有些教程说一种方式，有些说另一种方式。甚至有人声称上限是实时带宽+链路共享带宽的最大值？真相是什么？

类的上限曲线仅适用于链接共享，当您定义上限曲线时，您必须定义链接共享曲线。但是，父类的上限曲线仍然适用。

假设A2和B2均为128 kbit / s，如果A1和B1仅是128 kbit / s链路共享，或者是64 kbit / s实时和128 kbit / s链路共享，是否有任何区别？ ，有什么区别？

如果例如A2 = 0 kbits / s和B2 = 256 kbits / s，则存在细微差异。然后，A2的虚拟时间将达到最大。每当将数据包分类为A2时，便会立即对其进行处理。但是B2的实时曲线仍将确保能够传输至少64 kbit / s

如果我使用单独的实时曲线来增加班级的优先级，为什么我完全需要“曲线”？为什么实时不统一值和链接共享也不统一值？为什么两条曲线都是？在原始论文中很明显需要曲线，因为每个类只有一个这样的属性。但是现在，有了三个属性（实时，链接共享和上限），我仍然需要在每个属性上绘制曲线吗？为什么我要让曲线形状（不是平均带宽，而是斜率）对于实时流量和链路共享流量而言有所不同？

实时曲线不会在相邻叶子之间共享流量，链接共享曲线却可以。

根据现有的少量文档，对于内部类（类A和B），实时曲线值被完全忽略，它们仅应用于叶子类（A1，A2，B1，B2）。如果是这样，为什么ALTQ HFSC样本配置（搜索3.3样本配置）为何设置内部类的实时曲线，并声称那些设置了这些内部类的保证率？这不是完全没有意义的吗？（注意：pshare在ALTQ中设置链接共享曲线并磨碎实时曲线；您可以在示例配置上方的段落中看到它）。

的确，内部类将忽略实时曲线，它们仅应用于叶子类。但是，在叶类的计算中会考虑在这些内部类上定义的实时曲线。

一些教程说所有实时曲线的总和可能不高于线速度的80％，另一些教程则说它不得大于线速度的70％。哪一个是对的，或者它们都错了？

它们的意思是：您不能对所有流量进行优先级排序……只要给数据包赋予优先级，其他数据包的优先级就必须降低。如果您过度保证，该算法将变得毫无意义。定义获得优先级的类，并定义可能受到影响的类。

一篇教程说您将忘记所有理论。不管实际情况如何（计划程序和带宽分配），都可以根据以下“简化的思维模型”来想象这三个曲线：实时是此类将始终获得的保证带宽。链路共享是此类想要完全满足的带宽，但是不能保证满足。如果有多余的带宽，则该类甚至可能会获得超出满足要求所必需的带宽，但它可能永远不会使用超出上限的带宽。为了使所有这些工作正常进行，所有实时带宽的总和可能不超过线路速度的xx％（请参阅上面的问题，百分比会有所不同）。问题：这对HSFC或多或少是准确的还是完全误解了？

这是对的。

如果上述假设确实正确，那么该模型的优先级在哪里？例如，每个类别都可能具有实时带宽（保证），链路共享带宽（未保证）和上限，但是某些类别的优先级需求仍然高于其他类别。在那种情况下，即使在这些类的实时流量中，我仍然必须以某种方式确定优先级。我会优先考虑曲线的斜率吗？如果是这样，哪条曲线？实时曲线？链接份额曲线？上限曲线？他们都是？我要给所有人一个相同的坡度，还是给每个坡度一个不同的坡度，以及如何找出合适的坡度？

例如，HFSC和HTB之间的区别在于HFSC将允许您准确定义所需的优先级。您可以通过使用“ dmax”值定义最小和最大边界来实现。

最后，一个指南似乎解释了大多数不一致之处，以及当前的实现方式与原始论文有何不同：

http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html

根据该指南，关于HFSC的许多其他指南和论坛帖子完全是胡说八道；它只是显示了HFSC的复杂性，因为许多看起来像专家并且假装对HFSC完全了解的人，实际上仅是部分知识，并且由于对概念的误解以及所有这些设置如何共同作用而做出虚假陈述。

我想我最终将放弃HFSC。如果您可以正确设置HFSC，则它可能是您可以获得的最佳QoS，但是完全搞砸的机会远大于成功的机会。

如果您无法掌握原始作者的信息，那么我可以尝试以下方法：

1. 进入linux内核源代码树并找到实现“ TC调度框架”的C文件
2. 查看标题并找到代码的作者。
3. “ TC调度框架”的电子邮件程序员要求他们提供有关其实现的文献。

也可以尝试检查引用此文章的其他较新论文。可能会有新的论文在该领域继续进行研究，并且可能包含有关您所问问题的更多信息。