Menu
▾
▴
Re: [simspark-devel] Timer
|
From: Hedayat V. <hed...@ai...> - 2009-11-26 20:11:38
|
Hi, On ۰۹/۱۱/۲۶ 10:34, Sander van Dijk wrote: > 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. Yes, the proposed sync mode is just for debugging purposes. > > 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. Well, I noted that I'm not against a better timer, but to say that: 1. things are not that bad, 2. the timer does not need to provide strictly the same processing time to the agents (as measured in CPU cycles!) I'm not sure but I think there is no such strict timing in 2D too. There is not any special software on client machines to control agents' thinking time. Maybe the main difference is (I'm not sure about it) that they use UDP instead of TCP. Good luck, Hedayat > > 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/ >> >> >> >> -- >> 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 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 > > > > > -- > Best Regards > Khashayar > > > > > -- > Adaptive Systems Research Group > Department of Computer Science > University of Hertfordshire > United Kingdom |
