如果我不知道信道宽度，有什么办法可以在不同的stream量类别之间划分出去的信道，例如30/70的关系？ HTB需要确切的数字，而CBQ也是如此。
我认为这样做是可以做到的，但是除非有一些控制stream出的机制，否则队列排空得太快，从来没有显示出权重（不完全确定这是为什么）。 然而，只要有select压力，它就会按照预期的那样工作。
tc qdisc add dev eth0 handle 1 root drr tc class add dev eth0 parent 1: classid 1:1 drr quantum 600 # 30% tc class add dev eth0 parent 1: classid 1:2 drr quantum 1400 # 70% tc class add dev eth0 parent 1: classid 1:3 drr # everything else.... tc qdisc add dev eth0 parent 1:1 handle 10: sfq perturb 120 limit 1024 tc qdisc add dev eth0 parent 1:2 handle 20: sfq perturb 120 limit 1024 tc qdisc add dev eth0 parent 1:3 handle 30: sfq perturb 120 limit 1024 # outgoing to port 8111 will go to 30% queue, 8112 will go to 70% queue... tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 8111 0xffff classid 1:1 tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 8112 0xffff classid 1:2 # a default so my connection doesn't die when doing this. tc filter add dev eth0 protocol all parent 1:0 prio 2 u32 match u8 0x00 0x00 at 0 classid 1:3 如果你把它全部包装在一个800kbpsstream量的HTB中，你会得到一个很好的70KB / 30KB的分割，通过运行pv -ar /dev/zero | nc differenthost port并行实例来testingpv -ar /dev/zero | nc differenthost port pv -ar /dev/zero | nc differenthost port 。
顺便说一下，不要试图在没有带外控制机制的情况下以线速从远程机器进行testing。 （糟糕）
也许这个答案将有助于反正。
编辑 ：search互联网，事实certificate，没有其他的Linux赤字循环（DRR）qdisc的例子，除了手册页，包括一个，这似乎是不完整的，省略了过滤规则（及其注意事项） -明显。
赤字循环是一种调度algorithm，可以想象为一些并行队列。 调度程序按顺序迭代这些队列。 每次队列出现时，如果队列不是空的，它将检查队列中下一个数据包的数据包大小，并将其与每个队列称为缺陷计数器的数据进行比较 。 如果数据包大小小于赤字计数器，则DRR将数据包从队列中删除，并将其发送到networking上并从赤字计数器中减去其大小（因此赤字）。 然后重复队列中的下一个数据包，直到数据包大于缺陷计数器或队列为空。 如果循环结束时队列不是空的，那么在进入下一个队列之前，特定于队列的值将被添加到赤字计数器中。
这实际上与HTB并不完全不同，除了HTB限制了在任何特定时间间隔内添加到给定队列的最大数量（很确定，linux是以每字节为单位来测量的，虽然这可能不是真实的， ）并且还具有用于所有合并的队列的不足计数器（每个时间间隔也填充一定数量的字节）
那么上面的例子是创builddrr qdisc作为root用户，并为其添加3个队列，每个队列包含600个字节的数据，每个包含1400个字节，第三个队列默认为MTU大小。 出于某种原因，我会稍微解释一下，这些值是多less并不重要，只是比例是多less。
因为我喜欢公平，所以我在叶子上加了一些叶子; 这是没有必要的，因为如果你不这样做，它应该默认为pfifo快（或者不pipe你的默认调度器是什么，我想，我必须阅读sch_drr.c源码才能100％确定）。 它也不会改变我的testing，因为我使用每个端口的单个TCP连接。
当我testing上述时，实际上给了我一些过滤规则的麻烦。 drr并没有像其他许多qdisc所具有的默认stream程，也不允许您将其指定为qdisc选项（我知道，如果是，请编辑此答案）。 所以当开始丢弃你的数据包的时候，这是一个令人沮丧的方式，因为它不能排队等诸如arp请求或者回复之类的东西，而且也没有说出你的接口为什么会自发地下降。
因此，前两条规则执行testing活动，匹配8111和8112的tcp / udp（它在同一地点）dport，将匹配放在适当的队列中，如果find适当的规则则停止匹配。
第三条规则是“匹配第一个字节（0偏移量）匹配0x0和掩码0”的任何协议，并把它放在第三个队列中。 这是第一次通过球员评估后，然后捕获任何不匹配的数据包。 如果你知道一个更好的方式来创build一个默认的classid，我一定会想知道。
正如我前面提到的那样，实际值与比率无关，尽pipe它可能会使队列更加突然（我的意思是，如果每个队列比队列中的每个队列更大，就应该在队列中保持一个队列）如果它们比较小，那么可以使用更多的CPU时间。 出于这个原因，我select了接近与30/70目标比例相关的MTU数量级的值。 由于量子决定了每次通过的填充率，并因此决定了每次通过的字节数，所以量子比将是每通道相对于彼此的字节的比率。 如果一个队列是空的，其他队列没有太多的带宽，只是花费更多的时间跳过空队列并填充自己。
与HTB或CBQ相比，相对缺乏文档表明DRR并不是一个特别受欢迎的qdisc，所以不幸的是，如果你决定走这条路线，我期望的支持将是非常稀疏的，这使得很难推荐使用。
你检查了这个链接吗？
http://www.tldp.org/HOWTO/html_single/Traffic-Control-HOWTO/#r-unknown-bandwidth
> 8.2. Handling a link with a known bandwidth > > HTB is an ideal qdisc to use on a link with a known bandwidth, because the innermost (root-most) class can be set to the maximum > bandwidth available on a given link. Flows can be further subdivided > into children classes, allowing either guaranteed bandwidth to > particular classes of traffic or allowing preference to specific kinds > of traffic