[ros-users] Shared memory image plugin
jfaust at willowgarage.com
Mon May 10 22:51:10 UTC 2010
I've run the test (1500x1000 images only) on my computer, and do see about a
2x speedup with shared memory over TCP (~4ms avg latency vs. ~9ms).
Nodelets have a couple orders of magnitude advantage (this test shows a ~50
microsecond latency for nodelets). Profiling shows that in all cases most
of the time is spent in memcpy, but I don't have time to investigate
Looking at the code for the pub/sub though, there seems to be a major
problem with how it's structured. Due to only a single shmem buffer being
allocated per publisher and no locking going on, there is a high likelihood
1) Subscriber deserializing while the publisher is serializing resulting
in corrupt data
2) Subscriber receiving the same message multiple times (and losing
3) Unadvertising (publisher node gracefully exiting, for example), causing
Fixing these involves locking/queueing of some sort, as well as dealing with
multiple subscribers and crashed nodes -- which turns the whole thing into a
much larger problem. I can't see this as being generally useful without
solving these -- and to do this nicely (and automatically use sharedmemory
when available) it should be done at the ROS transport level (which would
also allow, for example, recording over shared memory with rosbag).
On Fri, May 7, 2010 at 7:13 PM, Cedric Pradalier <
cedric.pradalier at mavt.ethz.ch> wrote:
> Josh Faust wrote:
>> Excellent! This is good data to have -- I'll take a look at running those
>> tests when I get back to work on Monday.
>> Thanks. I've just noticed a mistake on the interframe plot (+1 offset on
> my columns index). Here is the corrected plot. It does not change the
> overall impression.
> Sorry for the spam.
> Dr. Cedric Pradalier
> ros-users mailing list
> ros-users at code.ros.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ros-users