ROS取数线程分析（4）: 不带组装: socket选项SO_SNDBUF，SO_RCVBUF对带宽和CPU的影响
昨天用ROS， iperf, nettest测试了cmm02node06——>cmm02node01的带宽和cpu占用率，发送的包长为2KB，测试的结果为：
带宽 发送端CPU占用率 接收端CPU占用率
ROS 4.42Gb/s, 80% 100%
iperf 4.66Gb/s， 100% 70%
nettest 4.38Gb/s， 100% 71%
发现iperf和nettest都是发送端cpu达到100%， 而接受端只占到70%；ROS是接收端cpu达到了100%，发送端cpu占80%。为什么ROS的cpu占用率与其他两个软件不同呢？
为什么ROS接收端的CPU占用率为100%呢？先排除ROS的查询，判断，buffer等的影响，将ROS的取数线程简化为一个直接recv的线程：
1. SequentialInputHandler_directrecv.cpp文件，将requriment里的SequentialInputHandler替换成SequentialInputHandler_directrecv，主要是将readyToReadout和ReleaseFragment注释掉了. 见：
https://files.cnblogs.com/files/zengtx/ROS_SequentialInputHandler_directrecv.pdf
2. SequentialDataChannel.cpp里的inputFragment函数注释掉，换成简单的：
/*****************************************************/
unsigned int SequentialDataChannel::inputFragment(void)
/*****************************************************/
{
// if(!buffer) buffer = new char[m_robPageSize*100000*401] ;
char buffer[2048*20];
this->getNextFragment((unsigned int*)buffer, (unsigned long)m_robPageSize);
return 0 ;
}
这样ROS接收端的取数模型简化为阻塞recv的while循环。
此时的测试结果为：（msg_size = 2048）带宽为6.7Gb/s，接收端的cpu占用率仍为100%，发送端cpu占用率为83%。
带宽 发送端CPU占用率 接收端CPU占用率
ROS 4.42Gb/s, 80% 100%
ROS_directrecv 6.7Gb/s 83% 100%
iperf 4.66Gb/s， 100% 70%
nettest 4.38Gb/s， 100% 71%
接收端线程简化后，用来recv的时间比例增加，使得发送端的cpu占用率提高了一些。但是接收端cpu为什么比发送端cpu先达到100%呢？为什么ROS_directrecv的带宽比iperf，nettest的带宽更高呢？
通过比较了nettest和ROS的代码后发现，ROS的代码中多了两个socket选项设置：SO_SNDBUF,SO_RCVBUF，这两个值都被设置为256*1024。将这两个设置选项注释掉，再进行一次测试。
带宽 发送端CPU占用率 接收端CPU占用率
ROS 4.42Gb/s, 80% 100%
ROS_directrecv 6.7Gb/s 83% 100%
ROS_directrecv_nosetsockopt 4.64Gb/s 100% 70%
iperf 4.66Gb/s， 100% 70%
nettest 4.38Gb/s， 100% 71%
发现注释掉SO_SNDBUF,SO_RCVBUF选项设置后，测得的带宽变小了，发送端的CPU占用率为100%，接收端的CPU为70%，与iperf，nettest的测试结果接近。
查阅：http://bbs.csdn.net/topics/310236933
“SO_SNDBUF和SO_RCVBUF设置系统缓冲区的大小，在接受和发送数据时直接影响系统遍历缓冲区的行为，比如你实际发送的数据比较少，接收缓冲区却很大，系统做无效遍历的内容会增多，肯定会影响效率的。”
SO_SNDBUF, SO_RCVBUF在传输包长小，cpu为瓶颈时，这两个选项值会影响系统性能，具体值设为多少最优，需要做具体的测试确定。
