我想添加一些交通pipe理到我们的互联网线路。 在阅读了大量的文档之后，我认为HFSC对我来说太复杂了（我不明白所有的曲线，恐怕我永远也搞不清楚），CBQ是不推荐的，基本上HTB是去为大多数人。
我们的内部networking有三个“细分市场”，我想在这些（至less在一开始）之间或多或less地分享带宽。 此外，我必须根据至less三种stream量（实时stream量，标准stream量和批量stream量）优先处理stream量。 带宽共享并不重要，因为实时stream量应该尽可能地被视为高级stream量，但是当然其他stream量级别也不会饿死。
问题是，什么更有意义，并保证更好的实时吞吐量：
每个分段创build一个类，每个类具有相同的速率（根据HTB开发人员的优先级无关紧要），每个类都有三个子类（叶子）用于3个优先级（具有不同的优先级和不同的费率）。
每个优先级上有一个类，每个具有不同的速率（同样优先级不重要），每个有3个子类，每个段有一个，而实时类中的所有3个具有最高的prio，最低的prio类，等等。
我将尝试使用下面的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 C | +--> Normal Prio | +--> Segment A | +--> Segment B | +--> Segment C | +--> Low Prio +--> Segment A +--> Segment B +--> Segment C 案例1似乎大多数人会这样做，但除非我没有正确阅读HTB实施细节，否则案例2可能会提供更好的优先级。
HTB手册说，如果一个class级达到了预定的速度，它可能会从其父母借款，而借款时，优先级较高的class级将首先获得带宽。 然而，它也表示， 无论优先级如何，在较低树级别上具有可用带宽的类别总是优先于在较高树级别上的类别。
我们假设以下情况：C段不发送任何stream量。 A段只发送实时stream量，尽可能快（足以使链路饱和），B段只发送大量stream量，尽可能快（再次，足以饱和链路本身）。 会发生什么？
情况1：
段A->高优先级和段B->低优先级都有数据包要发送，因为A->高优先级具有较高的优先级，它将始终被调度，直到它达到其速率。 现在它尝试从A段借款，但由于A段处于较高水平，而B-> Low Prio尚未达到它的汇率，所以现在该类现在首先被服务，直到它也达到了汇率并且想要从B部分。一旦两者都达到了他们的利率，两者都是在同一水平上，现在部分A – >高Prio将再次赢，直到它达到部分A的比率。现在它试图从根（它已因为C段没有使用任何保证stream量），但是同样需要等待段B->低优先级才能达到根级。 一旦发生这种情况，再次考虑优先级，这一次，A段>高优先级将获得段C剩余的所有带宽。
案例2：
高优先 – >段A和低优先 – >段B都有数据包要发送，高优先 – >段A将赢得，因为它具有较高的优先级。 一旦达到它的价格，它就会试图从有高带宽的High Prio中借用，但是在更高的水平上，它必须再次等待低优先 – > B段才能达到它的价格。 一旦两者都达到了他们的利率，都需要借款，高级 – >段A将再次赢得，直到它达到高级别的比率。 一旦发生这种情况，它会尝试从根目录中借出，而剩下的带宽仍然很多（此时正常的Prio的所有带宽都没有被使用），但是它必须等待，直到低优先 – >分段B达到低Prio类，也试图从根借。 最后，两个类都尝试从根借用，优先级考虑在内，高优先 – >段A获得所有剩余的带宽根。
这两种情况似乎都不是最理想的，因为实时stream量有时需要等待大量stream量，即使有足够的带宽可以借用。 然而，在情况2中，似乎实时业务量必须等于小于情况1，因为它只需要等到总体业务速率被触发，这很可能小于整个分段的速率（并且在情况1这是它必须等待的速度）。 还是我完全错了？
我想到了更简单的设置，使用优先级qdisc。 但优先级队列如果不是某种程度的限制，就会造成饥饿的大问题。 饥饿是不可接受的。 当然，可以在每个优先级中放入一个TBF（令牌桶filter）来限制速率，从而避免饥饿，但是当这样做时，单个优先级不能再自己饱和链路，即使所有其他优先级是空的，TBF将防止发生。 而且这也不是最佳的，因为如果目前还没有其他的课程需要它的话，为什么class级不能获得100％的带宽呢？
有关此设置的任何意见或想法？ 使用标准的tc qdisc似乎很难。 作为一名程序员，如果我可以简单地编写我自己的调度程序（这是我不允许的），那么这是一件容易的事情。
如果我正确理解htb，那么速率是“保证”的。 这意味着您对“实时”stream量的速度有所了解。 只有超过这个比率，它才会借。 如果有几个class想借，prio应该踢。保证费率应该加起来的物理限制。 否则，这太麻烦了。
恕我直言，案例A将永远不会真的工作，因为你需要在根级别的优先级或速率限制。 不同细分市场的优先级/比率并不相互了解，将会平等对待。
你可能想要的是：把低和普通prio的“比率”设置为0或接近它，并为其余的带宽添加“上限”，对于高比例，你保证100％的比率。