Menu
▾
▴
Re: [simspark-devel] [Sserver-three-d] Fwd: Re: Timer
|
From: Hedayat V. <hed...@ai...> - 2009-11-28 21:33:01
|
Hi, On ۰۹/۱۱/۲۷ 11:41, Sander van Dijk wrote: > 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. Using that approach, teams can prepare well if their systems is not more powerful than the competition's systems. Whatever works on slower clients should work the same on faster clients since they will have more thinking time on faster clients per cycle. So, anything achieved in slow clients can be reproduced on faster clients. The only remaining problems is that of teams which use clients faster than the competitions clients, and also that teams with slower clients will have less time for thinking on their systems, and so they won't use the full power of competition clients. And personally, I think what an agent MUST do in one cycle is low level control of its joints and some reactive behavior in this area, which should not need much time (such control should usually happen as fast as possible). All other higher level thinking could span several cycles since applying most of such decisions takes several cycles (consider when an agent decides to stop walking). BTW, I have a suggestion which is given below. > > 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). What do you think about this: we can define a simple benchmark which can be used on client systems to determine how much a cycle should last on the client machine. The client proxy will use this value as the time of one cycle. For example: cycle time = (time of running f *= 1.1 for N times)/10 Where N is a parameter defined based on the performance of a reference platform. We can have a small tool to measure and set the appropriate cycle time on clients. How is this? Thanks, Hedayat > > Regards, > Sander > > On Fri, Nov 27, 2009 at 6:44 PM, Hedayat Vatankhah <hed...@ai... > <mailto: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... >> <mailto: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... > <mailto:sim...@li...> > https://lists.sourceforge.net/lists/listinfo/simspark-devel > > > > > -- > Adaptive Systems Research Group > Department of Computer Science > University of Hertfordshire > United Kingdom |
