On Thu, Oct 13, 2011 at 7:33 PM, Kim, Yoonsoo <span dir="ltr"><<a href="mailto:yesarang.kim@gmail.com">yesarang.kim@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Troy,<div><br></div><div>What do you think about providing TCP_NODELAY option at ros::init()</div><div>and making this option default transport hint for suceeding subscriber or publisher</div><div>initialization?</div><div>

<br></div><div>Another thought is that nowadays, bandwidth is not a critical resource and also</div><div>unlikely to be a major problem source for small message exchanges because </div><div>they do not consume bandwidth greatly but large messages do.</div>

<div>2x bandwidth consumption of small messages may not be a visible </div><div>behavior change for most ROS users, IMO.</div><div>And TCP_NODELAY is highly probable to be a reasonable default for most of </div><div>robot applications, considering that ros_comm is made primarily for robot applications, </div>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>- Eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div><br></div><div><font color="#888888">- Yoonsoo</font><div><div></div><div class="h5"><br><br><div class="gmail_quote">2011/10/14 Troy Straszheim <span dir="ltr"><<a href="mailto:straszheim@willowgarage.com" target="_blank">straszheim@willowgarage.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>On Thu, Oct 13, 2011 at 11:02 AM, Edwards, Shaun M. <<a href="mailto:sedwards@swri.org" target="_blank">sedwards@swri.org</a>> wrote:<br>
> Troy,<br>
><br>
> I have ran into this same problem many times when working with sockets.  Is<br>
> there a reason not to turn off the nagel algorithm by default.  Turning off<br>
> the Nagel algorithm would seem to be the default behavior for small<br>
> messages.  This would result in more network traffic, but this is probably<br>
> what is desired (i.e. messages arriving as they are sent, instead of<br>
> buffered).<br>
<br>
</div>A reasonable question.  Maybe it would have been a good decision to<br>
turn it off by default initially (i.e. a few years ago) or not....<br>
but at this point I'd be very reluctant to subtly change the behavior<br>
of every subscriber in ROSland.  Imagine the consternation when pipes<br>
that used to exchange lots of small messages efficiently,  suddenly<br>
start to use 2x more bandwidth than they used to.<br>
<br>
Of course enabling TCP_NODELAY doesn't guarantee you anything.  If you<br>
really absolutely need to process things at 100Hz you'd be doing<br>
things completely differently (i.e. realtime kernel and whatnot).<br>
<font color="#888888"><br>
-t<br>
</font><div><div></div><div>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org" target="_blank">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
</div></div></blockquote></div><br></div></div></div>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@code.ros.org">ros-users@code.ros.org</a><br>
<a href="https://code.ros.org/mailman/listinfo/ros-users" target="_blank">https://code.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br>