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
>
|
