本DEMO的另一项测试功能是针对QOS来的，通过分析收发包延时结果，我们可以进一步了解丢包对系统延时的影响。在发送的媒体包时，我们在其负载中加入了系统当前时间，通过记录回环后的媒体包的接收时间（以应用层接收为准，即经过了QOS、FEC解码处理后）来计算该媒体包的来回总时长。

首先，我们选择不丢包，其他参数配置情况：冗余度20%(Group中10个媒体包配2个冗余包)，两个媒体包之间的发送间隔为60ms，得到的媒体包“收发延时”情况如下图1所示。

图1 不丢包时，媒体包收发延时情况

因为媒体包为本地回环且无丢包发生，QOS、FEC均未做任何处理，延时非常低。可见与缓存一段时间数据再排序的QOS算法相比，本方案的QOS算法在没有丢包时将不会引入任何延时。

当我们选择每10个包丢弃一个时，时延情况如下图2所示：

图2 每10个包丢弃1个时，媒体包收发时延情况

下面我们来解释这一现象。每10个包丢弃1包时的情况如下图3所示：

图3  每10个包丢弃1个的情况示意

在QOS阶段，0号媒体包丢失，接下来收到的1号媒体包不能直接输出给后续FEC环节，需要等待最多200ms（QOS丢包延时设置为200ms），若仍然未收到0号媒体包则直接输出1号媒体包以及收到的后续媒体包。同样，当收到1号冗余包时也需要等待200ms方能输出。

在FEC阶段，当收到1~9号媒体包时因发现存在丢包而不直接输出给上层应用，直到收到1号冗余包时具备了FEC恢复的条件（收到媒体包数+收到冗余包数>=GROUP媒体包数），恢复0号媒体包并输出0~9号媒体包给上层应用。这样计算来0号媒体包被恢复输出总计需要800ms以上（60ms收到1号媒体包+8*60ms收到2~9号媒体包+2*60ms收到1号冗余包+1号冗余包在QOS环节等待200ms）。

当18号媒体包的丢失，19号媒体包会在QOS环节等待200ms，此时间段内会陆续收到冗余包0和冗余包1，200ms后仍然未等到18号媒体包的到来则直接输出到FEC恢复环节实现恢复。这样计算来18号媒体包被恢复输出总计需要约200ms。

由上例可见，当GROUP比较大时，若丢包发生在GROUP的前部，QOS环节的处理将影响后续包的时延指标。同时，前部丢失的媒体包不得不等待较长时间，直至尾部的冗余包到来方能恢复，造成延时进一步增大。下面我们比较GROUP SIZE为5时的情况。

图4  GroupSize为5时，每10个包丢1个的情况

可见采用较小的FEC GROUP可以改善丢包延时情况。