Hi Cedric,

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 further.

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 of:
  1) Subscriber deserializing while the publisher is serializing resulting in corrupt data
  2) Subscriber receiving the same message multiple times (and losing intermediate messages)
  3) Unadvertising (publisher node gracefully exiting, for example), causing invalid data/crashes

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).

Josh

On Fri, May 7, 2010 at 7:13 PM, Cedric Pradalier <cedric.pradalier@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.

Josh

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
http://www.asl.ethz.ch/people/cedricp


_______________________________________________
ros-users mailing list
ros-users@code.ros.org
https://code.ros.org/mailman/listinfo/ros-users