<br><br><div class="gmail_quote">On Fri, Jul 30, 2010 at 7:28 PM, Cedric Pradalier <span dir="ltr"><<a href="mailto:cedric.pradalier@mavt.ethz.ch">cedric.pradalier@mavt.ethz.ch</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 07/31/10 01:56, Josh Faust wrote:<br>
> There are a couple different polling timeouts used that may affect this:<br>
>  xmlrpc_manager.cpp:256:   server_.work(0.01);<br>
>  poll_manager.cpp:95:  poll_set_.update(10);<br>
><br>
> If you're using timers:<br>
>  timer_manager.h:508:  timers_cond_.timed_wait(lock,<br>
> boost::posix_time::milliseconds(1));<br>
><br>
> Adjusting these to your needs will likely help quite a bit -- we don't<br>
> run on any embedded systems here, so we're haven't optimized for them<br>
> or provided knobs to tweak for these.<br>
<br>
</div>Thanks a lot.<br>
Changing the 2 first timeouts to 0.1 and 100 respectively my process<br>
much much lighter on my system. My real program is now oscillating<br>
around the 1% mark, which match my expectation for something gathering<br>
data on a serial port and publishing them at 30 fps.<br>
<br>
I'm not quite sure what is the drawback of this change. My understanding<br>
is that it will make the program termination and some connection closing<br>
a little bit slower. Is there something more?<br></blockquote><div><br></div><div>Essentially, yes.  I think those #s are from the days when the xmlrpc and ROS polling happened in the same thread, so we didn't want to starve 1 or the other.  I'll have to look into if they severely affect anything else.</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Now, I'm not using timers in these programs, so I cannot say what is the<br>
influence of the 1ms wait in timer_manager.h. I have not looked at the<br>
code in details, but it look like this wait could be advantageously<br>
replaced by the following code:<br>
<br>
       int remaining_time = std::max((int)((sleep_end.toSec() -<br>
current.toSec())*1000),0);<br>
<div class="im">       timers_cond_.timed_wait(lock,<br>
</div>boost::posix_time::milliseconds(std::min(50,remaining_time)));<br>
<br>
Is there any reason to verify that the time is not going backward at 1kHz?<br></blockquote><div><br></div><div><br></div><div>This is unfortunately not possible because of the ROS clock used in simulation.  If simulated time is going faster than normal time you end up missing timer events.  Building up a predictive model of how fast time is actually moving is possible, but not high priority.</div>

<div><br></div><div>Josh</div></div>