[ros-users] Latency of subscriber callback for large amount of data

[Daniel Stonier]

On 14 October 2011 08:52, Troy Straszheim <straszheim at willowgarage.com>wrote:

> On Thu, Oct 13, 2011 at 4:46 PM, Eric Perko <wisesage5001 at gmail.com>
> wrote:
> > On Thu, Oct 13, 2011 at 7:33 PM, Kim, Yoonsoo <yesarang.kim at gmail.com>
> > wrote:
> >>
> >> Troy,
> >> What do you think about providing TCP_NODELAY option at ros::init()
> >> and making this option default transport hint for suceeding subscriber
> or
> >> publisher
> >> initialization?
>
> Again, this might have been a reasonable default in the beginning, but
> at this point I am very reluctant to subtly change the networking
> behavior of roscpp, given that there is no way to check if the user
> needs to be warned about this change of behavior... it will break
> things (as Eric points out, it could cause wireless links to saturate,
> etc) without explanation.
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>


We ran into this a while ago as well. For us though, in one part where the
actual arrival time wasn't so important (I think those ones were on 25ms
periods and were sometimes coming in pairs), we modified the algorithm and
made sure to use timestamps in the messages. For others, like where we are
trying to run at 10ms periods, we just made sure nodes that are
communicating at that rate are running as nodelets under the same nodelet
manager. Dropping the high frequency tcp/ip chatter also saved us alot of
cpu cycles on an atom.

Having TCP_NODELAY as a non-default option at ros::init might be convenient.
Though, I do think there are other ways to attack the problem as above. Can
your use case do something like that?

Daniel.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20111014/9fe418a2/attachment-0004.html>