ROS取数线程分析（3）: 不带组装: readToReadout PollEth分析

https://files.cnblogs.com/files/zengtx/readyToReadout_PollEth.pdf

上图为readyToReadout函数和PollEth()函数的程序流程图。

在单ROS单DataChannel的情况下，buffer一直足够，查看m_statistics->noSpace值，该值一直为0。该值为0是符合逻辑的，因为一个dataChannel ， 每收到一个事例，就释放掉该事例占用的buffer。

下面将m_statistics->noSpace挪到m_fragmentsScheduled > 0为False的子句里，用来统计因为PollEth()返回0而导致readyToReadout返回0，无法执行inputFragment读出操作的次数；

另外，由readyToReadout流程图可知，m_statistics->pollRODs 是用来统计满足读数条件（buffer够，PollEth()返回1）的次数，也就是inputFragment的次数。

m_statistics->pollRODs /(m_statistics->noSpace+m_statistics->pollRODs)即为 poll查询出来可读的次数占poll总次数的比例。

 Server "DF" contains 1 object(s):
    DF.ROS.ROS-Eth-00.DataChannel0 <14/3/17 05:48:45.888469> <EthClientSequentialDataChannelInfo>      13 attribute(s):
      fragmentsServed       0
      fragmentsMissed       0
      fragmentsLost         0
      freePages             499
      lastL1IdInput         4294967295
      wrongMarker           0
      wrongSize             0
      multipleFragments     0
      pollRODs              25680001
      pollIRFlags           0
      noSpace               81481268
      fragments_input       0

通过查看is信息：可知单ROS，单dataChannel时，pollRODs/(pollRODs+noSpace)=24%,  就是说select 100次，只有24次会inputFragment, 剩下的76次都将导致readyToReadout返回False, 在单个通道的情况下，取数线程将进入yield，让出CPU的状态。

select 返回0表示检查出通道没有数可读，证明发送端发送数据慢。

检查发送端的程序发现，在每次发送完2048字节后，usleep(sleep),  而sleep从脚本读出为0，usleep(0),

后来发现【1】：

一般使用usleep(0)的主要目的应该是， CPU交出当前线程的执行权，让CPU去执行其他线程。也就是放弃当前线程的时间片，转而执行其他线程。

参考：【1】http://sunzixun.iteye.com/blog/1521113

将usleep(0)注释掉后，各个软件测试结果的比较如下：单线程，包长2KB, ROS单DataChannel

　　　　　　　　带宽　　　　　　　发送端CPU占用率　　　　　　接收端CPU占用率

ROS  　　　　4.42Gb/s,    　　　　　　80%　　　　　　　　　　　　100%

iperf 　　 　　4.66Gb/s，  　　　　　　100%　　　　　　　　　　　　70%

nettest 　　　4.38Gb/s， 　　　　　　 98%　　　　　  　　　　　　　86.4%

 

三个软件的测试结果相差不大，ROS的接收端CPU达到100%。iperf和nettest都是发送端CPU达到100%。