[ros-users] Shared memory image plugin

[Cedric Pradalier]

Hi,

this discussion raised my curiosity, so I created a small test program 
to evaluate the advantage of using shared memory. The program is quite 
simple: on one end a publisher is creating an image of some size, and 
publishing it with a timestamp given by ros::Time::now(), on the other 
end, a receiver is receiving the image, and recording the difference 
between ros::Time::now() and the image timestamp.

I made this test for 1000 images, from 640x480x1, 640x480x3, 
1500x1000x3, 3000x2000x3. The results are summarised in the attached pdf.

I also attach the test file so that someone can point out if something 
is wrong in my test.

The bottom line is: for big object, shared memory transfer reduces 
significantly the delivery delay.

I hope that helps.

Best

Josh Faust wrote:
>
>
>         Shared memory transport is a common feature request. There's a
>         long discussion of the issues at
>         http://ros-users.122217.n3.nabble.com/Shared-memory-transport-using-C-in-ROS-td414682.html
>         <http://ros-users.122217.n3.nabble.com/Shared-memory-transport-using-C-in-ROS-td414682.html%20>that
>         should get you caught up.
>
>     This links says me "Not found"...
>
>  
> The first link works: 
> http://ros-users.122217.n3.nabble.com/Shared-memory-transport-using-C-in-ROS-td414682.html
>  
>
>
>         Short version:
>          * We haven't found shared memory transport of serialized data
>         to be a significant improvement versus TCP over loopback, but
>         are interested in evidence to the contrary.
>          * Storing the message objects themselves in shared memory
>         could be a win, but gets very complicated to implement.
>          * We've focused on optimizing intra-process (no-copy) message
>         passing and are developing the nodelet
>         <http://www.ros.org/wiki/nodelet> infrastructure; big point
>         clouds are the motivating use case.
>
>     Similarly, I don't observe a significant performance gain on my
>     laptop either. From htop output, I could make myself believe that
>     5-10% perf gain are possible, but this is clearly marginal.
>     However, it might be different with more active processes, more
>     cpus, less cpus, more/less rams, bigger use of the network stack,
>     different hardware (gumstix?), so I would tend to put this
>     image_transport_plugins in the common pool, just in case.
>
>
> Again, without data showing it's faster (and perhaps a testsuite so 
> that others can test on different configurations), it's not 
> worthwhile.  Nodelets will be orders of magnitude faster for any but 
> the smallest images (where they will still be faster).
>
> You're welcome to put this in your own repo and share it with the 
> community.  I would suggest fixing some of the boundary cases first 
> though.
>
> Josh
> ------------------------------------------------------------------------
>
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>   


-- 
Dr. Cedric Pradalier
http://www.asl.ethz.ch/people/cedricp

-------------- next part --------------
A non-text attachment was scrubbed...
Name: delays.pdf
Type: application/pdf
Size: 4491 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100508/8e725966/attachment-0005.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: publisher.cpp
Type: text/x-c++src
Size: 1429 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100508/8e725966/attachment-0010.cpp>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: receiver.cpp
Type: text/x-c++src
Size: 1226 bytes
Desc: not available
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100508/8e725966/attachment-0011.cpp>