Re: [simspark-devel] Simulation cycle

[Hedayat V. <hed...@gm...>]

Hi Sander,


/*Sander van Dijk <sgv...@gm...>*/ wrote on Tue, 17 Jan 2012 
12:51:42 +0000:
> Hey all,
>
> I am digging through the simulation cycle life time again. If my 
> understanding is correct now (please correct me if I'm wrong, like the 
> last time I thought I had it figured out ;)), this is the order things 
> are happening now:
>
> * StartCycle
> - Read agent messages
> - Realize actions
>
> * SenseAgent
> - Send (last cycle's) sense data to agents
>
> * Step
> - Update physics and game conrol
>
> * SyncTime
> - Wait until 0.02 seconds have passed since last SyncTime
>
> * EndCycle
> - Query and prepare sensor data sent in the next cycle
>
> In this scenario, however, first all sensor data for next cycle is 
> prepared and all agent messages read and parsed, before the sense data 
> is sent to which the agent should have 0.02 seconds to reply. The time 
> these things take depend on how much sense data there is to query, 
> prepare and send, so the time left between SenseAgent and StartCycle 
> is not fixed. I don't know how much time it really is, but the fact it 
> is not constant is a problem.
>
> I think it would be a better idea to place SyncTime after 
> EndCycle/before StartCycle, such that the actual think time becomes 
> independent from how long it takes to query and prepare sensor data. 
> It then still does depend on StartCycle though, however I don't 
> believe there is much fluctuation in how long this takes during a 
> match, and this part has to be after the wait and before SenseAgent in 
> order to keep the same ordering of events from the view of an agent.
If I remember correctly, yes, this is the correct order :D. And your 
suggestion seems reasonable.


>
> If we want to make the think time more consistent not only in a single 
> match but also between matches, we will have to make the wait last 
> until 0.02 seconds after SenseAgent, though I am not sure whether that 
> is needed or not, though let me know what you think
It is related to the way we want to interpret the meaning of "real time" 
simulation. Currently, we *try* to be real-time, and therefore we want 
to have each cycle take 0.02 seconds totally. Your suggestion guarantees 
that we won't be real-time, but it could be considered more consistent 
in the view of agents. So, we should decide if we want to be real-time, 
or more consistent. I don't know which one is more interesting! It seems 
that the original authors preferred the former.

Regards,
Hedayat


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