Re: [simspark-devel] Timer Test Report

[Joschka B. <jbo...@un...>]

Hi Yuan,

Yuan Xu wrote:
> After several experiments, we got the conclusions below:
> * If the load of server is light, the timer works well.
> * The rendering influences the timer greatly.
> * The 10 humanoid robots physics simulation is too complex,
>  the simulation time is longer than the real time,
>  so that the timer can not work properly.
>
> The full report is at http://xuyuan.cn.googlepages.com/test-timer-rc1.pdf
>

first of all, thank you very much for the detailed experiments and the 
report! I'm sorry I couldn't reply earlier :-(

I couldn't really test the timer myself properly yet because of problems 
in the external monitor. I recently worked on that and submitted some 
updates to the server and the external monitor (monitorspark) to the 
CVS. The rendering is now by default disabled in the simspark (I added 
the TimerSDL in the initialization of the InputServer). The external 
monitor now gets an update every cycle, otherwise I got very strange 
rendering errors.

I have to help out at the JapanOpen 2007 in the next days (until 05/05), 
but I would be glad if somebody could test the current setup, if 
possible, also using Yuan's timer (since the rendering can now be done 
on an external machine).

Concerning the timer itself:

* For submitting the code to the CVS, we need a test to check for the 
boost_thread-mt library. In some distributions, we need to use 
"-lboost_thread-mt", in others "-lboost_thread-gcc-mt" for linking.
@Oliver: do you think you could do the Makefile magic for that? :-)

* You noticed that only one CPU is used and the others remain idle even 
though we use different threads that should be able to execute in 
parallel without blocking themselves all the time; do you have an idea 
why this is the case?

* It seems evident that we have to optimize the physics somehow. We 
should at least get to the point where 3 vs. 3 robots can be reliably 
simulated, I think. Without having done any profiling at all, my 
suggestion would be to take a look at possibilities to optimize the 
collision detection in the ODE part. One possibility is to use separate 
collision spaces for each robot. From the ODE Wiki [1]:

"Spaces may contain other spaces. These sub-spaces will typically 
represent a collection of geoms (or other spaces) that are located near 
each other. This is useful for gaining extra collision performance by 
dividing the collision world into hierarchies. Here is an example of 
where this is useful:

Suppose you have two cars driving over some terrain. Each car is made up 
of many geoms. If all these geoms were inserted into the same space, the 
collision computation time between the two cars would always be 
proportional to the total number of geoms (or even to the square of this 
number, depending on which space type is used).

To speed up collision a separate space is created to represent each car. 
The car geoms are inserted into the car-spaces, and the car-spaces are 
inserted into the top level space. At each time step dSpaceCollide is 
called for the top level space. This will do a single intersection test 
between the car-spaces (actually between their bounding boxes) and call 
the callback if they touch. The callback can then test the geoms in the 
car-spaces against each other using dSpaceCollide2. If the cars are not 
near each other then the callback is not called and no time is wasted 
performing unnecessary tests."

Anybody know any volunteers (we might ask on the server-three-d ML)?

Cheers,
Joschka

[1] 
http://opende.sourceforge.net/wiki/index.php/Manual_(Collision_Detection)