有人真的了解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 以下是一些我无法回答的问题，因为这些教程相互矛盾： 我到底需要什么实时曲线？假设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） 实时带宽是否计入链路共享带宽？例如，如果A1和B1都仅具有64kbit / s的实时和64kbit / s的链路共享带宽，那是否意味着一旦通过实时为64kbit / s提供服务，它们的链路共享要求也将得到满足（它们可能会获得多余的带宽，但请忽略一秒钟），或者这意味着它们通过链路共享又获得了64 kbit / s？那么，每个类别是否都具有实时和链接共享的带宽“需求”？或者，如果某个类别的要求比实时曲线更高，那么它的链接份额曲线要比实时曲线高（当前的链接份额要求等于指定的链接份额要求减去已为此提供的实时带宽）类）？ 上限曲线是否也适用于实时，仅适用于链接共享或两者都适用？有些教程说一种方式，有些说另一种方式。甚至有人声称上限是实时带宽+链路共享带宽的最大值？真相是什么？ 假设A2和B2均为128 kbit / …