<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
<p style="margin-bottom: 0cm; margin-top: 0pt;">Hi all,</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Today, I have played
with the server a bit, and these are the results (might be useful!);</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">1) I did a test with
dWorldQuickStep() instead of dWorldStep(). With the default iterations,
players would explode. I tried with 100 and 1000 iterations, the robots
didn't explode but they did some strange behaviors. I think that it is
not useful, at least with the current parameters. </p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">2) I did what Joschka
said about the Space creation. It seems reasonable so it is included in
the patch I've attached to this mail. However, I didn't notice any
improvements. (Not an accurate comparison, just some observations.)</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">3) I was unable to run
the server in the multi-threaded mode (it crashed), and I decided to
have a look at code. I decided to rewrite some parts of it and I used a
barrier object instead of using condition variables. I think the code
is a little simpler now and might be a little faster too. The code is
attached to this mail. It seems that the EndCycle functions are not
thread safe and also, when the EndCycle function of the RenderControl
is called outside the main thread it crashed on the first gl function
call (at least in my system). I implemented this (treating
RenderControl as an exception) and it didn't crashed like before, but
after some time it crashed in the middle of one of EndCycle functions
which shows that the EndCycle functions are not thread safe. For now, I
removed that exception and I simply call EndCycle functions in the main
thread. It might be possible to improve things a little by moving some
of the functionality of EndCycle function into the surprisingly unused
SenseAgent/ActAgent functions!</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Finally, I'm still
unable to use an external monitor in multi-threaded mode. So currently
I run the external monitor in single threaded mode. I didn't
investigate it.<br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">4) What's the reason
for stepping in discreet steps in SimulationServer::Step()? I think
that it wouldn't change anything for GameControlServer, but what about
the scene server?! Will it change anything with ODE?</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">5) As reported in
sserver mailing list, simulation is more stable with ODE 9.0, but much
performance improvement is needed. On my system (AMD 3000+) with 6
agents, each simulation step (using non-discreet steps) needs around
0.04s.</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">6) I ran a profiling
test of the server right now, and it seems that (well, it was my first
experience with callgrind!) dWorldStep is really a bottleneck. It might
be related to the current robot model...<br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;"><br>
</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Good luck,</p>
<p style="margin-bottom: 0cm; margin-top: 0pt;">Hedayat<br>
</p>
</body>
</html>
|
