[ros-users] ROS cpu load

[Josh Faust]

On Fri, Jul 30, 2010 at 7:28 PM, Cedric Pradalier <
cedric.pradalier at mavt.ethz.ch> wrote:

> On 07/31/10 01:56, Josh Faust wrote:
> > There are a couple different polling timeouts used that may affect this:
> >  xmlrpc_manager.cpp:256:   server_.work(0.01);
> >  poll_manager.cpp:95:  poll_set_.update(10);
> >
> > If you're using timers:
> >  timer_manager.h:508:  timers_cond_.timed_wait(lock,
> > boost::posix_time::milliseconds(1));
> >
> > Adjusting these to your needs will likely help quite a bit -- we don't
> > run on any embedded systems here, so we're haven't optimized for them
> > or provided knobs to tweak for these.
>
> Thanks a lot.
> Changing the 2 first timeouts to 0.1 and 100 respectively my process
> much much lighter on my system. My real program is now oscillating
> around the 1% mark, which match my expectation for something gathering
> data on a serial port and publishing them at 30 fps.
>
> I'm not quite sure what is the drawback of this change. My understanding
> is that it will make the program termination and some connection closing
> a little bit slower. Is there something more?
>

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.


>
> Now, I'm not using timers in these programs, so I cannot say what is the
> influence of the 1ms wait in timer_manager.h. I have not looked at the
> code in details, but it look like this wait could be advantageously
> replaced by the following code:
>
>       int remaining_time = std::max((int)((sleep_end.toSec() -
> current.toSec())*1000),0);
>        timers_cond_.timed_wait(lock,
> boost::posix_time::milliseconds(std::min(50,remaining_time)));
>
> Is there any reason to verify that the time is not going backward at 1kHz?
>


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.

Josh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ros.org/pipermail/ros-users/attachments/20100730/51da4e72/attachment-0003.html>