zoukankan      html  css  js  c++  java
  • ROS取数线程分析(4): count计数器溢出bug

    在不带组装,取数线程简化为直接while循环recv,通过setsockopt将SO_SNDBUF, SO_RCVBUF设置为256*1024时,短时间内的测试结果为6.7Gb/s。但是长时间的测试结果却如下图:

    上图的横坐标为ROS接收到event的个数,以40000为单位。 

    (x, y)表示 ROS接收到第 x*40000 个 event 时,接收端的带宽为 y Gbits/s. event size 为 2KB.

    由上图可以看出,接收端的带宽在保持了一段时间的6Gb/s后,是不断降低的。但是发送端的带宽一直都是保持在6.4Gb/s以上。

    send speed : 6.45782Gb/s
    send speed : 6.45631Gb/s
    send speed : 6.43146Gb/s
    send speed : 6.44313Gb/s
    send speed : 6.37502Gb/s
    send speed : 6.44647Gb/s
    send speed : 6.45929Gb/s
    send speed : 6.37766Gb/s
    send speed : 6.39508Gb/s
    send speed : 6.44929Gb/s
    send speed : 6.45014Gb/s
    send speed : 6.44203Gb/s
    send speed : 6.44749Gb/sq
    send speed : 6.42823Gb/s
    send speed : 6.43295Gb/s
    send speed : 6.44113Gb/s
    send speed : 6.44306Gb/s
    send speed : 6.41997Gb/s
    send speed : 6.44833Gb/s
    send speed : 6.42745Gb/s
    send speed : 6.44259Gb/s
    ...

    这个SO_SNDBUF,SO_RCVBUF的设置是有问题的吧? 是只设置接收端的SO_SNDBUF与SO_RCVBUF,不设置发送端的原因导致的吗?还是这个设置值的大小有问题?这个值应该设为延时带宽乘积?

    在发送端和接收端不设置SO_SNDBUF, SO_RCVBUF这两个选项时,测试的结果为:

    发送端:

    接收端:

    今天查看了一下接收端程序,发现是因为计数用的count溢出了,导致出现上面的阶梯状带宽曲线。

  • 相关阅读:
    CF G. Running Competition (NTT, 思维)
    ABC 177 F
    牛客练习赛68 D.牛牛的粉丝 (期望DP,矩阵快速幂)
    CF E
    HDU 6761 Minimum Index (字符串--Lyndon分解)
    D. GameGame (思维、博弈)
    P2533 最小圆覆盖
    P4049 [JSOI2007]合金
    P2510 [HAOI2008]下落的圆盘
    P3205 [HNOI2010]合唱队
  • 原文地址:https://www.cnblogs.com/zengtx/p/6576378.html
Copyright © 2011-2022 走看看