Ros Fetch number Threading analysis (4): Without assembly: socket option So_sndbuf,so_rcvbuf effect on bandwidth and CPU (2)

Without assembly, the number of threads is simplified to a direct while loop recv, setsockopt so_sndbuf, So_rcvbuf set to 256*1024, the test result in a short time is 6.7gb/s. But the long test results are as follows:

The horizontal axis of the ROS receives the number of event, in 40000 units.

(x, Y) indicates that when Ros receives the x*40000 event, the bandwidth of the receiving end is Y gbits/s. Event size is 2KB.

As can be seen, the bandwidth of the receiving end after a period of time to maintain the 6gb/s, is continuously reduced. However, the bandwidth of the transmitting side is always kept above 6.4gb/s.

Send speed:6.45782gb/ssend Speed:6.45631gb/ssend Speed:6.43146gb/ssend Speed:6.44313gb/ssend Speed:6.37502gb/ssend Speed:6.44647gb/ssend Speed:6.45929gb/ssend Speed:6.37766gb/ssend Speed:6.39508gb/ssend Speed:6.44929gb/ssend Speed:6.45014gb/ssend Speed:6.44203gb/ssend Speed:6.44749gb/sqsend Speed:6.42823gb/ssend Speed:6.43295gb/ssend Speed:6.44113gb/ssend Speed:6.44306gb/ssend Speed:6.41997gb/ssend Speed:6.44833gb/ssend Speed:6.42745gb/ssend Speed:6.44259gb/s ...

Is there a problem with this so_sndbuf,so_rcvbuf setup? is the SO_SNDBUF and SO_RCVBUF only set on the receiving end, and does not set the cause of the sending side? Or is there a problem with the size of this setting? This value should be set to the delay bandwidth product?

Ros Fetch number Threading analysis (4): Without assembly: socket option So_sndbuf,so_rcvbuf effect on bandwidth and CPU (2)