Mec*_*cki 36 linux qos bsd traffic-management traffic-shaping
我阅读了有关 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 获得服务，它们的链路共享要求也得到满足（它们可能获得多余的带宽，但让我们暂时忽略它）还是这是否意味着他们通过链接共享获得了另一个 64 kbit/s？那么每个班级是否都有实时加链接共享的带宽“要求”？或者，如果链路共享曲线高于实时曲线（当前链路共享要求等于指定的链路共享要求减去已提供给该类的实时带宽），则该类是否仅具有高于实时曲线的要求？班级）？
上限曲线是否也适用于实时，仅适用于链接共享，还是适用于两者？一些教程说一种方式，另一些说另一种方式。甚至有人声称上限是实时带宽+链路共享带宽的最大值？真相是什么？
假设 A2 和 B2 都是 128 kbit/s，如果 A1 和 B1 仅是 128 kbit/s 链路共享，或 64 kbit/s 实时和 128 kbit/s 链路共享，如果是，是否有任何区别，有什么区别？
如果我使用单独的实时曲线来增加类的优先级，为什么我需要“曲线”呢？为什么实时不是固定值而链接共享也是固定值？为什么都是曲线？原始论文中很清楚需要曲线，因为每个类只有一个这样的属性。但是现在，有了三个属性（实时、链接共享和上限），我还需要在每个属性上设置曲线吗？为什么我希望实时和链接共享流量的曲线形状（不是平均带宽，而是它们的斜率）不同？
根据可用的小文档，内部类（A 类和 B 类）完全忽略实时曲线值，它们仅适用于叶类（A1、A2、B1、B2）。如果这是真的，为什么ALTQ HFSC 示例配置（搜索3.3 示例配置）在内部类上设置实时曲线并声称那些设置了这些内部类的保证率？这不是完全没有意义吗？（注意：pshare 在 ALTQ 中设置链路共享曲线并磨碎实时曲线；您可以在示例配置上方的段落中看到这一点）。
有的教程说所有实时曲线的总和不能高于线速度的80%，也有人说不能高于线速度的70%。哪一个是对的，或者他们都错了？
一个教程说你会忘记所有的理论。无论实际情况如何（调度程序和带宽分配），请根据以下“简化思维模型”想象三个曲线：实时是此类将始终获得的保证带宽。link-share 是该类想要完全满足的带宽，但不能保证满足。如果有多余的带宽，该类甚至可能会获得比满足所需更多的带宽，但它可能永远不会使用超过上限规定的带宽。为了使所有这些工作，所有实时带宽的总和可能不会超过线路速度的 xx%（请参阅上面的问题，百分比会有所不同）。问题：这或多或少是准确的还是对 HSFC 的完全误解？
如果上述假设确实准确，那么该模型中的优先级在哪里？例如，每个类可能具有实时带宽（有保证）、链路共享带宽（不保证）和可能的上限，但仍然有些类具有比其他类更高的优先级需求。在那种情况下，我仍然必须以某种方式确定优先级，即使在这些类的实时流量中也是如此。我会根据曲线的斜率确定优先顺序吗？如果是，那是哪条曲线？实时曲线？链接共享曲线？上限曲线？他们都？我会给所有这些坡度相同的坡度还是给每个坡度不同的坡度，以及如何找出正确的坡度？
我仍然没有失去希望，这个世界上至少有一群真正了解 HFSC 并能够准确回答所有这些问题的人。这样做而不会在答案中相互矛盾会非常好;-)
Rus*_*art 18
阅读有关 HFSC 及其表亲的论文并不是理解它的好方法。HFSC 论文的主要目标是为其声明提供严格的数学证明，而不是解释其工作原理。实际上，仅从 HFSC 论文中您无法理解它是如何工作的，您还必须阅读它所引用的论文。如果您对声明或其证明有疑问，那么联系论文的作者可能是个好主意，否则我怀疑他们是否有兴趣听取您的意见。
我已经为 HFSC编写了一个教程。如果我下面的解释不清楚，请阅读它。
为什么我需要实时曲线？假设 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）
实时曲线和链路共享曲线的评估方式不同。实时曲线考虑了一个班级在其整个历史中所做的事情。它必须这样做才能提供准确的带宽和延迟分配。不利的一面并不是大多数人直觉上认为的公平。在实时情况下，如果一个班级在没有人想要的时候借用了带宽，那么当其他人想要回来时，它就会受到惩罚。这意味着在实时保证下，一个类可以长时间没有带宽，因为它在没有人想要的时候使用它。
链接共享是公平的，因为它不会惩罚使用空闲带宽的类。然而，这意味着它不能提供强大的延迟保证。
链路共享与提供延迟保证的分离是 HFSC 带来的新事物，该论文在其开场白中说了很多：在本文中，我们研究了支持链路共享和保证的分层资源管理模型和算法具有解耦延迟（优先级）和带宽分配的实时服务。 那句话中的关键词是解耦的。翻译过来，这意味着您需要说明如何与 ls 共享未使用的带宽，并指定 rt 需要哪些实时保证（又名延迟保证）。两者是正交的。
实时带宽是否计入链路共享带宽？
是的。在 HFSC 论文中，他们根据类已经积压（即有数据包等待发送）后发送的内容来定义带宽。rt 和 ls 之间的唯一区别是 rt 从每次类积压的时间开始并计算该集合中的最低保证带宽，而链接共享仅从类积压的最后一次查看。所以 rt 比 ls 考虑更多的字节，但 ls 考虑的每个字节也被 rt 考虑。
上限曲线是否也适用于实时，仅适用于链接共享，还是适用于两者？
上限不停止发送数据包以满足实时条件。实时条件下发送的数据包仍然计入上限，因此将来可能会延迟链路共享条件下发送的数据包。这是实时和链接共享之间的另一个区别。
假设 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 将不会在未来得到提升，除非它退后一段时间（鉴于 VOIP 是一个低带宽应用程序，它应该这样做）。所有这一切的最终结果是确保前几个 VOIP 数据包的发送速度比其他任何数据包都快，从而使 VOIP 具有低延迟，但代价是电子邮件的延迟较高。
正如我之前所说，由于链接共享不查看历史记录，因此无法提供延迟保证。像 VOIP 这样的实时流量需要坚如磐石的保证。然而，平均而言，链路共享凸曲线仍会为其流量提供延迟提升。只是不能保证。这对大多数事情来说都很好，比如通过电子邮件的网络流量。
根据可用的小文档，内部类（A 类和 B 类）完全忽略实时曲线值，它们仅适用于叶类（A1、A2、B1、B2）。如果这是真的，为什么 ALTQ HFSC 示例配置（搜索 3.3 示例配置）在内部类上设置实时曲线并声称那些设置了这些内部类的保证率？这不是完全没有意义吗？（注意：pshare 在 ALTQ 中设置链路共享曲线并磨碎实时曲线；您可以在示例配置上方的段落中看到这一点）。
文档是正确的。层次结构（以及内部节点）对实时计算没有任何影响。我不能告诉你为什么 ALTQ 显然认为它确实如此。
有的教程说所有实时曲线的总和不能高于线速度的80%，也有人说不能高于线速度的70%。哪一个是对的，或者他们都错了？
两者都是错误的。如果您的流量的 70% 或 80% 具有必须实时指定的硬延迟要求，那么现实情况是您几乎可以肯定您无法通过您使用的链接满足它们。您需要一个更快的链接。
有人认为指定 80% 的流量应该是实时的唯一方法是他们是否将实时作为优先级提升。是的，为了提供延迟保证，您实际上是在提高某些数据包的优先级。但它应该只持续几毫秒。这就是链路可以处理的所有内容，并且仍然提供延迟保证。
需要延迟保证的流量非常少。VOIP 是一种，NTP 是另一种。其余的都应该通过链接共享来完成。如果您希望网络速度快，则可以通过为其分配大部分链接容量来使其速度快。该份额是长期保证的。如果你希望它是低延迟（平均），在链接共享下给它一个凸曲线。
一个教程说你会忘记所有的理论。无论实际情况如何（调度程序和带宽分配），请根据以下“简化思维模型”想象三个曲线：实时是此类将始终获得的保证带宽。link-share 是该类想要完全满足的带宽，但不能保证满足。如果有多余的带宽，该类甚至可能会获得比满足所需更多的带宽，但它可能永远不会使用超过上限规定的带宽。为了使所有这些工作，所有实时带宽的总和可能不会超过线路速度的 xx%（请参阅上面的问题，百分比会有所不同）。问题：这或多或少是准确的还是对 HSFC 的完全误解？
这是一个很好的描述上限。虽然链接共享描述严格准确，但它具有误导性。虽然真正的链接共享不像实时那样提供硬延迟保证，但它在为类分配带宽方面做得比其竞争对手（如 CBQ 和 HTB）更好。因此，在说链接共享“不提供保证”时，它将其保持在任何其他调度程序可以提供的更高标准。
实时的描述设法既准确又准确，但具有误导性，我认为它是错误的。顾名思义，实时的目的不是提供有保证的带宽。它是为了提供有保证的延迟 - 即数据包立即发送，而不是稍后发送的随机时间，具体取决于链接的使用方式。大多数流量不需要保证延迟。
也就是说，实时也不能提供完美的延迟保证。如果链接也不是由链接共享管理，它可以，但大多数用户希望同时拥有两者的额外灵活性，而且它不是免费的。实时可能会错过发送一个 MTU 数据包所需的延迟期限。（如果发生这种情况，那将是因为它是一个 MTU 数据包链路共享偷偷溜进来，同时实时保持链路空闲，以防它收到必须立即发送的具有短期限的数据包。这是链路共享之间的另一个区别和实时。为了保证实时，即使有数据包要发送，实时也可能故意保持线路空闲，从而提供低于 100% 的链路利用率。链路共享始终使用 100% 的可用链路容量。与实时不同,
可以说实时提供硬延迟保证的原因是延迟是有界的。因此，如果您尝试在 1Mbit/sec 链路上提供 20 毫秒的延迟保证，并且链路共享正在发送 MTU 大小（1500 字节）的数据包，您知道其中一个数据包需要 12 毫秒才能发送。因此，如果你告诉实时你想要 8 毫秒的延迟，你仍然可以满足 20 毫秒的最后期限——绝对保证。
如果上述假设确实准确，那么该模型中的优先级在哪里？例如，每个类可能具有实时带宽（有保证）、链路共享带宽（不保证）和可能的上限，但仍然有些类具有比其他类更高的优先级需求。在那种情况下，我仍然必须以某种方式确定优先级，即使在这些类的实时流量中也是如此。我会根据曲线的斜率确定优先顺序吗？如果是，那是哪条曲线？实时曲线？链接共享曲线？上限曲线？他们都？我会给所有这些坡度相同的坡度还是给每个坡度不同的坡度，以及如何找出正确的坡度？
没有优先级模型。严重地。如果您想为流量提供绝对优先级，请使用 pfifo。这就是它的用途。而且要注意，如果你给Web流量的绝对优先于电子邮件流量，那就是让网络流量饱和的链接，因此没有电子邮件包打通，在所有。然后您所有的电子邮件连接都会消失。
实际上，没有人想要这种优先顺序。他们想要的是HFSC提供的。如果您确实有实时流量，HFSC 会提供。但这将是全部。其余的，HFSC 允许您说“在拥塞的链接上，将 90% 分配给网络，让电子邮件以 10% 的速度流过，然后快速发送奇怪的 DNS 数据包，但不要让别人用它来攻击我。”
小智 5
您可以定义具有不同名称的曲线：
为什么我需要实时曲线？假设 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）
当您在 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%。哪一个是对的，或者他们都错了？
它们的意思是：您不能对所有流量进行优先级排序……每当您赋予数据包优先级时，其他数据包的优先级就必须降低。如果你过度保证，算法就会变得毫无意义。定义获得优先级的类并定义可能受到影响的类。
一个教程说你会忘记所有的理论。无论实际情况如何（调度程序和带宽分配），请根据以下“简化思维模型”想象三个曲线：实时是此类将始终获得的保证带宽。link-share 是该类想要完全满足的带宽，但不能保证满足。如果有多余的带宽，该类甚至可能会获得比满足所需更多的带宽，但它可能永远不会使用超过上限规定的带宽。为了使所有这些工作，所有实时带宽的总和可能不会超过线路速度的 xx%（请参阅上面的问题，百分比会有所不同）。问题：这或多或少是准确的还是对 HSFC 的完全误解？
这是对的。
如果上述假设确实准确，那么该模型中的优先级在哪里？例如，每个类可能具有实时带宽（有保证）、链路共享带宽（不保证）和可能的上限，但仍然有些类具有比其他类更高的优先级需求。在那种情况下，我仍然必须以某种方式确定优先级，即使在这些类的实时流量中也是如此。我会根据曲线的斜率确定优先顺序吗？如果是，那是哪条曲线？实时曲线？链接共享曲线？上限曲线？他们都？我会给所有这些坡度相同的坡度还是给每个坡度不同的坡度，以及如何找出正确的坡度？
例如 HFSC 和 HTB 之间的区别在于 HFSC 将允许您准确定义您希望它具有多少优先级。您可以通过使用 'dmax' 值定义最小和最大边界来实现这一点。
