Re: [simspark-devel] Timer

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

Hi Hedayat and Khashayar,

Thanks for your replies, but I can't say I agree with Hedayat. To stick to
your points:

1. This is indeed a fast and easy to have 6 vs 6 games on any system.
However, this means agents practically will have infinite available thinking
time, which isn't realistic. Moreover, this makes the length of a game
variable depending on the agents, which is a pain for organisation. For
these reasons such a 'Sync' timer model is not feasible and definitely not
desirable during actual competitions, coming back to my argument that teams
won't be able to prepare well, because games they play at home are not
representable of games played at the competitions.

2. There has been improvement in the latest version. However, as you said it
is only 'less sensitive' and 'more fair', but still sensitive and unfair.

3. I do agree with you that it is interesting to research adaptation to
changes in processing power, network delays, et cetera, but as I said in my
previous E-Mail and as discussed during the road map discussion, this has to
be controllable. At the moment this is totally random. Regarding the
unbalanced unfairness for different teams, this can be caused by factors
outside of the server like hardware, which can be mediated with a better
timer. But even without any bug in the server and with perfectly fair
hardware it could be that the agents of one team require more thinking time
than the current setup supplies. Now you can say that's their problem, they
should have been programmed more efficient or shouldn't use those infeasibly
complex algorithms, but to come back to reproducibility again (and
Khashayar's experience): there is no way they can know beforehand that it
will be a problem, because they don't have access to the exact same system.

So concluding, I still think a good timer is of high importance.

Cheers,
Sander

On Thu, Nov 26, 2009 at 5:14 PM, Khashayar <kh....@gm...> wrote:

> Dear Sander and Hedayat
>
> First of all I would like to mention the point that only 'fair games' as
> Hedayat said is not enough, and we need to do sth to reduce the
> disadvantages of our platform sensitivity to timing difficulties like
> network delays. I deeply believe that we do need a timer that gives each
> agent the same, predetermined amount of processing time for each time
> step in *any* (network / system) conditions. I remember this problem
> affected our team (Scorpius) greatly in Graz competitions, Although as
> Hedayat mentioned this small effect will take place for both teams during
> competition but because we hadn't handled it before (and it's really hard to
> handle!), that caused our agents to fall down in their Max speed of walking
> during the matches on server which had never happened on our systems before.
> Overall, i think that we should consider this (timer) problem even if it may
> seems fair or ignorable!
>
> On Thu, Nov 26, 2009 at 3:39 AM, Hedayat Vatankhah <hed...@ai...>wrote:
>
>> Hi Sander,
>> Just some notes (maybe not directly related to the main discussion; sorry
>> for that):
>> 1. It is possible to make running full 6 vs 6 (or more) games possible for
>> everyone without a new timer: the proposed Sync mode (in which the simulator
>> will proceed to the next cycle when all of the connected agents tell it to
>> do so) could enable teams to run games on any system successfully. This
>> could be at least a temporary workaround while we do not have a new timer.
>> 2. The latest code is less sensitive to small network delays than before,
>> and it is more fair.
>> 3. IMHO we should not desire strictly equal conditions for all teams
>> during the whole game; since it doesn't happen in real world too. Small
>> hardware/network delays and other such things might happen in real robots
>> too. However, these should happen really "random" with the same probability
>> for both teams. It should not affect one team more. I'm not sure if it needs
>> a new timer; if the simulator could provide some advantage for one team
>> during a game, it is probably a bug somewhere in the current code, or in the
>> game cluster setup.
>> So I think the timer should be fair, but it does not necessarily mean that
>> all agents should always receive exactly the same thinking time. The
>> thinking time could vary during the game, but it should happen for both
>> teams almost equally.
>>
>>
>> Thanks,
>> Hedayat
>>
>>
>>
>> On ۰۹/۱۱/۲۵  05:43, Sander van Dijk wrote:
>>
>>  Hello fellow 3D-ists,
>>
>> During the competitions in Graz this year we discussed the future of our
>> league in the roadmap discussion (see Sahar's mail on the 3D list from 24th
>> of July for a full summary). The most important point was that next year we
>> want to double the amount of players and play 6 vs 6 games. There is already
>> good work under way to make this possible (e.g. multi threading (Hedayat)
>> and possibility for different (maybe faster) physics engines (Andreas, great
>> stuff!)). However I think the most important thing (I even think crucial
>> thing) is missing: a good timer.
>>
>> There are 2 reasons I think this needs high priority:
>>
>> 1. To have fair games. The last few years there was already some
>> discussion about fair timing. Especially in China things seemed to go wrong,
>> where in the same game one team seemed to be more affected than the other
>> team. With more agents this will only get worse, especially I expect when we
>> throw more computers into the mix (multiple computers per team for
>> instance). There is an argument that can be made for limiting the think time
>> by real time and hardware constraints, but at the moment it is too
>> uncontrolled. With network traffic, thread scheduling, et cetera, the amount
>> of processing time an agent gets is basically random and some agents/teams
>> may be disadvantaged.
>>
>> 2. To have reproducible games. Hereby I don't mean that games should be
>> deterministic, some noise is needed (though again, in a controllable way),
>> but games run on one system should be representable of games played on
>> another system (and especially on the same system at a different time).
>> Herein also lies the reason I think a better timer is crucial and even more
>> important than the other improvements being made:
>>
>> � Without a good timer teams may not be able to prepare for the
>> competitions, especially if they don't have access to a cluster of high end
>> machines like we will hopefully have, simply because they cannot play full 6
>> vs 6 games that reflect games at the competitions.
>>
>> So what I think we need is a timer that gives each agent the same,
>> predetermined amount of processing time for each time step. This possibly
>> reduces simulation speed to less than real time, but at least anybody then
>> can run a full match on any system and all other improvements become less
>> pressing if you only consider ability to play a game (but of course in the
>> end we do want real time). In Austria we said 'don't complain if you don't
>> contribute' and I would like to go ahead and implement something like this,
>> however I am missing the time. But hopefully I convinced you that this is
>> one of the (if not *the*) most important issue for next year and I can put
>> down some points to perhaps guide to a solution:
>>
>> - We used to have a system which did mostly what I said above: the Spades
>> middleware system [1], however it didn't make the transition from spheres to
>> humanoids in 2007. What was the exact reason, does it have unwanted
>> properties or is it a lack of knowledge about it? I think Joschka can shed
>> some more light on this probably?
>> - What properties do we want the timer to have? Do we want to limit CPU
>> cycles which might give teams using e.g. Java a disadvantage compared to
>> assembly hackers, or computation time which might make the timer still too
>> machine-specific..
>> - How does timing in the 2D simulation work, can we learn something from
>> that, or even just copy it?
>> - And most important: who will work on this?
>>
>>
>> Cheers,
>> Sander
>>
>>
>> [1] http://spades-sim.sourceforge.net/
>>
>>
>>
>> --
>> Adaptive Systems Research Group
>> Department of Computer Science
>> University of Hertfordshire
>> United Kingdom
>>
>>
>> ------------------------------------------------------------------------------
>> 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 lis...@li...://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
>>
>>
>
>
> --
> Best Regards
> Khashayar
>



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