[ros-users] ROS cpu load

Josh Faust jfaust at willowgarage.com
Sat Jul 31 04:28:40 UTC 2010

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.

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

More information about the ros-users mailing list