Re: [simspark-devel] performance

[Yuan X. <xuy...@gm...>]

Hi Hesham,

 Our team binary in China Open 07 has been published in
http://xuyuan.cn.googlepages.com/SEU-RedSun-Final.tar.gz,
and our team binary in RC07 is here:
http://xuyuan.cn.googlepages.com/SEU-RC07-binary.tar.gz

Hope it can help.

2008/1/30, Hesham <hes...@gm...>:
>
> Hi Yuan, Salam Hedayat,
>
> Yuan, you're absolutely right. I need to have kind of stress test as well to
> have a better insight into the server performance. As you know for a such a
> long time I haven't worked on a team for 3D soccer. So I was wondering if
> you can send me a binary that (with normal expected behaviours) makes ODE
> take a long time to simulate. Like a specific collision or whatever. I'm
> using the test agents that stand and just move their arms and send/hear
> messages. I've started optimizing ODE, it's not easy but so far it's
> promising, on the weekend I'll let you know the progress.
>
> Thanks in advances,
> Hesham
>
>
> On 28/01/2008, Yuan Xu <xuy...@gm...> wrote:
> > Hi all,
> >
> > >
> > > Next weekend I'll try to work more on these issues, and probably until
> then
> > > will know the answer of your 4th question.
> > >
> > > 4) What's the reason for stepping in discreet steps in
> SimulationServer::Step()?
> > > Will it change anything with ODE?
> >
> > Yes, dWorldStep(20ms)+dWorldStep(20ms) !=
> dWorldStep(40ms).
> > Because, the collision detection is missing in dWorldStep(40ms).
> >
> >
> > > Yuan, the code of SDL_GetTicks() is simple, it doesn't give any more
> > > precision. I didn't get some parts of what you said.
> >
> > Yes, the precision depends on the OS, then I remind the RTL, and I
> > know it is not suitable.
> >
> > > Maybe a silly question
> > > but, the server is supposed to have sharp 20ms cycles?
> >
> > The cycle duration effects the performance of robot controller.
> > Note that the control cycle is less than 10ms in real robot.
> > The longer cycle the harder for the controller.
> > And the HMDP[Joschka] may solve this, but it will make teams to change
> > their codes a lot.
> >
> > > I thought the
> > > previous timing method (SPADES) was replaced by the new one to get rid
> of
> > > the problems we had with timers, and more rely on time stamps. But you
> > > suggested using RTL to have more precise timers.
> >
> > The SPADES do not count the real time, it counts how many jiffies used
> > by the agent.
> > It can measure the CPU cost of the agent, but if the agent spend a lot
> > of time on other work, such as communication, writing logs, the game
> > will be very slow. Jelle Kok said that some games last less than
> > 10min, but some other games need more than 1 hour!
> >
> > > Sorry maybe I got the whole
> > > thing wrong, I'll go through the code again. But I would appreciate it
> if
> > > you (or others) could please remind me the new idea for timing, maybe by
> > > referring to old emails - I couldn't find them.
> > >
> >
> > The timer was designed just like the 2D server: fixed cycle duration,
> > the agent should sent action in time, otherwise the action will not be
> > executed. The difference between 2D and 3D only are the duration and
> > implementation.
> >
> >
> > Best wishes!
> >
> > Xu Yuan
> >
>
>


-- 
Best wishes!

Xu Yuan
School of Automation
Southeast University, Nanjing, China

mail:   xuy...@gm...
          xy...@ya...
web:   http://xuyuan.cn.googlepages.com
--------------------------------------------------