Chinaunix首页 | 论坛 | 博客
  • 博客访问: 714017
  • 博文数量: 79
  • 博客积分: 10
  • 博客等级: 民兵
  • 技术积分: 1338
  • 用 户 组: 普通用户
  • 注册时间: 2012-06-12 08:51
个人简介

XMU->九天揽月->五湖抓鳖->DSP->driver->kernel/OpenWRT->ISP/RTOS

文章分类

全部博文(79)

文章存档

2020年(2)

2018年(3)

2016年(7)

2015年(42)

2014年(25)

分类: 网络与安全

2015-04-24 09:50:42

原文链接 http://blog.csdn.net/shichaog/article/details/40897681

bufferbloat

bufferbloat产生

当一个分组交换网络中,过多的缓冲数据包导致了数据包的延迟、延迟抖动和降低了网络的总的吞吐量的现象。对一个速度很快的网络而言,如果配置了一个过大的缓冲区,也可能导致即时通讯服务类的应用的用户体验很差。果将TCP的数据包想象成水,队列管理是细细长长的管子,如果水有一瓶矿泉水那么多,使用矿泉水瓶口大小粗的水管放水,要不了多久水就会放完,如果水有青海湖那么多,也使用上述的管子,那么最后一滴水什么时候能放完呢?显然很长,对应到数据包,这个数据就是送到数据需求方太晚了。这就是bufferbloat。

当一个网络拥塞时,在Linux上就可能产生bufferbloat现象,其会导致排队等待处理的数据包的时间变长,长到对即时通讯类服务基本不可用的程度。在一个先进先出队列管理方式的网络中,过大的buffer以及过长的等待队列,在某些情况下不仅不能提高系统的吞吐量甚至可能导致系统的吞吐量近乎于零。

bufferbloat现象不仅存在于路由器、交换机中,Linux操作系统对接收和发送队列的处理也同样会导致该现象的出现。这里仅讨论Linux中的bufferbloat现象。windows xp将TCP连接限制在64KB,win7则提供了能够干掉所有连接的速率限制。Linux在3.5的版本中增加了bufferbloat管理的相关代码。

对于网络性能带宽的提升努力--操作系统

1)多队列管理方式,将上面的FIFO变成多个,它们的优先级设置成不同的,这样可以将发送和接收的数据按重要性送进对应的队列,这样可以保证优先级高的数据包后道依然能得到更快的处理。

2)NAPI方式,这是Linux内核提供的一个新的数据包处理方式,已经大行其道了,主要思想就是接收若干个数据包或者发送若干个数据包后在产生中断,在中断服务程序中进行缓冲区的释放,这极大的减小了中断的开销,理论上可以提高网络性能,之所以使用理论上,是因为笔先前在一个网络视屏嵌入式设备中测试过NAPI方式和非NAPI方式,笔者当时认为在传输视屏数据时发生和接收都使用NAPI方式,网络性能会好,但是使用netperf工具测试时,发现仅发送使用NAPI方式的网络带宽最高,当然这个测试结果和应用场景是息息相关的。关于netperf测试方法,见我的另一篇博文http://blog.csdn.net/shichaog/article/details/38895039

3)命名空间方法,在内核中,如果启用命名空间,那么一个CPU会对应一个自己的网络收发管理队列,这样就避免了单网络队列同步带来的消耗。当然将CPU号和网络管理队列号的对应也是需要开销的。

4)SMP,在SMP下花样就多了,GRO、GSO、TSO、RSS、UFO、RPS、RSS、RFS等,这些方法主要是利用cpu缓存原理、应用所在的CPU号以及中断绑定技术。如果接收两路视频数据,这两段视频码流较大被分成了多个数据包,这样将分成多个包被送到Linux主机。假设数据包为A0、A1、A2...和B0、B1、B2;CPU为8核,我们定义为CPU0、CPU1、CPU2...

如下一种情况到达,A0、A1、...被送到CPU1,B0、B1、...被送到CPU2,这种情况非常好,因为视频被重组存储时,CPU1、和CPU2处理就好了,为什么好呢?
假设A0、A1被送到CPU1,;A2、A3、B3被送到CPU6;A4、A5、B0、B1、A6被送到CPU2,麻烦事来了,CPU1想获得完整的A码流就需要存取其它CPU的缓存,这就需要开销,并且其它CPU需要将cache里的A码流刷出,它们不需要,B码流的过程也是这样的麻烦。所以呢得想个办法,就是按上面的将A码流送到一个核,B码流送到另一个核,RPS就可以完成这个功能。

还有更好的,想象一下,如果现在在预览我的码流视频,那么这时涉及到解析码流视频的应用了,假设应用运行在CPU1上,那么很庆幸,上面的RSP功能就够了,如果应用运行在CPU2上,视频数据在送到CPU2的cache中,这显然开销又大了,不仅如此,可能还会带来cache的抖动性问题。由此,Linux内核中RFS应运而生了。

5)回到上述bufferbloat问题,Kathie Nichols and Van Jacobson提出了一个叫controlled delay的算法又叫CoDel algorithm,当队列中的排队的数据包过多时开始丢弃数据包,但是丢弃的数据包是从队列的前面开始有选择的丢弃,而不是先处理直到不能处理了再把后面的丢弃。该思想是先查看每一个处理的数据包的等待时间,缺省5毫秒,如果等待超过5ms,那么说明队列可能拥堵了,这是会丢弃该数据包,继续查看下一个数据包的等待时间。由于拥塞的数据包被尽快的丢弃了,带来的好处之一是内核中的TCP拥塞控制部分的负荷减轻。
阅读(3289) | 评论(0) | 转发(1) |
给主人留下些什么吧!~~