Menu
▾
▴
Re: [simspark-devel] [Sserver-three-d] Timer
|
From: Hedayat V. <hed...@ai...> - 2009-11-27 15:44:34
|
Hi all,
On ۰۹/۱۱/۲۷ 01:45, Feng Xue wrote:
> Hi Sander, Khashayar and Hedayat,
> First of all, I am sorry that I have been acting silence since last
> year and didn't have a team for Graz. But I read every email that sent
> to these two mail lists, especially devel ML. So, I know what things
> are going on here, at least most of them.
:) Happy to hear that.
> With regard to the timer, it's an old topic, but important.
> At the first three years(2004, 2005, 2006), simulation 3D
> league was mainly focusing on strategy making, multi-agent systems,
> collaboration, etc. At the year of 2007, we made a big step to
> humanoid robot which is exciting and longsighted in my opinion.
> However, because of the hardware limitation "or" timing issues, we
> could only run a 2vs2 game. The consequence of this big step is that
> the topic of motion planning and path planning are mainly
> concerned. In another word, the research topics are somewhat
> restricted. However, the first thing to do for RoboCup2008 was solving
> the issues like unstable physics module, unrealistic robot model, etc.
> Well, what is the exact improvement of RoboCup2009 that is benefit
> for our research? Comparied to RoboCup2008, they have the same robot
> model, the same player numbers. Even in ChinaOpen2008(Dec. 2008), it's
> a 4 vs 4 game and had showed the importance of strategy making.
> Back to the timer issue, the current so-called sync solution
> will work, but in a short period. As Sander mentioned in the previous
> email, infinite available thinking time, uncontrollable noise casued
> by the differences of hardware and network delay, etc.
> The gentleman rule has appeared in the 3d rules for these three
> years. It is ridiculous especially when there is no effective
> supervise mechanism. Very long messages, debug tcp or even fast joints
> speed will cost the server much more computation which will bring
> different behaviours comparied to that on our home machines. And now,
> we have one more attack way: the sync. I believe we are all gentlemen,
> but what if it is a bug? It's hard to say. Well, if a person that have
> built a team for competition, he will understand this more easily.
Well, as I said the sync mode is only for development and debugging
purposes. It is certainly not suitable for the competitions.
While a better timer could make things more desirable (I have a proposal
for a timer at the end of this email), things are not that bad now.
There is a trade off between trying to be real time, and being more
deterministic. We've moved from the former towards the latter slightly.
For example, anything which cause the simulator to do more computation
should not affect agents' behaviors. The only effect is to make the
whole simulation slower.
BTW, there are certainly cases that would affect teams (the difference
between remote vs local runs, which should be much more consistent in
the latest code but note completely vanished). Also let me note that my
own team (UI-AI) in 2007 was hardly hit by these timing issues. Our
agents could walk just fine on our systems, but in the competitions they
were almost unable to properly walk. So I can understand what problems
you are talking about.
> Handling the noise is really a good topic. However we are on a
> simulator, not a real robot. We should simulate the noise, not let it
> happen out of our control. And, in my opinion, in order to bring our
> old research topics(strategy making, MAS, etc), the noise should be
> negotiated to avoid letting the motion control be the main topic.
Yes if we want to make things simpler, we should go for a strict and
(almost?) completely deterministic timer.
> Things are really bad now. TCs of 2D have been discussing the idea of
> 2.5D which involving the z axis. We should stop talking about
> the issues that for developers' concern(for example: whether using TCP
> or UDP), but pay more attention to how to bring back more research
> topics. Orelse, we are losing more and more teams.
> Well, as it is said, "don't complain if you don't contribute". But
> someone does contribute or will contribue but is not allowed complain.
> Well, I'd never expected to convince somebody since last year. But I
> am writing this email to support Sander's opinion because it is really
> important.
I think the sentence ("don't complain if you don't contribute") is going
to have a slightly different meaning than the original intent. At least
in my opinion, this sentence is about people who just complain.
Contribution is not necessary by providing code or documentation. If you
are constructive, you are contributing. Personally I do consider
providing constructive comments/suggestions/objections as contributions.
Putting forward discussions like this is far from those who just
complain! Any comments which can affect our decisions is highly
appreciated in MC. :) So, everybody have the right to participate in
such discussions; let alone people like you who are MC members.
Well, unfortunately me first email is going to become problematic. I
tried to avoid that - I said that it is not directly related to the main
subject - but it happened. I stated that we can solve some of the
problems with some simpler solutions than a new timer, like the sync
mode; but I said that "it is a temporary solution while we don't have a
new timer". I didn't want to say that it can fill the need for a new
timer. Also I mentioned that the latest code is less sensitive to small
network delays. To be more precise, except for teams who have some time
consuming computations in decision making and/or doing basic behaviors
(so need almost all of the time of a single cycle); it is not sensitive
to relatively "small" system/network delays. And another problem which
was problematic for many teams was that they were thinking "too fast",
and this could create a huge difference between running the simulator
locally vs running over network. IMHO, many of the teams was suffering
from this problem rather than thinking too much.
But I agree with Sander's point 3, which mostly affects teams which need
long thinking times and as we are going to have more players it'll
become more important. So yes, as far as the hardware used by teams is
not theirs, we need a better timer to mitigate hardware issues and if we
want to make our simulator a bit simpler than the real world in this
regard.
Finally my last comment was about how the new timer should be: in my
opinion, it should not be too strict like SPADES which considers CPU
cycles used by agents. That is too much (an example was what Sander
mentioned about using programming languages) and also considering the
popularity of multi-core CPUs; it should let the teams to use CPU power
completely in the desired cycle time. I'm not completely sure but I
think it would need some (maybe complex) changes in SPADES (considering
a dual core cpu, agents should be able to use both cores for 0.02
seconds, but not using 1 core for 0.04s). As I said before, there is a
trade off here and I think going towards a system which can run the
games equally on ANY system setup is not appropriate.
OK, let me try to bring the discussion back to its main line. I have a
proposal for a new timer, and I want to know your opinions about. It is
simple, and is (hopefully) simple to setup and I think it would satisfy
most of the concerns. But it does not guarantee that the agents'
performance is independent from the machine it runs on.
This is as follows:
For each agent we run a proxy application in the agent's machine (or
maybe it'll be a single proxy for all agents in the machine). Agents
connect to this proxy instead of the main simulator, and communicate
with it. It is the proxy's job to control the thinking time of the
agents. The proxy waits at much as a single cycle before reading more
commands from an agent. After each cycle, proxies must signal the server
to proceed to the next cycle (something like the sync mode, but
controlled by the proxies rather than the agents). There are some
details to prevent agents of interfering with the proxies activity, but
I think we can have an acceptable implementation using appropriate
design and priority settings.
Thanks,
Hedayat
> 20:04:47 2009-11-26 Sander van Dijk:
>
> 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...
> <mailto: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... <mailto: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/
>
>
|
