Re: [simspark-devel] [Sserver-three-d] Fwd: Re: Timer

[Sander v. D. <sgv...@gm...>]

Hi,

I think Hedayat's proposal is a step in the right direction to make things
more fair. By placing the timing on the client computer it overcomes
problems that may be caused by networking (an important feature that Spades
had) and it indeed shouldn't be too much work to implement.

However, even though this solves networking issues and makes thinks about as
fair as possible in a single game with homogeneous client computer setups,
it does not solve the problems of reproducibility and being able to prepare
well on different systems when we use fixed real time time steps. I have
thought about it more since my first email and think now that what is
desirable is to (roughly) define the think time in cpu
cycles/instructions/floating-point operations. Only that way agents get
similar restrictions/possibilities when run on different machines. The point
I made earlier about disadvantaging for instance Java implementations is
invalid, since on real robots such implementations will have a disadvantage
too. Also, when limiting based on real time they will still have this
disadvantage.

There are two ways to limit by processing time (that I can think of):
- Make the server keep an eye on this. This is what Spades did, however some
people (and my unreliable memory) say that this had problems, either because
it wasn't accurate enough, or just plain buggy. And, like mentioned earlier,
this may not work well in multi core setups (more on this later). Does
anybody know more details of this, or knows of an accurate way to check and
limit cpu usage?
- Determine a formula that gives a value for the real time step size given
details of the setup, which can be implemented in the server, or given as a
guideline.

I think for now the second option is the easiest and my suggestion would be:

t = N * Cs * A / (Cr * I)

Where N is the number of instructions we want to give an agent, Cs the
number of simulated cores, A the number of agents run simultaniously on a
single machine, Cr the number of real available cores and I the the number
of instructions per second each real core can do. This still isn't perfect,
if the amount of simulated cores is lower than the real number, agents using
more threads than simulated cores still have an advantage, but this could
maybe be overcome by restricting each agent to be able to use no more than
the simulated amount of cores (it's CPU affinity. On Linux this can be set
with schedtool).

Regards,
Sander

On Fri, Nov 27, 2009 at 6:44 PM, Hedayat Vatankhah <hed...@ai...>wrote:

>  Hi,
>
>
> On ۰۹/۱۱/۲۷  08:19, Mahdi wrote:
>
> Hi Hedayat
>
> � In my opinion, this may be good way of implementing a timer. But can you
> provide more detail on your proposal? Since there are some points which
> shall be calrified before implementing any timer solutions. There are things
> which shall be considered in mind, like:
>
> � * How and When agents are informed of a new cycles and data associated
> with each cycle?
> � * How and When agents shall send their commands to the proxy?
>
> Why this should be different from the current situation? I was thinking
> about the same way as now. Agents can receive data from sensors in each
> cycle, and they should their commands before the end of the cycle (about
> 0.02 seconds from the time they receive senses). (BTW, this model fits well
> with the Player integration goal; and when done agents will communicate with
> sensors/actuators in the Player way).
>
> � * How will the proxy behave if a team responds after specified time for a
> cycle?
>
> The received commands will be sent to the server in the next cycle.
>
>
> ��� - Will proxy announce a player dead after several cycles
> ��� - Or will it just send the actions of agent in the next cycle?
>
> � I think any proposal shall answer these question besides describing it's
> scheme of communication between agents and simulator.
>
> What is in my mind is that with the current protocol, players should
> communicate with the proxy in the same way as they communicate with the
> simulator now. So there is no need to modify agents' code. When integrated
> with Player, agents will communicate with the server using that method.
>
> Good luck,
> Hedayat
>
>
> Best Regards
> Mahdi
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
>
>
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Simspark Generic Physical MAS Simulator
> simspark-devel mailing list
> sim...@li...
> https://lists.sourceforge.net/lists/listinfo/simspark-devel
>
>


-- 
Adaptive Systems Research Group
Department of Computer Science
University of Hertfordshire
United Kingdom