<br><br><div class="gmail_quote">On 14 October 2011 08:52, Troy Straszheim <span dir="ltr"><<a href="mailto:straszheim@willowgarage.com">straszheim@willowgarage.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, Oct 13, 2011 at 4:46 PM, Eric Perko <<a href="mailto:wisesage5001@gmail.com">wisesage5001@gmail.com</a>> wrote:<br>
> On Thu, Oct 13, 2011 at 7:33 PM, Kim, Yoonsoo <<a href="mailto:yesarang.kim@gmail.com">yesarang.kim@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Troy,<br>
>> What do you think about providing TCP_NODELAY option at ros::init()<br>
>> and making this option default transport hint for suceeding subscriber or<br>
>> publisher<br>
>> initialization?<br>
<br>
</div>Again, this might have been a reasonable default in the beginning, but<br>
at this point I am very reluctant to subtly change the networking<br>
behavior of roscpp, given that there is no way to check if the user<br>
needs to be warned about this change of behavior... it will break<br>
things (as Eric points out, it could cause wireless links to saturate,<br>
etc) without explanation.<br>
<div><div></div><div class="h5">_______________________________________________<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>
</div></div></blockquote></div><br><br><div>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. </div>
<div><br></div><div>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?<br clear="all">
<div><br></div><div>Daniel.</div>
</div>