Qos队列调度算法(SP/WRR/DWRR)

最新推荐文章于 2025-03-11 00:06:32 发布

竹林

最新推荐文章于 2025-03-11 00:06:32 发布

阅读量2.3w

点赞数 22

分类专栏：路由交换文章标签： Qos 队列调度算法

本文链接：https://blog.csdn.net/lsl_zhulin/article/details/115643382

版权

路由交换专栏收录该内容

1 篇文章

订阅专栏

本文详细介绍了Sonic中支持的三种QoS队列调度算法：SP（Strict Priority）、WRR（Weighted Round Robin）和DWRR（Deficit Weighted Round Robin）。SP按照优先级严格调度，可能导致低优先级队列长时间无法调度；WRR基于报文数加权，能避免低优先级队列长时间等待；而DWRR基于报文字节数加权，更精确地分配带宽。每种算法各有优缺点，适用场景不同。例如，DWRR能更好地处理报文长度变化的情况，但低延迟业务可能受影响。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

本文重点分析sonic中支持的三种Qos队列调度算法：

1、SP（Strict Priority，严格优先级）

也称为PQ（Priority Queuing）调度，就是严格按照队列优先级的高低顺序进行调度。只有高优先级队列中的报文全部调度完毕后，低优先级队列才有调度机会。

2、WRR（Weighted Round Robin，加权轮循）

基于报文数的加权，每个队列拥有的调度次数和该队列的权重成比例。

实现方法是：为每个队列设置一个报文计数器 Count，根据权重进行初始化；每次轮询到一个队列时，输出一个报文且队列的计数器减一，直到计数器减为0时停止该队列的调度；当所有队列的计数器都为0时，根据权重重新初始化，开始新一轮调度。

3、DWRR（Deficit Weighted Round Robin，差分加权轮循）

基于报文字节数的加权，每个队列拥有的调度带宽和该队列的权重成比例。

实现方法是：为每个队列设置一个计数器Deficit，Deficit 初始化为Weight * MTU；每次轮询到一个队列时，输出一个报文且队列的计数器减去报文长度，直到计数器减为0时停止该队列的调度；当所有队列的计数器都为0时，根据Weight*MTU重新初始化每个队列计数器，开始新一轮调度。

如下图举例，假设某端口MTU=150Bytes，有2个队列Q1和Q2采用DWRR调度，Q1队列中有多个200Bytes的长报文，Q2队列中有多个100Bytes的端报文，Q1和Q2配置权重比为2:1。

经过第1~3轮DWRR调度，Q1队列被调出了3个200Bytes的报文，Q2 队列被调出了3个100Bytes 的报文；从长期的统计看，Q1和Q2的实际输出带宽比是2:1，与权重比相符；

综上，优缺点对比分析：

调度算法	优点	缺点
SP	1、将需要低延迟的关键业务放入高优先级队列，将非关键业务放入低优先级队列，从而确保关键业务被优先发送。	1、报文拥塞发生时，如果较高优先级队列中长时间有分组存在，那么低优先级队列中的报文将无法得到调度；
WRR	1、各队列中报文被调度次数与该队列的权值成正比。避免采用SP调度时低优先级队列中的报文可能长时间得不到调度的缺点； 2、WRR对于空的队列直接跳过，循环调度的周期变短，因此当某个队列流量小的时候，剩余带宽能够被其他队列按照比例占用。	1、WRR是按照报文个数进行调度，因此同等调度机会下大尺寸报文获得的实际带宽要大于小尺寸报文获得的带宽。当每个队列的平均报文长度相等或已知时，通过配置WRR权重，用户能够获得想要的带宽；但是当队列的平均报文长度变化时，用户就不能通过配置WRR权重获取想要的带宽。 2、相比SP调度，低延迟的关键业务（如语音）得不到及时调度。
DWRR	1、避免采用SP调度时低优先级队列中的报文可能长时间得不到调度的缺点。 2、避免采用WRR调度时各队列报文长度不等或变化较大时，不能按权重分配带宽资源的缺点。	1、相比SP调度，低延迟的关键业务（如语音）得不到及时调度。