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

[Eric Perko]

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?
>
> 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,
>

Keep in mind that a large number of small messages will decrease your
throughput when using a wireless link (which is also under the most
bandwidth constraints, especially if you have to do wifi over longer ranges)
when compared to packing the small messages into larger packets, so I don't
think TCP_NODELAY should be the default.

- Eric


>
> - 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
>>
>
>
> _______________________________________________
> 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/20111013/9a03690c/attachment-0004.html>