【原创】FEC/QOS 数据测试型DEMO——–QOS功能验证

本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可以改善丢包延时情况。

发表评论

电子邮件地址不会被公开。 必填项已用*标注