我读了关于HFSC的原始SIGCOMM '97 PostScript文件 ，这在技术上非常有用，但是我理解这个基本概念。 您可以指定一个凸或凹的服务曲线，而不是给出线性服务曲线（与其他几乎所有其他调度algorithm一样），因此可以分离带宽和延迟。 然而，尽pipe本文提到了正在使用的调度algorithm（实时和链接共享），但每个调度类总是只提到一条曲线（通过指定该曲线来完成解耦，只需要一条曲线）。
现在已经使用ALTQ调度框架为BSD（OpenBSD，FreeBSD等）实现了HFSC，并使用TC调度框架 （iproute2的一部分）实现了Linux。 两个实现都添加了两条额外的服务曲线，这些曲线并不在原始文件中！ 实时服务曲线和上限服务曲线。 再次请注意，原文提到了两种调度algorithm（实时和链接共享），但是在这篇论文中，这两种调度algorithm都是单一的服务曲线。 BSD和Linux目前都没有两个独立的服务曲线。
更糟糕的是，某些版本的ALTQ似乎给HSFC增加了一个额外的队列优先权（在原始文件中没有优先权）。 我发现了几个BSD HowTo提到这个优先级设置（尽pipe最新的ALTQ版本的手册页不知道HSFC的这个参数，所以官方它甚至不存在）。
这一切都使得HFSC的调度比原始文件中描述的algorithm更复杂，互联网上有大量的教程互相矛盾，一个声称与另一个相反。 这可能是没有人真正了解HFSC调度真正起作用的主要原因。 在问我的问题之前，我们需要一些样本设置。 我将使用一个非常简单的，如下图所示：
替代文字http://f.imagehost.org/0177/hfsc-test-setup.png
以下是我无法回答的一些问题，因为教程互相矛盾：
我该怎么做需要一个实时曲线？ 假设A1，A2，B1，B2都是128kbit / s的链路共享（任何一条都没有实时曲线），那么如果根分配512kbit / s，每个链路将得到128kbit / s A和B当然都是256kbit / s），对吗？ 为什么我还要给A1和B1 128 kbit / s的实时曲线？ 这有什么好处？ 为了给予这两个更高的优先？ 根据原始文件，我可以通过使用曲线给予他们更高的优先级，这就是HFSC最重要的。 通过给这两个类别[256kbit / s 20ms，128kbit / s]的曲线，它们的优先级比A2和B2的优先级高两倍（平均只能达到128kbit / s）
实时带宽是否计入链路共享带宽？ 例如，如果A1和B1都只有64kbit / s的实时和64kbit / s的链路共享带宽，这是否意味着一旦它们通过实时服务64kbit / s，它们的链路共享要求也是可以满足的获得多余的带宽，但让我们忽略一秒钟），或者这意味着他们通过链路共享获得另外的64 kbit / s？ 那么每个class级是否有一个实时加链接共享的带宽“要求”？ 或者，如果链路共享曲线高于实时曲线（当前链路共享要求等于指定的链路共享要求减去已经提供给此的实时带宽），那么只有比实时曲线更高的要求类）？
是否将上限曲线应用于实时，仅用于链接共享，或者可能同时应用于两者？ 有些教程是用一种方式说的，有些用另一种方式说的。 有人甚至认为上限是实时带宽+链路共享带宽的最大值？ 什么是真相？
假设A2和B2都是128 kbit / s，如果A1和B1只有128 kbit / s链路共享，或64 kbit / s实时和128 kbit / s链路共享，是否有区别？如果是，有什么区别？
如果我使用单独的实时曲线来增加课程的优先级，为什么我需要“曲线”呢？ 为什么不是实时的价值链接和平价？ 为什么都是曲线？ 在原始论文中对曲线的需求是清楚的，因为每个类只有一种属性。 但是现在，有三个属性（实时，链接共享和上限），我还需要每条曲线吗？ 为什么我会希望曲线形状 （不是平均带宽，但是它们的斜率）对于实时和链路共享stream量是不同的？
根据可用的文档，实时曲线值对于内部类（A类和B类）是完全忽略的，它们仅适用于叶类（A1，A2，B1，B2）。 如果这是真的，为什么ALTQ HFSC示例configuration （search3.3示例configuration ）设置内部类的实时曲线，并声称那些设置这些内部类的保证率？ 这不完全没有意义吗？ （注意：pshare将链接共享曲线设置为ALTQ并筛选实时曲线;您可以在示例configuration上方的段落中看到这一点）。
有些教程说，所有实时曲线的总和可能不会高于线速度的80％，有些则说不能高于线速度的70％。 哪一个是对的，或者他们可能都是错的？
一个教程说，你应该忘记所有的理论。 无论事情如何工作（调度程序和带宽分配），根据下面的“简化思维模型”想象这三条曲线：实时是这个类将保证的带宽。 link-share是这个class想要充分满足的带宽，但是满意度是无法保证的。 如果有过多的带宽，class级甚至可能获得更多的带宽而不是必要的满足，但它可能永远不会超过上限说。 为此，所有实时带宽的总和可能不高于线速度的xx％（参见上面的问题，百分比变化）。 问题：这或多或less是对HSFC的误解？
如果上面的假设真的是准确的，那么模型中的优先级在哪里？ 例如，每个class级可能有一个实时带宽（保证），一个链路共享带宽（不保证），也可能是一个上限，但仍然有一些class级比其他class级有更高的优先级需求。 在这种情况下，我仍然必须优先考虑，即使是那些类的实时stream量。 我会优先考虑曲线的斜率吗？ 如果是这样，哪条曲线？ 实时曲线？ 链接分享曲线？ 上限曲线？ 他们全部？ 我会把所有的人都倾斜在一起还是不一样，如何找出正确的倾斜？
我仍然没有失望，至less在这个世界上至less有一个人真正了解HFSC，并且能够准确地回答所有这些问题。 这样做而不会在答案中相互矛盾将是非常好的;-)
阅读有关HFSC及其表兄弟的文件并不是理解它的好方法。 HFSC论文的主要目标是提供严格的mathcertificate，而不是解释它的工作原理。 事实上，你不能单单从HFSC的论文中了解它是如何工作的，你也必须阅读它所参考的论文。 如果您的申诉或certificate有问题，那么联系论文的作者可能是一个好主意，否则我怀疑他们会有兴趣收到您的来信。
我已经写了一个HFSC的教程 。 如果我下面的解释不清楚，请阅读。
我该怎么做需要一个实时曲线？ 假设A1，A2，B1，B2都是128kbit / s的链路共享（任何一条都没有实时曲线），那么如果根分配512kbit / s，每个链路将获得128kbit / s A和B当然都是256kbit / s），对吗？ 为什么我还要给A1和B1 128 kbit / s的实时曲线？ 这有什么好处？ 为了给予这两个更高的优先？ 根据原始文件，我可以通过使用曲线给予他们更高的优先级，这就是HFSC的全部内容。 通过给这两个类别[256kbit / s 20ms，128kbit / s]的曲线，它们的优先级比A2和B2的优先级高两倍（平均只能达到128kbit / s）
实时曲线和链接共享曲线以不同的方式进行评估。 实时曲线考虑了课程在整个历史中所做的工作。 它必须这样做才能提供准确的带宽和延迟分配。 缺点不是大多数人直觉上认为是公平的 。 在实时的情况下，如果一个class级在没有人需要的情况下借用带宽，那么当别人想要回来的时候会受到惩罚。 这意味着在实时保证的情况下，一个class级可以在很长的一段时间内没有带宽，因为在没有人需要的时候使用它。
链路共享是公平的，因为它不会惩罚使用备用带宽的类。 但是这意味着它不能提供强大的延迟保证。
链路共享与提供等待时间保证的分离是HFSC带来的新事物，论文在开头的一句话中提到： 在本文中，我们研究支持链路共享和有保证的分层资源pipe理模型和algorithm具有解耦延迟（优先级）和带宽分配的实时服务。 该句中的关键词是分离的。 翻译，这意味着你可以说是多less未使用的带宽与ls共享，并指定实时保证（又名等待时间保证）是rt所需要的。 两者是正交的。
实时带宽是否计入链路共享带宽？
是。 在HFSC的论文中，他们定义了带宽，就是由于class级积压（即有数据包在等待发送），class级发送了什么。 rt和ls之间唯一的区别是rt从每次课程积压后计算出最低保证带宽，而链接共享仅从上次课堂积压时开始看。 所以rt需要考虑更多的字节比ls，但是每个字节ls也考虑rt。
是否将上限曲线应用于实时，仅用于链接共享，或者可能同时应用于两者？
上限不会阻止发送数据包以满足实时条件。 在实时状态下发送的数据包仍然计入上限，从而可能在未来链路共享状态下延迟发送的数据包。 这是实时和链接份额之间的另一个区别。
假设A2和B2都是128 kbit / s，如果A1和B1只有128 kbit / s链路共享，或64 kbit / s实时和128 kbit / s链路共享，是否有区别？如果是，有什么区别？
是的，它确实有所作为。 如上所述，如果您使用实时，则可以保证等待时间，但链路不能公平地共享（特别是class级可能会遭遇带宽匮乏），并且不会强制执行上限。 如果使用链路共享，则不保证延迟，但链路共享是公平的，不存在饥饿的风险，并且强制执行上限。 实时总是在链接共享之前检查，但这并不意味着链接共享将被忽略。 这是因为数据包计数不同。 由于历史被实时考虑，可能不需要分组来满足实时保证（因为历史包括一个计数），但是由于忽略历史分组而需要满足链路共享。
如果我使用单独的实时曲线来增加类别的优先级，为什么我需要“曲线”呢？ 为什么不是实时的价值链接和平价？ 为什么都是曲线？ 在原始论文中对曲线的需求是清楚的，因为每个类只有一种属性。 但是现在，有三个属性（实时，链接共享和上限），我还需要每条曲线吗？ 为什么我会希望曲线形状（不是平均带宽，但它们的斜率）对于实时和链路共享stream量是不同的？
实时控制曲线允许您针对其他stream量类别（例如电子邮件）的延迟较差的特定stream量类别（例如VOIP）交易紧缩延迟。 HFSC在实时约束下决定发送哪个包时首先select要完成发送的包。 但是，它并不使用链路的带宽来计算，而是使用实时曲线分配的带宽。 因此，如果我们具有相同长度的VOIP和电子邮件数据包，并且VOIP数据包具有凸曲线，如果在电子邮件的凹曲线上提供10倍的提升，那么将在第一个电子邮件数据包之前发送10个VOIP数据包。 但是这只发生在突发时间，最多只需发送几个包即毫秒。 此后，VOIP曲线应该平坦化，VOIP将不会获得未来的增长，除非它退缩了一段时间（VOIP是一个低带宽的应用）。 所有这一切的最终结果是确保那些第一对VOIP数据包的发送速度比其他任何事情都要快，从而使VOIP的延迟时间缩短，同时以电子邮件获得高延迟为代价。
正如我前面所说，因为链接共享不看历史，所以不能提供延迟保证。 像VOIP这样的实时stream量需要坚实的保证。 然而，平均而言，链接共享凸曲线仍然会为其stream量提供延迟提升。 这只是不能保证。 对于大多数情况来说，这很好，比如通过电子邮件的networkingstream量
根据可用的文档，实时曲线值对于内部类（A类和B类）是完全忽略的，它们仅适用于叶类（A1，A2，B1，B2）。 如果这是真的，为什么ALTQ HFSC示例configuration（search3.3示例configuration）设置内部类的实时曲线，并声称那些设置这些内部类的保证率？ 这不完全没有意义吗？ （注意：pshare将链接共享曲线设置为ALTQ并筛选实时曲线;您可以在示例configuration上方的段落中看到这一点）。
该文件是正确的。 层次结构（从而内部节点）对实时计算没有任何影响。 我不能告诉你为什么ALTQ显然认为它确实如此。
有些教程说，所有实时曲线的总和可能不会高于线速度的80％，有些则说不能高于线速度的70％。 哪一个是对的，或者他们可能都是错的？
两者都是错误的。 如果70％或80％的stream量具有必须实时指定的严格等待时间要求，那么现实情况是，几乎可以肯定的是，您无法通过所使用的链接来满足这些要求。 你需要一个更快的链接。
有人可能认为指定80％的stream量应该是实时的唯一方法是，如果他们实时踩踏作为一个优先提升。 是的，为了提供延迟保证，你实际上提高了一些数据包的优先级。 但它应该只有毫秒。 这是一个链接可以应付，仍然提供延迟保证。
有很less的stream量需要延迟保证。 VOIP是一个，NTP的另一个。 其余的都应该通过链接共享完成。 它希望networking速度更快，通过分配大部分链接容量来快速实现。 这个份额是长期保证的。 它希望它是低延迟（平均），在链接共享下给它一个凸曲线。
一个教程说，你应该忘记所有的理论。 无论事情如何工作（调度程序和带宽分配），根据以下“简化思维模型”想象这三条曲线：实时是该类将始终获得的保证带宽。 link-share是这个class想要充分满足的带宽，但是满意度是无法保证的。 如果有过多的带宽，class级甚至可能获得更多的带宽而不是必要的满足，但它可能永远不会超过上限说。 为此，所有实时带宽的总和可能不高于线速度的xx％（参见上面的问题，百分比变化）。 问题：这或多或less是对HSFC的误解？
这是一个很好的描述上限。 虽然链接分享描述是严格准确的，但这是误导性的。 尽pipe链路共享并不能像实时那样给予硬性延迟保证，但它比其它竞争对手（如CBQ和HTB）更有效地分配带宽。 所以在说链接共享“不提供保证”的时候，它把它保持到任何其他调度程序可以提供的更高的标准。
实时的描述pipe理是准确的，但如此误导我会说错了。 顾名思义，实时的目的不在于保证带宽。 这是提供有保证的延迟 – 即数据包是立即发送，而不是一些随机时间后取决于如何使用链接。 大多数stream量不需要保证延迟。
也就是说，实时并不能提供完美的延迟保证。 如果链接不是由链接共享pipe理的话，它也可以，但是大多数用户希望获得更多的灵活性，而且它不是免费的。 实时可能会错过发送一个MTU数据包所需的时间。 （如果发生这种情况，那将是因为它是一个MTU分组链路共享，而实时保持链路空闲的情况下，给它一个很短的截止时间，必须立即发送的数据包，这是链路共享和实时性，为了保证实时性，即使有报文发送，实时性也可以故意保持线路闲置，链路利用率低于100％，链路共享总使用链路可用容量的100％，与实时性不同，可以说是“保工”。）
实时的原因可以说是提供了难以保证的延迟是延迟是有界的。 因此，如果您尝试在1Mbit / sec链路上提供20ms的延迟保证，并且链路共享正在发送MTU大小（1500字节）的数据包，则您知道其中一个数据包需要12ms才能发送。 因此，如果您实时告诉您需要8毫秒的延迟时间，您仍然可以达到20毫秒的最后期限 – 绝对保证。
如果上面的假设真的是准确的，那么模型中的优先级在哪里？ 例如，每个class级可能有一个实时带宽（保证），一个链路共享带宽（不保证），也可能是一个上限，但仍然有一些class级比其他class级有更高的优先级需求。 在这种情况下，我仍然必须优先考虑，即使在这些类别的实时stream量中。 我会优先考虑曲线的斜率吗？ 如果是这样，哪条曲线？ 实时曲线？ 链接分享曲线？ 上限曲线？ 他们全部？ 我会把所有的人都倾斜在一起还是不一样，如何找出正确的倾斜？
没有优先模式。 认真。 如果您想给交通绝对优先权，请使用pfifo。 这就是它的目的。 但是也要注意，如果您给予networkingstream量绝对优先于电子邮件stream量，这意味着让networkingstream量饱和链接，因此没有电子邮件数据包通过。 所有的电子邮件连接然后死亡。
实际上没有人想要这种优先顺序。 他们想要的是HFSC提供的。 如果你真的有实时的stream量，HFSC提供。 但这将是所有的东西。 其余部分，HFSC允许你说：“在一个拥挤的环节上，把90％分配给networking，让电子邮件以10％的速度stream淌，并且快速发送奇怪的DNS数据包，但是不要让别人来阻止我。
你可以用不同的名字定义曲线：
我该怎么做需要一个实时曲线？ 假设A1，A2，B1，B2都是128kbit / s的链路共享（任何一条都没有实时曲线），那么如果根分配512kbit / s，每个链路将得到128kbit / s A和B当然都是256kbit / s），对不对？ 为什么我还要给A1和B1 128 kbit / s的实时曲线？ 这有什么好处？ 为了给予这两个更高的优先？ 根据原始文件，我可以通过使用曲线给予他们更高的优先级，这就是HFSC的全部内容。 通过给这两个类别[256kbit / s 20ms，128kbit / s]的曲线，它们的优先级比A2和B2的优先级高两倍（平均只能达到128kbit / s）
当您在HFSC中仅以费率进行定义时，会自动将“dmax”设置为0.这基本上意味着它没有考虑延迟。 一个好的HFSCconfiguration应该包括你想要用于你的类的带宽和延迟边界，否则algorithm不能确切地说明一个类应该得到多less优先级。
无论何时您给数据包优先，其他数据包将不得不优先减less。 基于'dmax'和'rate'值，所有的类将使用虚拟定时器进行复用。 有关更多信息，请参阅tc-hfsc（7）。
实时带宽是否计入链路共享带宽？ 例如，如果A1和B1都只有64kbit / s的实时和64kbit / s的链路共享带宽，这是否意味着一旦它们通过实时服务64kbit / s，它们的链路共享要求也是可以满足的获得多余的带宽，但让我们忽略一秒钟），或者这意味着他们通过链路共享获得另外的64 kbit / s？ 那么每个class级是否有一个实时加链接共享的带宽“要求”？ 或者，如果链路共享曲线高于实时曲线（当前链路共享要求等于指定的链路共享要求减去已经提供给此的实时带宽），那么只有比实时曲线更高的要求类）？
如果stream程没有超出该类的链接份额定义的边界，则从不使用实时曲线。 在这种情况下定义一个实时曲线可以让您：例如保证一定的“dmax”。
如果您的链接共享定义完美无瑕，那么您就不需要实时曲线。 您可以定义服务曲线（sc），但这会使您的configuration工作更难。
是否将上限曲线应用于实时，仅用于链接共享，或者可能同时应用于两者？ 有些教程是用一种方式说的，有些用另一种方式说的。 有人甚至认为上限是实时带宽+链路共享带宽的最大值？ 什么是真相？
您的类的上限曲线仅应用于链接份额，当您定义上限曲线时，您必须定义链接份额曲线。 但是父类的上限曲线仍然适用。
假设A2和B2都是128 kbit / s，如果A1和B1只有128 kbit / s链路共享，或64 kbit / s实时和128 kbit / s链路共享，是否有区别？如果是，有什么区别？
如果例如A2 = 0千比特/秒和B2 = 256千比特/秒，则存在细微差别。 那么A2的虚拟时间将是他的最大值。 每当数据包在A2中被分类，它们将被立即处理。 然而B2的实时曲线仍然能确保至less能够传输64 kbit / s
如果我使用单独的实时曲线来增加类别的优先级，为什么我需要“曲线”呢？ 为什么不是实时的价值链接和平价？ 为什么都是曲线？ 在原始论文中对曲线的需求是清楚的，因为每个类只有一种属性。 但是现在，有三个属性（实时，链接共享和上限），我还需要每条曲线吗？ 为什么我会希望曲线形状（不是平均带宽，但它们的斜率）对于实时和链路共享stream量是不同的？
实时曲线不会在相邻叶子之间共享stream量，链路共享曲线也是如此。
根据可用的文档，实时曲线值对于内部类（A类和B类）是完全忽略的，它们仅适用于叶类（A1，A2，B1，B2）。 如果这是真的，为什么ALTQ HFSC示例configuration（search3.3示例configuration）设置内部类的实时曲线，并声称那些设置这些内部类的保证率？ 这不完全没有意义吗？ （注意：pshare将链接共享曲线设置为ALTQ并筛选实时曲线;您可以在示例configuration上方的段落中看到这一点）。
对于内部类来说，实时曲线是被忽略的，它们只适用于叶类。 然而，在这些叶类上计算的内部类别上定义的实时曲线被考虑在内。
有些教程说，所有实时曲线的总和可能不会高于线速度的80％，有些则说不能高于线速度的70％。 哪一个是对的，或者他们可能都是错的？
他们的意思是：你不能优先考虑所有的stream量…每当你给数据包优先，其他数据包将不得不优先减less。 如果你过度担保，algorithm变得毫无意义。 定义获得优先级的类并定义可能遭受的类。
一个教程说，你应该忘记所有的理论。 无论事情如何工作（调度程序和带宽分配），根据以下“简化思维模型”想象这三条曲线：实时是该类将始终获得的保证带宽。 link-share是这个class想要充分满足的带宽，但是满意度是无法保证的。 如果有过多的带宽，class级甚至可能获得更多的带宽而不是必要的满足，但它可能永远不会超过上限说。 为此，所有实时带宽的总和可能不高于线速度的xx％（参见上面的问题，百分比变化）。 问题：这或多或less是对HSFC的误解？
这是对的。
如果上面的假设真的是准确的，那么模型中的优先级在哪里？ 例如，每个class级可能有一个实时带宽（保证），一个链路共享带宽（不保证），也可能是一个上限，但仍然有一些class级比其他class级有更高的优先级需求。 在这种情况下，我仍然必须优先考虑，即使在这些类别的实时stream量中。 我会优先考虑曲线的斜率吗？ 如果是这样，哪条曲线？ 实时曲线？ 链接分享曲线？ 上限曲线？ 他们全部？ 我会把所有的人都倾斜在一起还是不一样，如何找出正确的倾斜？
HFSC和HTB之间的区别在于，HFSC将允许您准确定义您希望具有多less优先级。 您可以通过使用“dmax”值定义最小和最大边界来做到这一点。
最后，这个指南似乎解释了大部分的不一致之处，以及目前的实施情况与原始文件的不同之处：
http://manpages.ubuntu.com/manpages/precise/man7/tc-hfsc.7.html
根据这个指南，许多关于HFSC的指南和论坛post完全是无稽之谈。 这只是说明HFSC是多么的复杂，因为很多似乎是专家的人都假装完全了解HFSC，实际上只是基于对这个概念的误解和所有这些环境如何共同发挥作用而产生的部分知识和虚假陈述。
我想我最终会放弃HFSC。 如果你的HFSC设置正确的话，这可能是你能得到的最好的QoS，但你完全搞砸的机会远远高于你成功的机会。
如果你不能抓住原作者，那么我会尝试下一步：
也请尝试检查引用这一个的其他较新的论文。 那里可能有更新的论文是这个领域的研究的延续，可能包括更多关于你所问的问题的信息。