<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
<br>
To continue on my fight against overhead, I've had good performance
improvement of rosout by replacing all the timeout argument in the
CallbackQueue::callAvailable and CallbackQueue::callOne from 0.01s to
0.1s. <br>
Now my rosout is really sitting in a corner doing nothing while I'm not
logging.<br>
<br>
Can you foresee any drawbacks from this change?<br>
<br>
On 07/31/10 11:15, Cedric Pradalier wrote:
<blockquote cite="mid:4C53E99B.1090406@mavt.ethz.ch" type="cite">
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<br>
<blockquote
cite="mid:AANLkTi=KeTcgA68g0u0KhUFYoQ9eYagX8Vqqd5mOFk17@mail.gmail.com"
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; 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>
<br>
</blockquote>
<br>
Thanks for the feedback. <br>
<br>
I somehow feel sorry to loose at least 15% of the CPU time per node on
my embedded system for something that is only an issue for simulation
systems.<br>
What would make the most sense: separating the simulation functionality
from the (pseudo) real-time system, or add a global parameter that
define which type of system we are running? I would think the second
possibility is better and easier to implement. <br>
<br>
I for one will definitely apply the above change to all my on-board
system. The gain is too dramatic to ignore. <br>
<br>
Now, a bonus question I'm going to investigate now: is there the same
kind of high frequency threads in the rospy implementation?<br>
</blockquote>
-- <br>
<pre class="moz-signature" cols="80">Dr. Cedric Pradalier
<a class="moz-txt-link-freetext" href="http://www.asl.ethz.ch/people/cedricp">http://www.asl.ethz.ch/people/cedricp</a>
</pre>
</body>
</html>