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

Kim, Yoonsoo yesarang.kim at gmail.com
Thu Oct 13 23:33:06 UTC 2011


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?

Another thought is that nowadays, bandwidth is not a critical resource and
also
unlikely to be a major problem source for small message exchanges because
they do not consume bandwidth greatly but large messages do.
2x bandwidth consumption of small messages may not be a visible
behavior change for most ROS users, IMO.
And TCP_NODELAY is highly probable to be a reasonable default for most of
robot applications, considering that ros_comm is made primarily for robot
applications,

- Yoonsoo

2011/10/14 Troy Straszheim <straszheim at willowgarage.com>

> On Thu, Oct 13, 2011 at 11:02 AM, Edwards, Shaun M. <sedwards at swri.org>
> wrote:
> > Troy,
> >
> > I have ran into this same problem many times when working with sockets.
> Is
> > there a reason not to turn off the nagel algorithm by default.  Turning
> off
> > the Nagel algorithm would seem to be the default behavior for small
> > messages.  This would result in more network traffic, but this is
> probably
> > what is desired (i.e. messages arriving as they are sent, instead of
> > buffered).
>
> A reasonable question.  Maybe it would have been a good decision to
> turn it off by default initially (i.e. a few years ago) or not....
> but at this point I'd be very reluctant to subtly change the behavior
> of every subscriber in ROSland.  Imagine the consternation when pipes
> that used to exchange lots of small messages efficiently,  suddenly
> start to use 2x more bandwidth than they used to.
>
> Of course enabling TCP_NODELAY doesn't guarantee you anything.  If you
> really absolutely need to process things at 100Hz you'd be doing
> things completely differently (i.e. realtime kernel and whatnot).
>
> -t
> _______________________________________________
> ros-users mailing list
> ros-users at code.ros.org
> https://code.ros.org/mailman/listinfo/ros-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20111014/576e0c85/attachment-0004.html>


More information about the ros-users mailing list