Menu
▾
▴
simspark-devel — Discussion about Spark development
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(11) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
|
Feb
(1) |
Mar
(6) |
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
| 2007 |
Jan
|
Feb
(24) |
Mar
(19) |
Apr
(2) |
May
(45) |
Jun
(80) |
Jul
(1) |
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2008 |
Jan
(13) |
Feb
(57) |
Mar
(48) |
Apr
(71) |
May
(22) |
Jun
(26) |
Jul
(10) |
Aug
(1) |
Sep
|
Oct
(13) |
Nov
(21) |
Dec
(15) |
| 2009 |
Jan
(33) |
Feb
(36) |
Mar
(30) |
Apr
(8) |
May
(5) |
Jun
(29) |
Jul
(21) |
Aug
(4) |
Sep
(3) |
Oct
(9) |
Nov
(38) |
Dec
(17) |
| 2010 |
Jan
(13) |
Feb
(24) |
Mar
(18) |
Apr
(16) |
May
(13) |
Jun
(25) |
Jul
|
Aug
|
Sep
(4) |
Oct
|
Nov
(18) |
Dec
(2) |
| 2011 |
Jan
(2) |
Feb
(15) |
Mar
(15) |
Apr
(7) |
May
(16) |
Jun
|
Jul
(2) |
Aug
|
Sep
(4) |
Oct
(2) |
Nov
(4) |
Dec
(1) |
| 2012 |
Jan
(6) |
Feb
|
Mar
(9) |
Apr
(5) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
(2) |
| 2013 |
Jan
(4) |
Feb
(5) |
Mar
(2) |
Apr
|
May
(8) |
Jun
(15) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(4) |
Feb
(1) |
Mar
(1) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Hedayat V. <hed...@gm...> - 2011-04-28 13:58:38
|
/*Drew Noakes <dre...@ya...>*/ wrote on 04/28/2011 5:35:02 PM +0450: > Great news. I look forward to trying it out. > > I notice that there haven't been any binaries for Windows since 0.6.3. > It'd be great to have these. In fact, the Windows version gets more > downloads than the Linux versions on SourceForge (possibly because > people get it via package managers on Linux?): > > http://sourceforge.net/projects/simspark/files/rcssserver3d/0.6.3/ Hi Drew, I'm working on the Windows version and (hopefully) it'll be released soon. Thanks, Hedayat > > Drew. > > ------------------------------------------------------------------------ > *From:* Hedayat Vatankhah <hed...@gm...> > *To:* Server3D ML <sse...@li...> > *Cc:* Simspark Devel ML <sim...@li...> > *Sent:* Wednesday, 27 April 2011, 7:41 > *Subject:* [simspark-devel] SimSpark 0.2.2 and RCSSServer3D 0.6.5 are > available now! > > Dear all, > Finally, simspark 0.2.2 and rcssserver3d 0.6.5 are released! You can > download them from [1]. These packages include a number of bug fixes and > improvements since the pre-release versions. Most notably, simspark > includes some bug fixes for log playback and a small fix in network > communication. The latter can affect teams which spend too much time > when thinking. Previously, such agents could slow down the simulator; > but in this release such agents will lose some cycles if they don't > receive simulator's messages on time. > > RCSSServer3D includes some changes too: thanks to the initial patch by > Luis (FC Portugal), and the code to geometrically calculate where the > ball has crossed the goal line by Mehdi (Zigorat/Halcyon), rcssserver3d > should be able to count all goals correctly now. Hopefully, it should > not miss any goals any longer (However, it seems that rcssmonitor might > sometimes fail to update the goal count on the screen). Another patch > was submitted by Mehdi (IIRC) from Nexus3D. With this change, when too > much players are in touch with each other and the number of opponents in > the group are more than the number of teammates of the last player to > joint the group; a member of the opponent team is relocated outside the > field instead of him. Thanks to all for their contribution. > > Like most simultaneous releases, please note that rcssserver3d 0.6.5 > requires simspark 0.2.2 and will *not* work with previous versions of > simspark. Therefore, you should install simspark 0.2.2 and then > rcssserver3d 0.6.5. It is highly recommended to remove previous versions > of simspark and rcssserver3d before installing the latest versions. > Also, remove your ~/.simspark directory before running the latest > version. Notice that, since simspark 0.2.2, spark.rb is copied to > ~/.simspark in the first run, and ~/.simspark/spark.rb is used in > subsequent runs. So, if you want to change anything in spark.rb you > should apply it to ~/.simspark/spark.rb rather than what is installed > along the simulator (It is highly recommended to limit our your changes > to ~/.simspark anyway: e.g. if you want to modify rcssserver3d.rb, copy > it to ~/.simspark and apply your changes there). > > More detailed release notes of rcssserver3d and simspark follows: > > SimSpark 0.2.2 > ========= > This release features many small enhancements which will benefit users. > It contains many bug fixes and performance improvements, in addition to > fixing some compilation issues. The behavior of ACC perceptor has been > slightly > changed, and the multi-threaded mode should work without any known bugs. > Support for the camera sensor is improved too. More details are as > follows: > > - ACC sensor provides raw data without any pre-processing > -- You can apply the following filter to 'RawACC' value received from the > simulator to get ACC value as what you'd receive in previous versions: > ACC = 0.9 * ACC + (0.1) * RawACC > - Using base64 encoding for camera perceptor > - Fixed bugs in multi-threaded mode. > - Compilation fixes > - HingePerceptor can report torque > - Better Performance > - New timing system result in more cleaner code and prevent wasting > CPU time > - Do not block on sending data to clients. Previously, simulator would > block on > send() until it can send all data to clients. > > RCSSServer3D 0.6.5 > ============ > This release comes with a number of enhancements and some bug fixes. Most > notably, the automated referee is improved to prevent many agents to > collide > with each other which is required for running games with more players. > Also, to > better suite the field for running 9 vs 9 games, the field size is > increased > and it is 21x14 now. There are some visual improvements and minor > enhancements > to improve the general experience with the simulator. Finally, > simspark.rb is > renamed to rcssserver3d.rb for more consistency. > > * New touch rules: > The automated referee now enforces two new rules to better prevent > crowding and > a high number of collisions in 9 vs 9 games: > - If an agent is in touch with more than 2 agents (including himself), > and he > wasn't in such a situation in the previous time step - which means he > is the > last to join the group - he is relocated outside of the field. > However, if > the number of opponents in the group are more than teammates, an > unspecified > opponent will be relocated instead. > - If it is not clear which agent joined the group last, e.g. when 3 > players > were all separate at time t, but were all touching each other in time > t + 1, > an agent is chosen at random for relocation. > > * Other Enhancements: > - Visual improvements in rcssmonitor3d: new field texture, colored team > names > and scores > - Set different agent and monitor ports with --agent-port and > --server-port > - Bigger field size: 21x14 > - Updated PDF documentation > - Bug fixes, specially in the automated referee > - New Trainer command (killsim) to terminate the simulator > - Compilation fixes > - Nao robots now sense visual information about field lines by default > - Now you should change the value of enableRealTimeMode variable in > rcssserver3d.rb if you want to turn off using real time mode > > Thanks to all MC members who contributed to this release, > Hedayat Vatankhah > RCSServer3D Maintenance Committee > > [1] http://sourceforge.net/projects/simspark/files > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > <mailto:sim...@li...> > https://lists.sourceforge.net/lists/listinfo/simspark-devel > > |
|
From: Drew N. <dre...@ya...> - 2011-04-28 13:05:14
|
Great news. I look forward to trying it out. I notice that there haven't been any binaries for Windows since 0.6.3. It'd be great to have these. In fact, the Windows version gets more downloads than the Linux versions on SourceForge (possibly because people get it via package managers on Linux?): http://sourceforge.net/projects/simspark/files/rcssserver3d/0.6.3/ Drew. ________________________________ From: Hedayat Vatankhah <hed...@gm...> To: Server3D ML <sse...@li...> Cc: Simspark Devel ML <sim...@li...> Sent: Wednesday, 27 April 2011, 7:41 Subject: [simspark-devel] SimSpark 0.2.2 and RCSSServer3D 0.6.5 are available now! Dear all, Finally, simspark 0.2.2 and rcssserver3d 0.6.5 are released! You can download them from [1]. These packages include a number of bug fixes and improvements since the pre-release versions. Most notably, simspark includes some bug fixes for log playback and a small fix in network communication. The latter can affect teams which spend too much time when thinking. Previously, such agents could slow down the simulator; but in this release such agents will lose some cycles if they don't receive simulator's messages on time. RCSSServer3D includes some changes too: thanks to the initial patch by Luis (FC Portugal), and the code to geometrically calculate where the ball has crossed the goal line by Mehdi (Zigorat/Halcyon), rcssserver3d should be able to count all goals correctly now. Hopefully, it should not miss any goals any longer (However, it seems that rcssmonitor might sometimes fail to update the goal count on the screen). Another patch was submitted by Mehdi (IIRC) from Nexus3D. With this change, when too much players are in touch with each other and the number of opponents in the group are more than the number of teammates of the last player to joint the group; a member of the opponent team is relocated outside the field instead of him. Thanks to all for their contribution. Like most simultaneous releases, please note that rcssserver3d 0.6.5 requires simspark 0.2.2 and will *not* work with previous versions of simspark. Therefore, you should install simspark 0.2.2 and then rcssserver3d 0.6.5. It is highly recommended to remove previous versions of simspark and rcssserver3d before installing the latest versions. Also, remove your ~/.simspark directory before running the latest version. Notice that, since simspark 0.2.2, spark.rb is copied to ~/.simspark in the first run, and ~/.simspark/spark.rb is used in subsequent runs. So, if you want to change anything in spark.rb you should apply it to ~/.simspark/spark.rb rather than what is installed along the simulator (It is highly recommended to limit our your changes to ~/.simspark anyway: e.g. if you want to modify rcssserver3d.rb, copy it to ~/.simspark and apply your changes there). More detailed release notes of rcssserver3d and simspark follows: SimSpark 0.2.2 ========= This release features many small enhancements which will benefit users. It contains many bug fixes and performance improvements, in addition to fixing some compilation issues. The behavior of ACC perceptor has been slightly changed, and the multi-threaded mode should work without any known bugs. Support for the camera sensor is improved too. More details are as follows: - ACC sensor provides raw data without any pre-processing -- You can apply the following filter to 'RawACC' value received from the simulator to get ACC value as what you'd receive in previous versions: ACC = 0.9 * ACC + (0.1) * RawACC - Using base64 encoding for camera perceptor - Fixed bugs in multi-threaded mode. - Compilation fixes - HingePerceptor can report torque - Better Performance - New timing system result in more cleaner code and prevent wasting CPU time - Do not block on sending data to clients. Previously, simulator would block on send() until it can send all data to clients. RCSSServer3D 0.6.5 ============ This release comes with a number of enhancements and some bug fixes. Most notably, the automated referee is improved to prevent many agents to collide with each other which is required for running games with more players. Also, to better suite the field for running 9 vs 9 games, the field size is increased and it is 21x14 now. There are some visual improvements and minor enhancements to improve the general experience with the simulator. Finally, simspark.rb is renamed to rcssserver3d.rb for more consistency. * New touch rules: The automated referee now enforces two new rules to better prevent crowding and a high number of collisions in 9 vs 9 games: - If an agent is in touch with more than 2 agents (including himself), and he wasn't in such a situation in the previous time step - which means he is the last to join the group - he is relocated outside of the field. However, if the number of opponents in the group are more than teammates, an unspecified opponent will be relocated instead. - If it is not clear which agent joined the group last, e.g. when 3 players were all separate at time t, but were all touching each other in time t + 1, an agent is chosen at random for relocation. * Other Enhancements: - Visual improvements in rcssmonitor3d: new field texture, colored team names and scores - Set different agent and monitor ports with --agent-port and --server-port - Bigger field size: 21x14 - Updated PDF documentation - Bug fixes, specially in the automated referee - New Trainer command (killsim) to terminate the simulator - Compilation fixes - Nao robots now sense visual information about field lines by default - Now you should change the value of enableRealTimeMode variable in rcssserver3d.rb if you want to turn off using real time mode Thanks to all MC members who contributed to this release, Hedayat Vatankhah RCSServer3D Maintenance Committee [1] http://sourceforge.net/projects/simspark/files ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Simspark Generic Physical MAS Simulator simspark-devel mailing list sim...@li... https://lists.sourceforge.net/lists/listinfo/simspark-devel |
|
From: Hedayat V. <hed...@gm...> - 2011-04-27 06:41:15
|
Dear all,
Finally, simspark 0.2.2 and rcssserver3d 0.6.5 are released! You can
download them from [1]. These packages include a number of bug fixes and
improvements since the pre-release versions. Most notably, simspark
includes some bug fixes for log playback and a small fix in network
communication. The latter can affect teams which spend too much time
when thinking. Previously, such agents could slow down the simulator;
but in this release such agents will lose some cycles if they don't
receive simulator's messages on time.
RCSSServer3D includes some changes too: thanks to the initial patch by
Luis (FC Portugal), and the code to geometrically calculate where the
ball has crossed the goal line by Mehdi (Zigorat/Halcyon), rcssserver3d
should be able to count all goals correctly now. Hopefully, it should
not miss any goals any longer (However, it seems that rcssmonitor might
sometimes fail to update the goal count on the screen). Another patch
was submitted by Mehdi (IIRC) from Nexus3D. With this change, when too
much players are in touch with each other and the number of opponents in
the group are more than the number of teammates of the last player to
joint the group; a member of the opponent team is relocated outside the
field instead of him. Thanks to all for their contribution.
Like most simultaneous releases, please note that rcssserver3d 0.6.5
requires simspark 0.2.2 and will *not* work with previous versions of
simspark. Therefore, you should install simspark 0.2.2 and then
rcssserver3d 0.6.5. It is highly recommended to remove previous versions
of simspark and rcssserver3d before installing the latest versions.
Also, remove your ~/.simspark directory before running the latest
version. Notice that, since simspark 0.2.2, spark.rb is copied to
~/.simspark in the first run, and ~/.simspark/spark.rb is used in
subsequent runs. So, if you want to change anything in spark.rb you
should apply it to ~/.simspark/spark.rb rather than what is installed
along the simulator (It is highly recommended to limit our your changes
to ~/.simspark anyway: e.g. if you want to modify rcssserver3d.rb, copy
it to ~/.simspark and apply your changes there).
More detailed release notes of rcssserver3d and simspark follows:
SimSpark 0.2.2
=========
This release features many small enhancements which will benefit users.
It contains many bug fixes and performance improvements, in addition to
fixing some compilation issues. The behavior of ACC perceptor has been
slightly
changed, and the multi-threaded mode should work without any known bugs.
Support for the camera sensor is improved too. More details are as follows:
- ACC sensor provides raw data without any pre-processing
-- You can apply the following filter to 'RawACC' value received from the
simulator to get ACC value as what you'd receive in previous versions:
ACC = 0.9 * ACC + (0.1) * RawACC
- Using base64 encoding for camera perceptor
- Fixed bugs in multi-threaded mode.
- Compilation fixes
- HingePerceptor can report torque
- Better Performance
- New timing system result in more cleaner code and prevent wasting CPU time
- Do not block on sending data to clients. Previously, simulator would
block on
send() until it can send all data to clients.
RCSSServer3D 0.6.5
============
This release comes with a number of enhancements and some bug fixes. Most
notably, the automated referee is improved to prevent many agents to collide
with each other which is required for running games with more players.
Also, to
better suite the field for running 9 vs 9 games, the field size is increased
and it is 21x14 now. There are some visual improvements and minor
enhancements
to improve the general experience with the simulator. Finally,
simspark.rb is
renamed to rcssserver3d.rb for more consistency.
* New touch rules:
The automated referee now enforces two new rules to better prevent
crowding and
a high number of collisions in 9 vs 9 games:
- If an agent is in touch with more than 2 agents (including himself),
and he
wasn't in such a situation in the previous time step - which means he
is the
last to join the group - he is relocated outside of the field. However, if
the number of opponents in the group are more than teammates, an
unspecified
opponent will be relocated instead.
- If it is not clear which agent joined the group last, e.g. when 3 players
were all separate at time t, but were all touching each other in time
t + 1,
an agent is chosen at random for relocation.
* Other Enhancements:
- Visual improvements in rcssmonitor3d: new field texture, colored team
names
and scores
- Set different agent and monitor ports with --agent-port and --server-port
- Bigger field size: 21x14
- Updated PDF documentation
- Bug fixes, specially in the automated referee
- New Trainer command (killsim) to terminate the simulator
- Compilation fixes
- Nao robots now sense visual information about field lines by default
- Now you should change the value of enableRealTimeMode variable in
rcssserver3d.rb if you want to turn off using real time mode
Thanks to all MC members who contributed to this release,
Hedayat Vatankhah
RCSServer3D Maintenance Committee
[1] http://sourceforge.net/projects/simspark/files
|
|
From: Hedayat V. <hed...@gm...> - 2011-04-21 15:57:35
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
Hi all,<br>
Recently I had applied some small changes that I thought are
required for this release. These include: (hopefully) fixing the
goal counting bug in the simulator (still, there might be times that
the monitor doesn't show the current score; but the server should
have the correct goal count) and applied a change which is supposed
to remove a player from the opponent team when the number of
opponents in a touch group is more than the number of teammates of
the last player who has joined the group.<br>
Finally, I had a look at networking part and found out that
simulator blocks on send(), and I've fixed it. Now, agents might
miss some messages if they don't receive messages on time.<br>
<br>
It'd be nice if you can test the latest SVN head. Also, if you have
planned any minor changes for this release please let us know. If
not, I will probably release the next version in 2 days.<br>
<br>
Thanks,<br>
Hedayat<br>
</body>
</html>
|
|
From: Hedayat V. <hed...@gm...> - 2011-03-27 22:03:16
|
Hi ritter liu, Thank you for reporting the issue. Both issues (black screen and the crash) have been (hopefully) solved in the current SVN head and will be available in the final release. Thanks, Hedayat /*ritter liu <rit...@gm...>*/ wrote on 03/27/2011 8:53:52 AM +0450: > Hi,all: > Sorry for disturbing again. > Is there anybody who try to use the 'rcssmonitor' command? Can you use > it successfully? > > After I do > �/usr/local/share/rcssserver3d/rcssserver3d.rb > $recordLogfile = true > > And then I have a match,after that ,I run 'rcssmonitor3d� --logfile > sparkmonitor.log' > > In ubuntu10.10(32) > the monitor show up ,and the time goes,but only with dark > screen,without any pictures. > > In Fedora14(64) > the monitor show up for a while,then shut down.And I get errors below: > /////////////////////////////////////////////////////////////////// > (MonitorServer) WARNING: SimulationServer not found. > rcssmonitor3d, 0.2 > Koblenz University. > Copyright (C) 2004, The RoboCup Soccer Server Maintenance Group. > > Type '--help' for further information > > (spark.rb) sparkSetupRendering > (spark.rb) using OpenGLSystem 'OpenGLSystemSDL' > (OpenGLServer) Init OpenGLSystemSDL > (OpenGLSystemSDL) Initialized OpenGL Window > (spark.rb) sparkSetupInput > (spark.rb) using InputSystem 'InputSystemSDL' > (SimulationServer) SimControlNode 'RenderControl' registered > (InputServer) Init InputSystemSDL > (InputServer) CreateDevice Keyboard > (InputServer) CreateDevice Mouse > (spark.rb) sparkSetupTimer > (spark.rb) using TimerSystem 'TimerSystemBoost' > (SimulationServer) SimControlNode 'InputControl' registered > (SimulationServer) TimerSystem 'TimerSystemBoost' registered > (spark.rb) sparkAddFPSCamera at /usr/scene/camera > (bindings.rb) setting up bindings > (soccerbindings.rb) setting up bindings > setting bindings for logplayer > > (Font) WARNING: Init font: skipping character no. 124 > ERROR: (SoccerRender) Unable to get SoccerInput > (spark.rb) sparkEnableLog logTarget=:cerr logType=eAll > (ScriptServer) updating cached script variables > (ScriptServer) updating cached script variables > (SimulationServer) init > (SimulationServer) entering runloop > (Core) caught signal 11 > (Core) dumping 16 stack frames. > [0] > /usr/local/lib/simspark/libzeitgeist.so.3(zeitgeist::Core::CatchSignal(int)+0xd0) > [0x7fd703e0bb30] > ?? > ??:0 > > [1] /lib64/libc.so.6() [0x345da33140] > ?? > ??:0 > > [2] /usr/lib64/libstdc++.so.6(__dynamic_cast+0x23) [0x3464ab8a23] > ?? > ??:0 > > [3] > /usr/local/lib/simspark/rubysceneimporter.so(boost::shared_ptr<oxygen::BaseNode> > boost::shared_dynamic_cast<oxygen::BaseNode, > zeitgeist::Leaf>(boost::shared_ptr<zeitgeist::Leaf> const&)+0x2b) > [0x7fd70193508b] > ?? > ??:0 > > [4] > /usr/local/lib/simspark/rubysceneimporter.so(RubySceneImporter::ReadDeltaGraph(elt*, > boost::shared_ptr<oxygen::BaseNode>)+0x3d2) [0x7fd701933e92] > ?? > ??:0 > > [5] > /usr/local/lib/simspark/rubysceneimporter.so(RubySceneImporter::ReadDeltaGraph(elt*, > boost::shared_ptr<oxygen::BaseNode>)+0x2e7) [0x7fd701933da7] > ?? > ??:0 > > [6] > /usr/local/lib/simspark/rubysceneimporter.so(RubySceneImporter::ParseScene(char > const*, int, boost::shared_ptr<oxygen::BaseNode>, > boost::shared_ptr<zeitgeist::ParameterList>)+0x24b) [0x7fd701934a7b] > ?? > ??:0 > > [7] > /usr/local/lib/simspark/rubysceneimporter.so(RubySceneImporter::ParseScene(std::basic_string<char, > std::char_traits<char>, std::allocator<char> > const&, > boost::shared_ptr<oxygen::BaseNode>, > boost::shared_ptr<zeitgeist::ParameterList>)+0x96) [0x7fd70192bad6] > ?? > ??:0 > > [8] > /usr/local/lib/simspark/sparkmonitor.so(SparkMonitorLogFileServer::ParseMessage(std::basic_string<char, > std::char_traits<char>, std::allocator<char> > const&)+0x1ed) > [0x7fd7012dcc9d] > ?? > ??:0 > > [9] > /usr/local/lib/simspark/sparkmonitor.so(SparkMonitorLogFileServer::StartCycle()+0x106) > [0x7fd7012dd2f6] > ?? > ??:0 > > [10] > /usr/local/lib/simspark/liboxygen.so.5(oxygen::SimulationServer::ControlEvent(oxygen::SimulationServer::EControlEvent)+0x21c) > [0x7fd703b8744c] > ?? > ??:0 > > [11] > /usr/local/lib/simspark/liboxygen.so.5(oxygen::SimulationServer::Cycle()+0x1a) > [0x7fd703b8762a] > ?? > ??:0 > > [12] > /usr/local/lib/simspark/liboxygen.so.5(oxygen::SimulationServer::Run(int, > char**)+0xac) [0x7fd703b8a8dc] > ?? > ??:0 > > [13] rcssmonitor3d(main+0xc0) [0x402440] > main > ??:0 > > [14] /lib64/libc.so.6(__libc_start_main+0xfd) [0x345da1ee5d] > ?? > ??:0 > > [15] rcssmonitor3d() [0x4016a9] > _start > ??:0 > > (Core) exit > /////////////////////////////////////////////////////// > please help,Thank you so much. > > Best Regards, > ritter liu > |
|
From: Sander v. D. <sgv...@gm...> - 2011-03-27 03:06:37
|
Try removing the .simspark directory in your home dir. Sander On Sat, Mar 26, 2011 at 10:41 PM, ritter liu <rit...@gm...> wrote: > Hi,all: > After I 'make uninstall' the old simspark and rcssserver3d > I install the new one. > But when I run 'rcsoccersim3d',the monitor just show up for a while,then > shut down. > I get errors below,please help: > > ////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////// > (MonitorServer) WARNING: SimulationServer not found. > rcssserver3d (formerly simspark), a monolithic simulator 0.6.5 > Copyright (C) 2004 Markus Rollmann, > Universität Koblenz. > Copyright (C) 2004-2009, The RoboCup Soccer Server Maintenance Group. > > Type '--help' for further information > > (SimulationServer) SimControlNode 'AgentControl' registered > (AgentControl) Running in normal mode. > (spark.rb) sparkSetupInput > (spark.rb) using InputSystem 'InputSystemSDL' > (InputServer) Init InputSystemSDL > (InputServer) CreateDevice Timer > (InputServer) CreateDevice Keyboard > (InputServer) CreateDevice Mouse > (SimulationServer) SimControlNode 'InputControl' registered > (ScriptServer) ERROR: Unknown function 'sparkSetupTimer' > (bindings.rb) setting up bindings > (spark.rb) sparkEnableLog logTarget=:cerr logType=eError > (Light) ERROR: OpenGLServer not found > (Light) ERROR: OpenGLServer not found > (Material2DTexture) ERROR: cannot find TextureServer > (Material2DTexture) ERROR: OpenGLServer not found. > (Material2DTexture) ERROR: cannot find TextureServer > (Material2DTexture) ERROR: OpenGLServer not found. > (Material2DTexture) ERROR: cannot find TextureServer > (Material2DTexture) ERROR: OpenGLServer not found. > (Material2DTexture) ERROR: cannot find TextureServer > (Material2DTexture) ERROR: OpenGLServer not found. > (Material2DTexture) ERROR: cannot find TextureServer > (Material2DTexture) ERROR: OpenGLServer not found. > (Material2DTexture) ERROR: cannot find TextureServer > (Material2DTexture) ERROR: OpenGLServer not found. > (Material2DTexture) ERROR: cannot find TextureServer > (Material2DTexture) ERROR: OpenGLServer not found. > (Material2DTexture) ERROR: cannot find TextureServer > (Material2DTexture) ERROR: OpenGLServer not found. > (Material2DTexture) ERROR: cannot find TextureServer > (Material2DTexture) ERROR: OpenGLServer not found. > (Material2DTexture) ERROR: cannot find TextureServer > (Material2DTexture) ERROR: OpenGLServer not found. > (InputControl) ERROR: no FPSController found at > '/usr/scene/camera/physics/controller' > (SimulationServer) ERROR: can not get any TimerSystem objects. > (MonitorServer) WARNING: SimulationServer not found. > rcssmonitor3d, 0.2 > Koblenz University. > Copyright (C) 2004, The RoboCup Soccer Server Maintenance Group. > > Type '--help' for further information > > (spark.rb) sparkSetupRendering > (spark.rb) using OpenGLSystem 'OpenGLSystemSDL' > (OpenGLServer) Init OpenGLSystemSDL > (OpenGLSystemSDL) Initialized OpenGL Window > (spark.rb) sparkSetupInput > (spark.rb) using InputSystem 'InputSystemSDL' > (SimulationServer) SimControlNode 'RenderControl' registered > (InputServer) Init InputSystemSDL > (InputServer) CreateDevice Timer > (InputServer) CreateDevice Keyboard > (InputServer) CreateDevice Mouse > (SimulationServer) SimControlNode 'InputControl' registered > (ScriptServer) ERROR: Unknown function 'sparkSetupTimer' > (spark.rb) sparkAddFPSCamera at /usr/scene/camera > (bindings.rb) setting up bindings > (soccerbindings.rb) setting up bindings > setting bindings for online monitor > > (Font) WARNING: Init font: skipping character no. 124 > (spark.rb) sparkEnableLog logTarget=:cerr logType=eAll > (ScriptServer) updating cached script variables > (ScriptServer) updating cached script variables > (SimulationServer) init > (NetClient) 'SparkMonitorClient'connecting to TCP 127.0.0.1:3200 > (NetClient::SendMessage) ERROR: send returned error 'Broken pipe' > (SimulationServer) entering runloop > (SimulationServer) ERROR: can not get any TimerSystem objects. > (NetClient) 'SparkMonitorClient' closed connection to 127.0.0.1:3200 > (SimulationServer) leaving runloop at t=0 > Average FPS: -nan > kill: 65: No such process > > /////////////////////////////////////////////////////////////////////////////////////////// > Ps:I have install on a computer successfully with the same way,but I don't > know why it doesn't work in this computer. > Both of them are ubuntu10.10(32). > Please help.Thank you so much. > > Best Regards, > ritter liu > > > 2011/3/26 Hedayat Vatankhah <hed...@gm...> > >> Hi all, >> You can find the pre-release version of both simspark-0.2.2 and >> rcssserver3d-0.6.5 at [1]. These packages will become the final release >> if there work fine and have no unexpected problems. Please try them and >> let us know if there are any problems. >> >> As always, it is recommended to remove the older version of both >> packages before installing the new ones. Notice that rcssserver3d-0.6.5 >> doesn't work with older versions of simspark. >> >> Good luck, >> Hedayat >> On behalf of Maintenance Committee >> RoboCup 3D Soccer Simulation >> >> >> [1] http://hedayat.fedorapeople.org/misc/ >> >> >> ------------------------------------------------------------------------------ >> Enable your software for Intel(R) Active Management Technology to meet the >> growing manageability and security demands of your customers. Businesses >> are taking advantage of Intel(R) vPro (TM) technology - will your software >> be a part of the solution? Download the Intel(R) Manageability Checker >> today! http://p.sf.net/sfu/intel-dev2devmar >> _______________________________________________ >> Sserver-three-d mailing list >> Sse...@li... >> https://lists.sourceforge.net/lists/listinfo/sserver-three-d >> > > > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Sserver-three-d mailing list > Sse...@li... > https://lists.sourceforge.net/lists/listinfo/sserver-three-d > > -- Adaptive Systems Research Group Department of Computer Science University of Hertfordshire United Kingdom |
|
From: Hedayat V. <hed...@gm...> - 2011-03-26 15:24:04
|
Hi all, You can find the pre-release version of both simspark-0.2.2 and rcssserver3d-0.6.5 at [1]. These packages will become the final release if there work fine and have no unexpected problems. Please try them and let us know if there are any problems. As always, it is recommended to remove the older version of both packages before installing the new ones. Notice that rcssserver3d-0.6.5 doesn't work with older versions of simspark. Good luck, Hedayat On behalf of Maintenance Committee RoboCup 3D Soccer Simulation [1] http://hedayat.fedorapeople.org/misc/ |
|
From: Sander v. D. <sgv...@gm...> - 2011-03-26 02:21:09
|
Hey Hedayat, The RELEASE files seem good to me. I will also try to update the ChangeLog with my changes, though I'm swamped by other things atm (like qualification, and locked myself outside of my office with my computer.. ;), and if you want I think you can go ahead and make the release. Sander On Wed, Mar 23, 2011 at 5:51 AM, Hedayat Vatankhah <hed...@gm...>wrote: > Hi all, > As we are going to have a new release very soon, I've updated RELEASE files > of simspark(will be committed in a few minutes) and rcssserver3d. Please > read them and edit them as you see appropriate. Specially I might have > missed some changes of Yuan and Sander. I have tried my best to extract > changes from ChangeLog and SVN log, but I might have missed some points. > > Thanks > Hedayat > > > ------------------------------------------------------------------------------ > Enable your software for Intel(R) Active Management Technology to meet the > growing manageability and security demands of your customers. Businesses > are taking advantage of Intel(R) vPro (TM) technology - will your software > be a part of the solution? Download the Intel(R) Manageability Checker > today! http://p.sf.net/sfu/intel-dev2devmar > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > > -- Adaptive Systems Research Group Department of Computer Science University of Hertfordshire United Kingdom |
|
From: Sander v. D. <sgv...@gm...> - 2011-03-21 23:40:32
|
Hey all, I have committed the extended rules. The way they work: - 'touch groups' are created. A touch group is a group of agents that touch each other (either directly, or through other agents in the same touch group). These are similar to ODE's 'islands'. - If an agent is in a touch group with more than 2 agents (including himself), and he wasn't in a group the timestep before, which means he is the last to join the group, he is relocated outside of the field. - If it is not clear which agent joined the group last, e.g. when 3 players were all separate at time t, but were all touching each other in time t + 1, an agent is chosen at random. This seems to work well enough, though two things I am not sure about: - Relocating the agents completely outside of the field fits the other rules, may be a bit harsh? Perhaps just beaming them FreeKickDist meters away would be enough. Although that could be a beneficial/defensive position. - The way it currently works, agents will not be relocated when several touch groups join, e.g there are 2 touch groups of two, that in the next timestep form a touch group of 4. However, I am not able to produce such a situation and think it will be really unlikely. Also, I don't have a good intuition which agent to throw away in such a case anyway. Sander On Mon, Mar 21, 2011 at 3:40 PM, Hedayat Vatankhah <hed...@gm...>wrote: > Hi Sander, > Thank you for the reminder :P. I'll try to do some tests in the mean time. > > Thanks > Hedayat > > *Sander van Dijk <sgv...@gm...> <sgv...@gm...>* wrote on > 03/21/2011 8:15:30 AM +0350: > > Hey, to keep you posted, I am implementing a new touching rule as we have > discussed: if 2 are touching and a third joins, he is moved away. I think I > have a working setup for this, just fighting with boost 'smart' pointers > (apparently smarter than I am). Hope to have a working version in the > repository tomorrow. > > Sander > > On Sat, Mar 19, 2011 at 6:41 AM, Hedayat Vatankhah <hed...@gm...>wrote: > >> Hi all, >> We should release a new version of simspark/rcssserver3d very soon. Please >> check the latest SVN and let us know if there are any problems. It'd be nice >> if you can test with the multi-threaded ODE prepared by Sander. >> >> Thanks >> Hedayat >> >> >> ------------------------------------------------------------------------------ >> Colocation vs. Managed Hosting >> A question and answer guide to determining the best fit >> for your organization - today and in the future. >> http://p.sf.net/sfu/internap-sfd2d >> _______________________________________________ >> Simspark Generic Physical MAS Simulator >> simspark-devel mailing list >> sim...@li... >> https://lists.sourceforge.net/lists/listinfo/simspark-devel >> >> > > > -- > Adaptive Systems Research Group > Department of Computer Science > University of Hertfordshire > United Kingdom > > -- Adaptive Systems Research Group Department of Computer Science University of Hertfordshire United Kingdom |
|
From: Sander v. D. <sgv...@gm...> - 2011-03-21 04:45:37
|
Hey, to keep you posted, I am implementing a new touching rule as we have discussed: if 2 are touching and a third joins, he is moved away. I think I have a working setup for this, just fighting with boost 'smart' pointers (apparently smarter than I am). Hope to have a working version in the repository tomorrow. Sander On Sat, Mar 19, 2011 at 6:41 AM, Hedayat Vatankhah <hed...@gm...>wrote: > Hi all, > We should release a new version of simspark/rcssserver3d very soon. Please > check the latest SVN and let us know if there are any problems. It'd be nice > if you can test with the multi-threaded ODE prepared by Sander. > > Thanks > Hedayat > > > ------------------------------------------------------------------------------ > Colocation vs. Managed Hosting > A question and answer guide to determining the best fit > for your organization - today and in the future. > http://p.sf.net/sfu/internap-sfd2d > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel > > -- Adaptive Systems Research Group Department of Computer Science University of Hertfordshire United Kingdom |
|
From: Hedayat V. <hed...@gm...> - 2011-03-19 10:42:06
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html style="direction: ltr;">
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body style="direction: ltr;" bgcolor="#ffffff" text="#000000">
Hi all,<br>
We should release a new version of simspark/rcssserver3d very soon.
Please check the latest SVN and let us know if there are any
problems. It'd be nice if you can test with the multi-threaded ODE
prepared by Sander.<br>
<br>
Thanks<br>
Hedayat<br>
</body>
</html>
|
|
From: saeid j. z. <kam...@gm...> - 2011-03-09 17:48:23
|
Hi Hedayat , I refer to the "soft tissue" for an important relative issue: a "grass field" is similar to the "soft surface" in several parameters. However, I will search more about it to find a component, project such as ODE or etc. I don't work in simulation designing filed, but i will make every effort to help you to improving the simulator. Regards Saeid On Wed, Mar 9, 2011 at 1:54 AM, Hedayat Vatankhah <hed...@gm...>wrote: > Hi Saeid, > Working on diversity in robots' properties is good, but it would be also > interesting if we can use a more natural field (a grass field) instead of > the current one. I wonder if ODE can provide such simulation by itself, or > if there exists a good model for a real soccer field; but it would be nice > if we can have such a field in our simulator. Also, we would really > appreciate if someone can help us in improving the simulator. Can you > provide more details on this issue and maybe even start implementing it in > the simulator? > > Thanks, > Hedayat > > > *saeid jaffari zadeh <kam...@gm...> <kam...@gm...>*wrote on 03/07/2011 10:22:17 PM +0350: > > Hi All, > We know that the 3D league has been extended enough and the early problems > (such as walk,turn and etc.) has been solved now. > We can work with environment parameters and its features instead of robot > features, I have a idea for developing environment,� > "*We can�use the soft surface instead of smooth surface for soccer field.* > " > This idea can be implemented using statical parameters or mathematical > parameters . > This issue has been discussed in surgery field previously, for simulation > the soft tissue part of a human body .�I think that it can be useful for > implementation.� > What is your opinion? > � > > > |
|
From: Hedayat V. <hed...@gm...> - 2011-03-08 22:24:45
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Saeid,<br>
Working on diversity in robots' properties is good, but it would be
also interesting if we can use a more natural field (a grass field)
instead of the current one. I wonder if ODE can provide such
simulation by itself, or if there exists a good model for a real
soccer field; but it would be nice if we can have such a field in
our simulator. Also, we would really appreciate if someone can help
us in improving the simulator. Can you provide more details on this
issue and maybe even start implementing it in the simulator?<br>
<br>
Thanks,<br>
Hedayat<br>
<br>
<br>
<span>
<style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;} blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important} blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important} blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important} blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>saeid
jaffari zadeh <a class="moz-txt-link-rfc2396E"
href="mailto:kam...@gm..."><kam...@gm...></a></b></i>
wrote on 03/07/2011 10:22:17 PM +0350:</span><br>
<blockquote style="color: navy; background-color: rgb(245, 245,
245); padding-left: 15px; border-left: 2px solid rgb(16, 16,
255);"
cite="mid:AANLkTin+K7gtK_TvaizfvrH66CubZ=NT-...@ma..."
type="cite">
<div>Hi All,</div>
<div>We know that the 3D league has been extended enough and the
early problems (such as walk,turn and etc.) has been solved now.</div>
<div>We can work with environment parameters and its features
instead of robot features, I have a idea for developing
environment,�</div>
<div>"<u>We can�use the soft surface instead of smooth surface for
soccer field.</u>"</div>
<div>This idea can be implemented using statical parameters or
mathematical parameters .</div>
<div>This issue has been discussed in surgery field previously,
for simulation the soft tissue part of a human body .�I think
that it can be useful for implementation.� <br>
What is your opinion?<br>
</div>
<div>�</div>
<pre wrap=""><fieldset class="mimeAttachmentHeader"></fieldset></pre>
<br>
</blockquote>
</body>
</html>
|
|
From: saeid j. z. <kam...@gm...> - 2011-03-07 18:52:26
|
Hi All, We know that the 3D league has been extended enough and the early problems (such as walk,turn and etc.) has been solved now. We can work with environment parameters and its features instead of robot features, I have a idea for developing environment, "*We can use the soft surface instead of smooth surface for soccer field.*" This idea can be implemented using statical parameters or mathematical parameters . This issue has been discussed in surgery field previously, for simulation the soft tissue part of a human body . I think that it can be useful for implementation. What is your opinion? |
|
From: Hedayat V. <hed...@gm...> - 2011-03-05 19:41:40
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Sander,<br>
<br>
<span>
<style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;} blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important} blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important} blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important} blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>Sander
van Dijk <a class="moz-txt-link-rfc2396E"
href="mailto:sgv...@gm..."><sgv...@gm...></a></b></i>
wrote on 03/02/2011 9:11:10 PM +0350:</span><br>
<blockquote style="color: navy; background-color: rgb(245, 245,
245); padding-left: 15px; border-left: 2px solid rgb(16, 16,
255);"
cite="mid:AAN...@ma..."
type="cite">Hey guys,
<div><br>
</div>
<div>Another update: currently, with the ODE version I put now at
my page [1], and current SVN head of rcssserver3d, I am able to
run 9 vs 9 in real time on my i7 740QM laptop, with the agents
and monitor also running on the same machine. Having said that:</div>
</blockquote>
First, thanks a lot for making us informed about your progress.
Unfortunately I was a little busy these days and unable to follow
you fast enough :)<br>
It's great to hear about the results so far, and I'm really happy to
hear that the work of Hesham was not wasted. <br>
<br>
<br>
<blockquote style="color: navy; background-color: rgb(245, 245,
245); padding-left: 15px; border-left: 2px solid rgb(16, 16,
255);"
cite="mid:AAN...@ma..."
type="cite">
<div><br>
</div>
<div>- This is when the number of collisions is not too high.
Because of the extra constraints and the fact that they result
in agents being put into 1 one island, collisions are even worse
in multithreaded version. The select-and-move functionality of
RoboViz comes in quite handy here, but it's still a pain.</div>
</blockquote>
Is this a considerable issue even with the current automatic
referee? Are all agents able to collide with each other even with
this referee?<br>
<br>
<blockquote style="color: navy; background-color: rgb(245, 245,
245); padding-left: 15px; border-left: 2px solid rgb(16, 16,
255);"
cite="mid:AAN...@ma..."
type="cite">
<div>- Even worse: with many collisions ODE crashes. This seems to
be a memory issue, probably because ODE allocates everything on
the stack and runs out of space there. Indeed, configuring ODE
with -DdUSE_MALLOC_FOR_ALLOCA seems to prevent this issue by
using the heap instead. However, using the stack frequently is
suboptimal for multithreading, it might be worth it looking into
TBB's options to increase thread stack size.</div>
</blockquote>
We might be able to use a custom memory allocator too. So that we
can allocate a big block of memory from heap and assign it to ode in
an efficient manner. However, I don't know how ODE uses memory so my
suggestion might not be very practical.<br>
<br>
<blockquote style="color: navy; background-color: rgb(245, 245,
245); padding-left: 15px; border-left: 2px solid rgb(16, 16,
255);"
cite="mid:AAN...@ma..."
type="cite">
<div>- Multithreading in Simspark is still sometimes unstable, s
with 18 agents, eemingly on the communication/predicate
generation/parsing side. Looking into that (after the rather
enjoying 18 robot wrestling match currently going on on my
screen ;)</div>
</blockquote>
About the communication part, I'm going to take this issue very
seriously soon. <br>
<br>
Thanks,<br>
Hedayat<br>
<br>
<blockquote style="color: navy; background-color: rgb(245, 245,
245); padding-left: 15px; border-left: 2px solid rgb(16, 16,
255);"
cite="mid:AAN...@ma..."
type="cite">
<div><br>
</div>
<div>Sander</div>
<div><br>
</div>
<div><br>
<div class="gmail_quote">On Wed, Feb 23, 2011 at 7:43 PM, Sander
van Dijk <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sgv...@gm...">sgv...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div class="im">Hey all,<br>
<br>
I have worked on multithreading ODE. First of all thanks
for sending me Hesham Ebrahimi's work. He took basically
the same approach as I had, so it confirmed my ideas and
it helped identifying and verifying problematic places. I
also adopted his use if Intel's Thread Building Blocks
library. It is quite helpful; simple as OpenMP, but
doesn't respawn threads, which I ran into at my first
attempt. My implementation is slightly different, to make
sure that all tasks are created before spawning any of
them, which can be an issue when small tasks (like
stepping the ball) finish fast.<br>
<br>
</div>
I have uploaded the current result at[1]. Using it I got
similar results as Hesham with the same test he, i.e.
significantly less cpu cycles spent doing the world
stepping. However, although I double checked each part
multiple times, the physics seem a little less stable.
During most runs it is fine, but at some, especially with a
lot of agents, one blows up and the server crashes. I am
still digging into it, It is hard to reproduce, and not sure
yet if the multi threading makes it worse, but if any of you
want to do some test runs and see how it works for you, that
may help. Especially if it does blow up and you see a
pattern in when it happens.<br>
<br>
Thanks all,<br>
<font color="#888888"><br>
Sander<br>
</font><br>
[1] <a moz-do-not-send="true"
href="http://homepages.feis.herts.ac.uk/%7Esv08aav/ode-0.11.1-tbb.tar.gz"
target="_blank">http://homepages.feis.herts.ac.uk/~sv08aav/ode-0.11.1-tbb.tar.gz</a>
<div class="im"> <br>
<br>
PS don't forget to install tbb dev packages (though
configure should warn you about that too) and remake and
install simspark<br>
PS2 gmail won't let me tar.gz, that's why it's targz<br>
<br>
</div>
<div>
<div> </div>
<div class="h5">
<div class="gmail_quote"> On Wed, Feb 23, 2011 at 7:20
PM, Sander van Dijk <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:sgv...@gm..." target="_blank">sgv...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt
0pt 0.8ex; border-left: 1px solid rgb(204, 204,
204); padding-left: 1ex;"> Hey all,<br>
<br>
I have worked on multithreading ODE. First of all
thanks for sending me Hesham Ebrahimi's work. He
took basically the same approach as I had, so it
confirmed my ideas and it helped identifying and
verifying problematic places. I also adopted his use
if Intel's Thread Building Blocks library. It is
quite helpful; simple as OpenMP, but doesn't respawn
threads, which I ran into at my first attempt. My
implementation is slightly different, to make sure
that all tasks are created before spawning any of
them, which can be an issue when small tasks (like
stepping the ball) finish fast.<br>
<br>
I have attached the current result here. Using it I
got similar results as Hesham with the same test he,
i.e. significantly less cpu cycles spent doing the
world stepping. However, although I double checked
each part multiple times, the physics seem a little
less stable. During most runs it is fine, but at
some, especially with a lot of agents, one blows up
and the server crashes. I am still digging into it,
It is hard to reproduce, and not sure yet if the
multi threading makes it worse, but if any of you
want to do some test runs and see how it works for
you, that may help. Especially if it does blow up
and you see a pattern in when it happens.<br>
<br>
Thanks all,<br>
<font color="#888888"><br>
Sander<br>
</font><br>
PS don't forget to install tbb dev packages (though
configure should warn you about that too) and remake
and install simspark<br>
PS2 gmail won't let me tar.gz, that's why it's targz
<div>
<div><br>
<br>
<div class="gmail_quote">On Sun, Feb 20, 2011 at
3:28 AM, Hedayat Vatankhah <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:hed...@gm..."
target="_blank">hed...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:
0pt 0pt 0pt 0.8ex; border-left: 1px solid
rgb(204, 204, 204); padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> Hi,<br>
<br>
On ۱۱/۰۲/۲۰ 09:06, Sander van Dijk wrote:
<blockquote type="cite">....
<div>
<div class="gmail_quote">
<div><br>
</div>
<div>Yes, good point. I will make
sure to record all test details.
For now: I am mostly using
valgrind (with the callgrind and
helgrind tools in specific). I
first tried gprof, but then
everything was very unstable, but
maybe that's helped with the
current fixes.</div>
</div>
</div>
</blockquote>
Thanks.<br>
<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204,
204); padding-left: 1ex;">
<div bgcolor="#ffffff"
text="#000000">...Also, Andreas
Seekircher has reported his
experience with multi-threaded
which also confirms that
multi-threaded mode is faster, but
also he has faced a problem which
deserves some attention:
<div><br>
<blockquote type="cite">However
there was a strange behavior,
that the simulation was
running quite fast on my
laptop with up to 9 agents and
the simulator was using more
than one core. When I started
the 10th agent it was getting
much slower and it seemed that
the simulator was then using
only one core (it was then
again the same speed like
without multi-threading). This
happened with 4 cores. On a
dual core system already the
5th agent slowed down the
simulation... Is this a known
issue? </blockquote>
I guess that in this situation,
ODE is the main bottleneck. But
that's just a guess.</div>
</div>
</blockquote>
<div>
<div><br>
</div>
<div>Yes, Andreas notified me of
that, too. This happens when
agents and server are run on the
same machine with multiple cores.I
have found that at some point, the
system's scheduler assigns an
agent to the same core as the
server (even though in practice
there is still room on another
core), so the server can't run at
full speed. With taskset(1) it is
possible to explicitly set a
process' CPU affinity, and by
starting the agents with e.g.
'taskset 2 ./start.sh localhost'
the server is able to take up 100%
again.</div>
</div>
</div>
</blockquote>
Great, thanks for the info. We might be
able to design a more general framework
for running agents using Linux CGroups and
maybe taking advantage of perf tools. But
I should investigate more before being
able to comment more on this issue.<br>
<br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204, 204,
204); padding-left: 1ex;">
<div bgcolor="#ffffff"
text="#000000">
<div>
<blockquote type="cite">...<br>
</blockquote>
</div>
<div> Great. But it'd be probably
nice if we parallelize the
collision detection too.
Specially, it's computation time
will increase considerably when
two or more robots collide
(fortunately the new referee
doesn't allow many robots to
collide at the same place, but
with more players it is more
likely that we'll have
collisions in different part of
the field).<br>
</div>
</div>
</blockquote>
<div>
<div><br>
</div>
<div>From what I can tell so far it
seems that the main part of the
speed reduction due to collisions
is not caused by the collision
detection, but by the fact that it
adds many new constraints to the
LCP problem that ODE solves to
step the physics. However, I still
have to make a team of robots that
just run into each other to be
able to say that with certainty.
And you are right, it would be
nice in any case ;) <br>
</div>
</div>
</div>
</blockquote>
Thanks for the clarification. Yes IIRC
solving the LCP problem was a real
bottleneck. If it doesn't worth the
effort, we might skip this part for now. <br>
<div> <br>
<br>
<blockquote type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204,
204, 204); padding-left: 1ex;">
<div bgcolor="#ffffff"
text="#000000">
<div>
<blockquote type="cite">So far
about what I am doing. Now,
I would also like something
from you guys ;-) First of
all, give the new stuff I
committed a good test.
Behaviour of the simulator
should still be the same,
but it could be that I
missed something and that
timing of messages is
slightly different, breaking
agents. Also, give the multi
threaded mode a good test,
see if you can make it
crash. And, finally, I will
be working full time on the
simulator for 1 1/2 months
more, if you think there is
anything that I may be able
to squeeze in there, do let
me know!<br>
</blockquote>
</div>
Certainly! :) <br>
I noticed something in your
recent commit: you've removed
the ugly busy-waiting loop in
SimControlThread, but wouldn't
it result in a faster simulation
when ODE has not much work to
do? The loop was there to make
sure that a cycle will last no
less than 0.02 (mSimStep). If
I'm not mistaken, it is now
possible for a cycle to finish
too soon. <br>
</div>
</blockquote>
<div><br>
</div>
<div>I think you refer to:</div>
<div>
<div><br>
</div>
<div> if
(isInputControl)</div>
<div> {</div>
<div> while
(int(mSumDeltaTime*100) <
int(mSimStep*100))</div>
<div>
controlNode->StartCycle();
// advance the time</div>
<div> }</div>
</div>
<div><br>
</div>
<div>? The only use I saw of that
was to keep updating the
InputControl to get messages from
the monitor while the physics are
updated. The time check is there
to stop doing this when the
physics are done. Without this
check, the InputControl (and the
other controls, AgentControl and
MonitorControl) wait for the
physics to be done anyway at the
next barrier, so the cycle can't
be finished too soon. And this
loop caused the most problems with
multi threading, because it
allowed the scene graph to be
changed while the physics were
still running on it.</div>
</div>
</blockquote>
</div>
Yes, I was referring to this loop.
Unfortunately InputControl doesn't exactly
do what it is supposed to. Beside handing
input, it also functions as the simulator
timer, which is very ambiguous (and I'm
going to replace it with another timer
implementation). This loop is not intended
to receive messages from the monitor
(you'll see the same loop in
SimulationServer::Cycle() which is run in
single threaded mode); it is a
busy-waiting loop to make sure that a
cycle will not last less than mSimStep. On
of the functions which
InputControl::StartCycle does is to
inspect SDL's timer and call
SimulationServer::AdvanceTime(), which in
turn updates mSumDeltaTime. Yes, doesn't
look good and was really problematic for
me to understand what happens completely
:P<br>
<br>
Personally, I'm planning to remove the use
of SDL timer altogether and switch to
using Boost's timing facilities, which is
much more cleaner and also doesn't need a
busy-waiting loop. <br>
<br>
Thanks,<br>
<font color="#888888"> Hedayat<br>
<br>
<br>
</font>
<blockquote type="cite">
<div>
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204,
204, 204); padding-left: 1ex;">
<div bgcolor="#ffffff"
text="#000000"> <br>
There are some collaboration
opportunities with your work and
what I'm planning to do, but
I'll talk about them in a
separate email soon.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Looking forward to it :)</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin: 0pt 0pt 0pt 0.8ex;
border-left: 1px solid rgb(204,
204, 204); padding-left: 1ex;">
<div bgcolor="#ffffff"
text="#000000"> <br>
Thanks,<br>
<font color="#888888"> Hedayat</font><br>
</div>
</blockquote>
</div>
</div>
-- <br>
<div> Adaptive Systems Research Group<br>
Department of Computer Science<br>
University of Hertfordshire<br>
United Kingdom<br>
</div>
</blockquote>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Adaptive Systems Research Group<br>
Department of Computer Science<br>
University of Hertfordshire<br>
United Kingdom<br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Adaptive Systems Research Group<br>
Department of Computer Science<br>
University of Hertfordshire<br>
United Kingdom<br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Adaptive Systems Research Group<br>
Department of Computer Science<br>
University of Hertfordshire<br>
United Kingdom<br>
</div>
</blockquote>
</body>
</html>
|
|
From: Sander v. D. <sgv...@gm...> - 2011-03-02 17:41:18
|
Hey guys, Another update: currently, with the ODE version I put now at my page [1], and current SVN head of rcssserver3d, I am able to run 9 vs 9 in real time on my i7 740QM laptop, with the agents and monitor also running on the same machine. Having said that: - This is when the number of collisions is not too high. Because of the extra constraints and the fact that they result in agents being put into 1 one island, collisions are even worse in multithreaded version. The select-and-move functionality of RoboViz comes in quite handy here, but it's still a pain. - Even worse: with many collisions ODE crashes. This seems to be a memory issue, probably because ODE allocates everything on the stack and runs out of space there. Indeed, configuring ODE with -DdUSE_MALLOC_FOR_ALLOCA seems to prevent this issue by using the heap instead. However, using the stack frequently is suboptimal for multithreading, it might be worth it looking into TBB's options to increase thread stack size. - Multithreading in Simspark is still sometimes unstable, s with 18 agents, eemingly on the communication/predicate generation/parsing side. Looking into that (after the rather enjoying 18 robot wrestling match currently going on on my screen ;) Sander On Wed, Feb 23, 2011 at 7:43 PM, Sander van Dijk <sgv...@gm...>wrote: > Hey all, > > I have worked on multithreading ODE. First of all thanks for sending me > Hesham Ebrahimi's work. He took basically the same approach as I had, so it > confirmed my ideas and it helped identifying and verifying problematic > places. I also adopted his use if Intel's Thread Building Blocks library. It > is quite helpful; simple as OpenMP, but doesn't respawn threads, which I ran > into at my first attempt. My implementation is slightly different, to make > sure that all tasks are created before spawning any of them, which can be an > issue when small tasks (like stepping the ball) finish fast. > > I have uploaded the current result at[1]. Using it I got similar results as > Hesham with the same test he, i.e. significantly less cpu cycles spent doing > the world stepping. However, although I double checked each part multiple > times, the physics seem a little less stable. During most runs it is fine, > but at some, especially with a lot of agents, one blows up and the server > crashes. I am still digging into it, It is hard to reproduce, and not sure > yet if the multi threading makes it worse, but if any of you want to do some > test runs and see how it works for you, that may help. Especially if it does > blow up and you see a pattern in when it happens. > > Thanks all, > > Sander > > [1] http://homepages.feis.herts.ac.uk/~sv08aav/ode-0.11.1-tbb.tar.gz > > > PS don't forget to install tbb dev packages (though configure should warn > you about that too) and remake and install simspark > PS2 gmail won't let me tar.gz, that's why it's targz > > On Wed, Feb 23, 2011 at 7:20 PM, Sander van Dijk <sgv...@gm...>wrote: > >> Hey all, >> >> I have worked on multithreading ODE. First of all thanks for sending me >> Hesham Ebrahimi's work. He took basically the same approach as I had, so it >> confirmed my ideas and it helped identifying and verifying problematic >> places. I also adopted his use if Intel's Thread Building Blocks library. It >> is quite helpful; simple as OpenMP, but doesn't respawn threads, which I ran >> into at my first attempt. My implementation is slightly different, to make >> sure that all tasks are created before spawning any of them, which can be an >> issue when small tasks (like stepping the ball) finish fast. >> >> I have attached the current result here. Using it I got similar results as >> Hesham with the same test he, i.e. significantly less cpu cycles spent doing >> the world stepping. However, although I double checked each part multiple >> times, the physics seem a little less stable. During most runs it is fine, >> but at some, especially with a lot of agents, one blows up and the server >> crashes. I am still digging into it, It is hard to reproduce, and not sure >> yet if the multi threading makes it worse, but if any of you want to do some >> test runs and see how it works for you, that may help. Especially if it does >> blow up and you see a pattern in when it happens. >> >> Thanks all, >> >> Sander >> >> PS don't forget to install tbb dev packages (though configure should warn >> you about that too) and remake and install simspark >> PS2 gmail won't let me tar.gz, that's why it's targz >> >> >> On Sun, Feb 20, 2011 at 3:28 AM, Hedayat Vatankhah <hed...@gm...>wrote: >> >>> Hi, >>> >>> On ۱۱/۰۲/۲۰ 09:06, Sander van Dijk wrote: >>> >>> .... >>> >>> Yes, good point. I will make sure to record all test details. For now: >>> I am mostly using valgrind (with the callgrind and helgrind tools in >>> specific). I first tried gprof, but then everything was very unstable, but >>> maybe that's helped with the current fixes. >>> >>> Thanks. >>> >>> >>> >>> ...Also, Andreas Seekircher has reported his experience with >>>> multi-threaded which also confirms that multi-threaded mode is faster, but >>>> also he has faced a problem which deserves some attention: >>>> >>>> However there was a strange behavior, that the simulation was running >>>> quite fast on my laptop with up to 9 agents and the simulator was using more >>>> than one core. When I started the 10th agent it was getting much slower and >>>> it seemed that the simulator was then using only one core (it was then again >>>> the same speed like without multi-threading). This happened with 4 cores. On >>>> a dual core system already the 5th agent slowed down the simulation... Is >>>> this a known issue? >>>> >>>> I guess that in this situation, ODE is the main bottleneck. But that's >>>> just a guess. >>>> >>> >>> Yes, Andreas notified me of that, too. This happens when agents and >>> server are run on the same machine with multiple cores.I have found that at >>> some point, the system's scheduler assigns an agent to the same core as the >>> server (even though in practice there is still room on another core), so the >>> server can't run at full speed. With taskset(1) it is possible to explicitly >>> set a process' CPU affinity, and by starting the agents with e.g. 'taskset >>> 2 ./start.sh localhost' the server is able to take up 100% again. >>> >>> Great, thanks for the info. We might be able to design a more general >>> framework for running agents using Linux CGroups and maybe taking advantage >>> of perf tools. But I should investigate more before being able to comment >>> more on this issue. >>> >>> >>> >>> ... >>>> >>>> Great. But it'd be probably nice if we parallelize the collision >>>> detection too. Specially, it's computation time will increase considerably >>>> when two or more robots collide (fortunately the new referee doesn't allow >>>> many robots to collide at the same place, but with more players it is more >>>> likely that we'll have collisions in different part of the field). >>>> >>> >>> From what I can tell so far it seems that the main part of the speed >>> reduction due to collisions is not caused by the collision detection, but by >>> the fact that it adds many new constraints to the LCP problem that ODE >>> solves to step the physics. However, I still have to make a team of robots >>> that just run into each other to be able to say that with certainty. And you >>> are right, it would be nice in any case ;) >>> >>> Thanks for the clarification. Yes IIRC solving the LCP problem was a real >>> bottleneck. If it doesn't worth the effort, we might skip this part for now. >>> >>> >>> >>> So far about what I am doing. Now, I would also like something from >>>> you guys ;-) First of all, give the new stuff I committed a good test. >>>> Behaviour of the simulator should still be the same, but it could be that I >>>> missed something and that timing of messages is slightly different, breaking >>>> agents. Also, give the multi threaded mode a good test, see if you can make >>>> it crash. And, finally, I will be working full time on the simulator for 1 >>>> 1/2 months more, if you think there is anything that I may be able to >>>> squeeze in there, do let me know! >>>> >>>> Certainly! :) >>>> I noticed something in your recent commit: you've removed the ugly >>>> busy-waiting loop in SimControlThread, but wouldn't it result in a faster >>>> simulation when ODE has not much work to do? The loop was there to make sure >>>> that a cycle will last no less than 0.02 (mSimStep). If I'm not mistaken, it >>>> is now possible for a cycle to finish too soon. >>>> >>> >>> I think you refer to: >>> >>> if (isInputControl) >>> { >>> while (int(mSumDeltaTime*100) < int(mSimStep*100)) >>> controlNode->StartCycle(); // advance the time >>> } >>> >>> ? The only use I saw of that was to keep updating the InputControl to >>> get messages from the monitor while the physics are updated. The time check >>> is there to stop doing this when the physics are done. Without this check, >>> the InputControl (and the other controls, AgentControl and MonitorControl) >>> wait for the physics to be done anyway at the next barrier, so the cycle >>> can't be finished too soon. And this loop caused the most problems with >>> multi threading, because it allowed the scene graph to be changed while the >>> physics were still running on it. >>> >>> Yes, I was referring to this loop. Unfortunately InputControl doesn't >>> exactly do what it is supposed to. Beside handing input, it also functions >>> as the simulator timer, which is very ambiguous (and I'm going to replace it >>> with another timer implementation). This loop is not intended to receive >>> messages from the monitor (you'll see the same loop in >>> SimulationServer::Cycle() which is run in single threaded mode); it is a >>> busy-waiting loop to make sure that a cycle will not last less than >>> mSimStep. On of the functions which InputControl::StartCycle does is to >>> inspect SDL's timer and call SimulationServer::AdvanceTime(), which in turn >>> updates mSumDeltaTime. Yes, doesn't look good and was really problematic for >>> me to understand what happens completely :P >>> >>> Personally, I'm planning to remove the use of SDL timer altogether and >>> switch to using Boost's timing facilities, which is much more cleaner and >>> also doesn't need a busy-waiting loop. >>> >>> Thanks, >>> Hedayat >>> >>> >>> >>> >>>> There are some collaboration opportunities with your work and what I'm >>>> planning to do, but I'll talk about them in a separate email soon. >>>> >>> >>> Looking forward to it :) >>> >>> >>>> >>>> Thanks, >>>> Hedayat >>>> >>> -- >>> Adaptive Systems Research Group >>> Department of Computer Science >>> University of Hertfordshire >>> United Kingdom >>> >>> >> >> >> -- >> Adaptive Systems Research Group >> Department of Computer Science >> University of Hertfordshire >> United Kingdom >> > > > > -- > Adaptive Systems Research Group > Department of Computer Science > University of Hertfordshire > United Kingdom > -- Adaptive Systems Research Group Department of Computer Science University of Hertfordshire United Kingdom |
|
From: Sander v. D. <sgv...@gm...> - 2011-02-24 00:43:59
|
Hey all, I have worked on multithreading ODE. First of all thanks for sending me Hesham Ebrahimi's work. He took basically the same approach as I had, so it confirmed my ideas and it helped identifying and verifying problematic places. I also adopted his use if Intel's Thread Building Blocks library. It is quite helpful; simple as OpenMP, but doesn't respawn threads, which I ran into at my first attempt. My implementation is slightly different, to make sure that all tasks are created before spawning any of them, which can be an issue when small tasks (like stepping the ball) finish fast. I have uploaded the current result at[1]. Using it I got similar results as Hesham with the same test he, i.e. significantly less cpu cycles spent doing the world stepping. However, although I double checked each part multiple times, the physics seem a little less stable. During most runs it is fine, but at some, especially with a lot of agents, one blows up and the server crashes. I am still digging into it, It is hard to reproduce, and not sure yet if the multi threading makes it worse, but if any of you want to do some test runs and see how it works for you, that may help. Especially if it does blow up and you see a pattern in when it happens. Thanks all, Sander [1] http://homepages.feis.herts.ac.uk/~sv08aav/ode-0.11.1-tbb.tar.gz PS don't forget to install tbb dev packages (though configure should warn you about that too) and remake and install simspark PS2 gmail won't let me tar.gz, that's why it's targz On Wed, Feb 23, 2011 at 7:20 PM, Sander van Dijk <sgv...@gm...>wrote: > Hey all, > > I have worked on multithreading ODE. First of all thanks for sending me > Hesham Ebrahimi's work. He took basically the same approach as I had, so it > confirmed my ideas and it helped identifying and verifying problematic > places. I also adopted his use if Intel's Thread Building Blocks library. It > is quite helpful; simple as OpenMP, but doesn't respawn threads, which I ran > into at my first attempt. My implementation is slightly different, to make > sure that all tasks are created before spawning any of them, which can be an > issue when small tasks (like stepping the ball) finish fast. > > I have attached the current result here. Using it I got similar results as > Hesham with the same test he, i.e. significantly less cpu cycles spent doing > the world stepping. However, although I double checked each part multiple > times, the physics seem a little less stable. During most runs it is fine, > but at some, especially with a lot of agents, one blows up and the server > crashes. I am still digging into it, It is hard to reproduce, and not sure > yet if the multi threading makes it worse, but if any of you want to do some > test runs and see how it works for you, that may help. Especially if it does > blow up and you see a pattern in when it happens. > > Thanks all, > > Sander > > PS don't forget to install tbb dev packages (though configure should warn > you about that too) and remake and install simspark > PS2 gmail won't let me tar.gz, that's why it's targz > > > On Sun, Feb 20, 2011 at 3:28 AM, Hedayat Vatankhah <hed...@gm...>wrote: > >> Hi, >> >> On ۱۱/۰۲/۲۰ 09:06, Sander van Dijk wrote: >> >> .... >> >> Yes, good point. I will make sure to record all test details. For now: I >> am mostly using valgrind (with the callgrind and helgrind tools in >> specific). I first tried gprof, but then everything was very unstable, but >> maybe that's helped with the current fixes. >> >> Thanks. >> >> >> >> ...Also, Andreas Seekircher has reported his experience with >>> multi-threaded which also confirms that multi-threaded mode is faster, but >>> also he has faced a problem which deserves some attention: >>> >>> However there was a strange behavior, that the simulation was running >>> quite fast on my laptop with up to 9 agents and the simulator was using more >>> than one core. When I started the 10th agent it was getting much slower and >>> it seemed that the simulator was then using only one core (it was then again >>> the same speed like without multi-threading). This happened with 4 cores. On >>> a dual core system already the 5th agent slowed down the simulation... Is >>> this a known issue? >>> >>> I guess that in this situation, ODE is the main bottleneck. But that's >>> just a guess. >>> >> >> Yes, Andreas notified me of that, too. This happens when agents and >> server are run on the same machine with multiple cores.I have found that at >> some point, the system's scheduler assigns an agent to the same core as the >> server (even though in practice there is still room on another core), so the >> server can't run at full speed. With taskset(1) it is possible to explicitly >> set a process' CPU affinity, and by starting the agents with e.g. 'taskset >> 2 ./start.sh localhost' the server is able to take up 100% again. >> >> Great, thanks for the info. We might be able to design a more general >> framework for running agents using Linux CGroups and maybe taking advantage >> of perf tools. But I should investigate more before being able to comment >> more on this issue. >> >> >> >> ... >>> >>> Great. But it'd be probably nice if we parallelize the collision >>> detection too. Specially, it's computation time will increase considerably >>> when two or more robots collide (fortunately the new referee doesn't allow >>> many robots to collide at the same place, but with more players it is more >>> likely that we'll have collisions in different part of the field). >>> >> >> From what I can tell so far it seems that the main part of the speed >> reduction due to collisions is not caused by the collision detection, but by >> the fact that it adds many new constraints to the LCP problem that ODE >> solves to step the physics. However, I still have to make a team of robots >> that just run into each other to be able to say that with certainty. And you >> are right, it would be nice in any case ;) >> >> Thanks for the clarification. Yes IIRC solving the LCP problem was a real >> bottleneck. If it doesn't worth the effort, we might skip this part for now. >> >> >> >> So far about what I am doing. Now, I would also like something from >>> you guys ;-) First of all, give the new stuff I committed a good test. >>> Behaviour of the simulator should still be the same, but it could be that I >>> missed something and that timing of messages is slightly different, breaking >>> agents. Also, give the multi threaded mode a good test, see if you can make >>> it crash. And, finally, I will be working full time on the simulator for 1 >>> 1/2 months more, if you think there is anything that I may be able to >>> squeeze in there, do let me know! >>> >>> Certainly! :) >>> I noticed something in your recent commit: you've removed the ugly >>> busy-waiting loop in SimControlThread, but wouldn't it result in a faster >>> simulation when ODE has not much work to do? The loop was there to make sure >>> that a cycle will last no less than 0.02 (mSimStep). If I'm not mistaken, it >>> is now possible for a cycle to finish too soon. >>> >> >> I think you refer to: >> >> if (isInputControl) >> { >> while (int(mSumDeltaTime*100) < int(mSimStep*100)) >> controlNode->StartCycle(); // advance the time >> } >> >> ? The only use I saw of that was to keep updating the InputControl to >> get messages from the monitor while the physics are updated. The time check >> is there to stop doing this when the physics are done. Without this check, >> the InputControl (and the other controls, AgentControl and MonitorControl) >> wait for the physics to be done anyway at the next barrier, so the cycle >> can't be finished too soon. And this loop caused the most problems with >> multi threading, because it allowed the scene graph to be changed while the >> physics were still running on it. >> >> Yes, I was referring to this loop. Unfortunately InputControl doesn't >> exactly do what it is supposed to. Beside handing input, it also functions >> as the simulator timer, which is very ambiguous (and I'm going to replace it >> with another timer implementation). This loop is not intended to receive >> messages from the monitor (you'll see the same loop in >> SimulationServer::Cycle() which is run in single threaded mode); it is a >> busy-waiting loop to make sure that a cycle will not last less than >> mSimStep. On of the functions which InputControl::StartCycle does is to >> inspect SDL's timer and call SimulationServer::AdvanceTime(), which in turn >> updates mSumDeltaTime. Yes, doesn't look good and was really problematic for >> me to understand what happens completely :P >> >> Personally, I'm planning to remove the use of SDL timer altogether and >> switch to using Boost's timing facilities, which is much more cleaner and >> also doesn't need a busy-waiting loop. >> >> Thanks, >> Hedayat >> >> >> >> >>> There are some collaboration opportunities with your work and what I'm >>> planning to do, but I'll talk about them in a separate email soon. >>> >> >> Looking forward to it :) >> >> >>> >>> Thanks, >>> Hedayat >>> >> -- >> Adaptive Systems Research Group >> Department of Computer Science >> University of Hertfordshire >> United Kingdom >> >> > > > -- > Adaptive Systems Research Group > Department of Computer Science > University of Hertfordshire > United Kingdom > -- Adaptive Systems Research Group Department of Computer Science University of Hertfordshire United Kingdom |
|
From: Hedayat V. <hed...@gm...> - 2011-02-20 08:28:56
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi,<br>
<br>
On ۱۱/۰۲/۲۰ 09:06, Sander van Dijk wrote:
<blockquote
cite="mid:AANLkTinzmGOLWX+OzoWy9Wb9YWUsE5Q4AqzKtZ=Ez...@ma..."
type="cite">....
<div class="gmail_quote">
<div><br>
</div>
<div>Yes, good point. I will make sure to record all test
details. For now: I am mostly using valgrind (with the
callgrind and helgrind tools in specific). I first tried
gprof, but then everything was very unstable, but maybe that's
helped with the current fixes.</div>
</div>
</blockquote>
Thanks.<br>
<br>
<br>
<blockquote
cite="mid:AANLkTinzmGOLWX+OzoWy9Wb9YWUsE5Q4AqzKtZ=Ez...@ma..."
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">...Also, Andreas
Seekircher has reported his experience with multi-threaded
which also confirms that multi-threaded mode is faster, but
also he has faced a problem which deserves some attention:<br>
<blockquote type="cite">However there was a strange
behavior, that the simulation was running quite fast on my
laptop with up to 9 agents and the simulator was using
more than one core. When I started the 10th agent it was
getting much slower and it seemed that the simulator was
then using only one core (it was then again the same speed
like without multi-threading). This happened with 4 cores.
On a dual core system already the 5th agent slowed down
the simulation... Is this a known issue? </blockquote>
I guess that in this situation, ODE is the main bottleneck.
But that's just a guess.</div>
</blockquote>
<div><br>
</div>
<div>Yes, Andreas notified me of that, too. This happens when
agents and server are run on the same machine with multiple
cores.I have found that at some point, the system's scheduler
assigns an agent to the same core as the server (even though
in practice there is still room on another core), so the
server can't run at full speed. With taskset(1) it is possible
to explicitly set a process' CPU affinity, and by starting the
agents with e.g. 'taskset 2 ./start.sh localhost' the server
is able to take up 100% again.</div>
</div>
</blockquote>
Great, thanks for the info. We might be able to design a more
general framework for running agents using Linux CGroups and maybe
taking advantage of perf tools. But I should investigate more before
being able to comment more on this issue.<br>
<br>
<br>
<blockquote
cite="mid:AANLkTinzmGOLWX+OzoWy9Wb9YWUsE5Q4AqzKtZ=Ez...@ma..."
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div class="im">
<blockquote type="cite">...<br>
</blockquote>
</div>
Great. But it'd be probably nice if we parallelize the
collision detection too. Specially, it's computation time
will increase considerably when two or more robots collide
(fortunately the new referee doesn't allow many robots to
collide at the same place, but with more players it is more
likely that we'll have collisions in different part of the
field).<br>
</div>
</blockquote>
<div><br>
</div>
<div>From what I can tell so far it seems that the main part of
the speed reduction due to collisions is not caused by the
collision detection, but by the fact that it adds many new
constraints to the LCP problem that ODE solves to step the
physics. However, I still have to make a team of robots that
just run into each other to be able to say that with
certainty. And you are right, it would be nice in any case ;)
<br>
</div>
</div>
</blockquote>
Thanks for the clarification. Yes IIRC solving the LCP problem was a
real bottleneck. If it doesn't worth the effort, we might skip this
part for now. <br>
<br>
<br>
<blockquote
cite="mid:AANLkTinzmGOLWX+OzoWy9Wb9YWUsE5Q4AqzKtZ=Ez...@ma..."
type="cite">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000">
<div class="im">
<blockquote type="cite">So far about what I am doing. Now,
I would also like something from you guys ;-) First of
all, give the new stuff I committed a good test.
Behaviour of the simulator should still be the same, but
it could be that I missed something and that timing of
messages is slightly different, breaking agents. Also,
give the multi threaded mode a good test, see if you can
make it crash. And, finally, I will be working full time
on the simulator for 1 1/2 months more, if you think
there is anything that I may be able to squeeze in
there, do let me know!<br>
</blockquote>
</div>
Certainly! :) <br>
I noticed something in your recent commit: you've removed
the ugly busy-waiting loop in SimControlThread, but wouldn't
it result in a faster simulation when ODE has not much work
to do? The loop was there to make sure that a cycle will
last no less than 0.02 (mSimStep). If I'm not mistaken, it
is now possible for a cycle to finish too soon. <br>
</div>
</blockquote>
<div><br>
</div>
<div>I think you refer to:</div>
<div>
<div><br>
</div>
<div> if (isInputControl)</div>
<div> {</div>
<div> while (int(mSumDeltaTime*100) <
int(mSimStep*100))</div>
<div> controlNode->StartCycle(); //
advance the time</div>
<div> }</div>
</div>
<div><br>
</div>
<div>? The only use I saw of that was to keep updating the
InputControl to get messages from the monitor while the
physics are updated. The time check is there to stop doing
this when the physics are done. Without this check, the
InputControl (and the other controls, AgentControl and
MonitorControl) wait for the physics to be done anyway at the
next barrier, so the cycle can't be finished too soon. And
this loop caused the most problems with multi threading,
because it allowed the scene graph to be changed while the
physics were still running on it.</div>
</div>
</blockquote>
Yes, I was referring to this loop. Unfortunately InputControl
doesn't exactly do what it is supposed to. Beside handing input, it
also functions as the simulator timer, which is very ambiguous (and
I'm going to replace it with another timer implementation). This
loop is not intended to receive messages from the monitor (you'll
see the same loop in SimulationServer::Cycle() which is run in
single threaded mode); it is a busy-waiting loop to make sure that a
cycle will not last less than mSimStep. On of the functions which
InputControl::StartCycle does is to inspect SDL's timer and call
SimulationServer::AdvanceTime(), which in turn updates
mSumDeltaTime. Yes, doesn't look good and was really problematic for
me to understand what happens completely :P<br>
<br>
Personally, I'm planning to remove the use of SDL timer altogether
and switch to using Boost's timing facilities, which is much more
cleaner and also doesn't need a busy-waiting loop. <br>
<br>
Thanks,<br>
Hedayat<br>
<br>
<br>
<blockquote
cite="mid:AANLkTinzmGOLWX+OzoWy9Wb9YWUsE5Q4AqzKtZ=Ez...@ma..."
type="cite">
<div class="gmail_quote">
<div><br>
</div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> <br>
There are some collaboration opportunities with your work
and what I'm planning to do, but I'll talk about them in a
separate email soon.<br>
</div>
</blockquote>
<div><br>
</div>
<div>Looking forward to it :)</div>
<div> </div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> <br>
Thanks,<br>
<font color="#888888"> Hedayat</font><br>
</div>
</blockquote>
</div>
-- <br>
Adaptive Systems Research Group<br>
Department of Computer Science<br>
University of Hertfordshire<br>
United Kingdom<br>
</blockquote>
</body>
</html>
|
|
From: Sander v. D. <sgv...@gm...> - 2011-02-20 05:36:55
|
Hey,
On Sat, Feb 19, 2011 at 7:34 PM, Hedayat Vatankhah <hed...@gm...>wrote:
> Hi Sander!
> (my reply with more time to write! :P)
>
Great, thanks :)
>
>
> On ۱۱/۰۲/۱۸ 11:53, Sander van Dijk wrote:
>
> Hello MC,
>
> As you may know, the RC federation put out a call for proposals for
> projects, among others to work on the competition infrastructure. I sent in
> a proposal together with Ubbo Visser, which got accepted. So now I am with
> Ubbo to work on simspark for 2 months, and I would like to keep you up to
> date with what we're doing.
>
> Thanks for letting us informed, and very happy to hear that it is going to
> happen in these 2 months. :)
>
>
>
> The main aim of our project is to make the simulator usable for bulk
> training. One part of that means debugging the simulator and make it faster
> and more stable, the other part is to make some external tools. On the
> second point we are still working out the details, but on the first part I
> did some work:
>
> * Did a lot of profiling, which a.o. showed that the server spent more than
> 10% of the time on dynamic casting alone. This was mostly because of
> continuous searches for nodes in the scene tree. I have put in some caching
> here to alleviate it, reducing the time spent casting to 1%. This extra 10%
> has now gone to ODE. I still have to create some performance tests to see if
> this made stuff faster.
>
> That's great. It'd be also nice if you specify which tools do you use for
> profiling for the record. IIRC, previously we had some inconsistent
> profiling results based on the tools we used; so it might be helpful to know
> the tools beside the results. Also, it might be helpful if you provide the
> complete results about the most time consuming parts with more details.
> Maybe there are people who'll work on some other time consuming parts. :)
>
Yes, good point. I will make sure to record all test details. For now: I am
mostly using valgrind (with the callgrind and helgrind tools in specific). I
first tried gprof, but then everything was very unstable, but maybe that's
helped with the current fixes.
> * Multi threading mode is fixed (but see below). Although at first I was
> doubtful of whether the current way it is done would help, it should,
> because now the second and third most costly things, gathering perception
> data (20%) and gathering monitor data (8%) can now be done in parallel.
> However, while running a 6vs6 game there is not a real noticeable speed-up.
> But again, I still have to do proper performance tests to see what it does.
>
> Thanks for the fix.
> We've not conducted any benchmarks to find the difference when
> multi-threading is enabled and when it is disabled; but our experience at
> IranOpen 2010 and apparently GermanOpen 2010 experience have shown that
> multi-threaded mode is practically faster.
> Also, Andreas Seekircher has reported his experience with multi-threaded
> which also confirms that multi-threaded mode is faster, but also he has
> faced a problem which deserves some attention:
>
> However there was a strange behavior, that the simulation was running quite
> fast on my laptop with up to 9 agents and the simulator was using more than
> one core. When I started the 10th agent it was getting much slower and it
> seemed that the simulator was then using only one core (it was then again
> the same speed like without multi-threading). This happened with 4 cores. On
> a dual core system already the 5th agent slowed down the simulation... Is
> this a known issue?
>
> I guess that in this situation, ODE is the main bottleneck. But that's just
> a guess.
>
Yes, Andreas notified me of that, too. This happens when agents and server
are run on the same machine with multiple cores.I have found that at some
point, the system's scheduler assigns an agent to the same core as the
server (even though in practice there is still room on another core), so the
server can't run at full speed. With taskset(1) it is possible to explicitly
set a process' CPU affinity, and by starting the agents with e.g. 'taskset
2 ./start.sh localhost' the server is able to take up 100% again.
However, the biggest opportunity to optimise is ODE, which now eats up
> 67-70% of all computation time. There was a project at CMU in 2007 to
> parallelize ODE [1], where they made the collision detection parallel.
> Profiling shows however that this will not help: collision detection takes
> up 0.45% in rcssserver3d. What is expensive for us, is stepping the physics.
> Luckily, ODE already splits this work into different parts, updating
> 'islands' seperately, where in our case each island is one agent. I am now
> working on parallelising this, and if that works we can in theory cut up the
> 67% CPU time into 12/18 parts (4vs6/9vs9) that can be run in parallel,
> hopefully making having 8 cores actually useful.
>
> Great. But it'd be probably nice if we parallelize the collision detection
> too. Specially, it's computation time will increase considerably when two or
> more robots collide (fortunately the new referee doesn't allow many robots
> to collide at the same place, but with more players it is more likely that
> we'll have collisions in different part of the field).
>
>From what I can tell so far it seems that the main part of the speed
reduction due to collisions is not caused by the collision detection, but by
the fact that it adds many new constraints to the LCP problem that ODE
solves to step the physics. However, I still have to make a team of robots
that just run into each other to be able to say that with certainty. And you
are right, it would be nice in any case ;)
So far about what I am doing. Now, I would also like something from you guys
> ;-) First of all, give the new stuff I committed a good test. Behaviour of
> the simulator should still be the same, but it could be that I missed
> something and that timing of messages is slightly different, breaking
> agents. Also, give the multi threaded mode a good test, see if you can make
> it crash. And, finally, I will be working full time on the simulator for 1
> 1/2 months more, if you think there is anything that I may be able to
> squeeze in there, do let me know!
>
> Certainly! :)
> I noticed something in your recent commit: you've removed the ugly
> busy-waiting loop in SimControlThread, but wouldn't it result in a faster
> simulation when ODE has not much work to do? The loop was there to make sure
> that a cycle will last no less than 0.02 (mSimStep). If I'm not mistaken, it
> is now possible for a cycle to finish too soon.
>
I think you refer to:
if (isInputControl)
{
while (int(mSumDeltaTime*100) < int(mSimStep*100))
controlNode->StartCycle(); // advance the time
}
? The only use I saw of that was to keep updating the InputControl to get
messages from the monitor while the physics are updated. The time check is
there to stop doing this when the physics are done. Without this check, the
InputControl (and the other controls, AgentControl and MonitorControl) wait
for the physics to be done anyway at the next barrier, so the cycle can't be
finished too soon. And this loop caused the most problems with multi
threading, because it allowed the scene graph to be changed while the
physics were still running on it.
> There are some collaboration opportunities with your work and what I'm
> planning to do, but I'll talk about them in a separate email soon.
>
Looking forward to it :)
>
> Thanks,
> Hedayat
>
>
> Cheers,
> Sander
>
> [1] http://www.cs.cmu.edu/~mpa/ode/
>
> --
> Adaptive Systems Research Group
> Department of Computer Science
> University of Hertfordshire
> United Kingdom
>
>
--
Adaptive Systems Research Group
Department of Computer Science
University of Hertfordshire
United Kingdom
|
|
From: Hedayat V. <hed...@gm...> - 2011-02-20 00:35:34
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Sander!<br>
(my reply with more time to write! :P)<br>
<br>
On ۱۱/۰۲/۱۸ 11:53, Sander van Dijk wrote:
<blockquote
cite="mid:AAN...@ma..."
type="cite">Hello MC,<br>
<br>
As you may know, the RC federation put out a call for proposals
for projects, among others to work on the competition
infrastructure. I sent in a proposal together with Ubbo Visser,
which got accepted. So now I am with Ubbo to work on simspark for
2 months, and I would like to keep you up to date with what we're
doing.<br>
</blockquote>
Thanks for letting us informed, and very happy to hear that it is
going to happen in these 2 months. :)<br>
<br>
<blockquote
cite="mid:AAN...@ma..."
type="cite">
<br>
The main aim of our project is to make the simulator usable for
bulk training. One part of that means debugging the simulator and
make it faster and more stable, the other part is to make some
external tools. On the second point we are still working out the
details, but on the first part I did some work:<br>
<br>
* Did a lot of profiling, which a.o. showed that the server spent
more than 10% of the time on dynamic casting alone. This was
mostly because of continuous searches for nodes in the scene tree.
I have put in some caching here to alleviate it, reducing the time
spent casting to 1%. This extra 10% has now gone to ODE. I still
have to create some performance tests to see if this made stuff
faster.<br>
</blockquote>
That's great. It'd be also nice if you specify which tools do you
use for profiling for the record. IIRC, previously we had some
inconsistent profiling results based on the tools we used; so it
might be helpful to know the tools beside the results. Also, it
might be helpful if you provide the complete results about the most
time consuming parts with more details. Maybe there are people
who'll work on some other time consuming parts. :)<br>
<br>
<br>
<blockquote
cite="mid:AAN...@ma..."
type="cite">
<br>
* Multi threading mode is fixed (but see below). Although at first
I was doubtful of whether the current way it is done would help,
it should, because now the second and third most costly things,
gathering perception data (20%) and gathering monitor data (8%)
can now be done in parallel. However, while running a 6vs6 game
there is not a real noticeable speed-up. But again, I still have
to do proper performance tests to see what it does.<br>
</blockquote>
Thanks for the fix. <br>
We've not conducted any benchmarks to find the difference when
multi-threading is enabled and when it is disabled; but our
experience at IranOpen 2010 and apparently GermanOpen 2010
experience have shown that multi-threaded mode is practically
faster.<br>
Also, Andreas Seekircher has reported his experience with
multi-threaded which also confirms that multi-threaded mode is
faster, but also he has faced a problem which deserves some
attention:<br>
<blockquote type="cite">However there was a strange behavior, that
the simulation was running quite fast on my laptop with up to 9
agents and the simulator was using more than one core. When I
started the 10th agent it was getting much slower and it seemed
that the simulator was then using only one core (it was then again
the same speed like without multi-threading). This happened with 4
cores. On a dual core system already the 5th agent slowed down the
simulation... Is this a known issue?
</blockquote>
I guess that in this situation, ODE is the main bottleneck. But
that's just a guess.<br>
<br>
<br>
<blockquote
cite="mid:AAN...@ma..."
type="cite">
<br>
However, the biggest opportunity to optimise is ODE, which now
eats up 67-70% of all computation time. There was a project at CMU
in 2007 to parallelize ODE [1], where they made the collision
detection parallel. Profiling shows however that this will not
help: collision detection takes up 0.45% in rcssserver3d. What is
expensive for us, is stepping the physics. Luckily, ODE already
splits this work into different parts, updating 'islands'
seperately, where in our case each island is one agent. I am now
working on parallelising this, and if that works we can in theory
cut up the 67% CPU time into 12/18 parts (4vs6/9vs9) that can be
run in parallel, hopefully making having 8 cores actually useful.<br>
</blockquote>
Great. But it'd be probably nice if we parallelize the collision
detection too. Specially, it's computation time will increase
considerably when two or more robots collide (fortunately the new
referee doesn't allow many robots to collide at the same place, but
with more players it is more likely that we'll have collisions in
different part of the field). <br>
<br>
<br>
<br>
<blockquote
cite="mid:AAN...@ma..."
type="cite">
<br>
So far about what I am doing. Now, I would also like something
from you guys ;-) First of all, give the new stuff I committed a
good test. Behaviour of the simulator should still be the same,
but it could be that I missed something and that timing of
messages is slightly different, breaking agents. Also, give the
multi threaded mode a good test, see if you can make it crash.
And, finally, I will be working full time on the simulator for 1
1/2 months more, if you think there is anything that I may be able
to squeeze in there, do let me know!<br>
</blockquote>
Certainly! :) <br>
I noticed something in your recent commit: you've removed the ugly
busy-waiting loop in SimControlThread, but wouldn't it result in a
faster simulation when ODE has not much work to do? The loop was
there to make sure that a cycle will last no less than 0.02
(mSimStep). If I'm not mistaken, it is now possible for a cycle to
finish too soon. <br>
<br>
There are some collaboration opportunities with your work and what
I'm planning to do, but I'll talk about them in a separate email
soon.<br>
<br>
Thanks,<br>
Hedayat<br>
<blockquote
cite="mid:AAN...@ma..."
type="cite">
<br>
Cheers,<br>
Sander<br>
<br>
[1] <a moz-do-not-send="true"
href="http://www.cs.cmu.edu/%7Empa/ode/">http://www.cs.cmu.edu/~mpa/ode/</a><br>
<br>
-- <br>
Adaptive Systems Research Group<br>
Department of Computer Science<br>
University of Hertfordshire<br>
United Kingdom<br>
<br>
</blockquote>
</body>
</html>
|
|
From: Hedayat V. <hed...@gm...> - 2011-02-19 17:56:56
|
Hi,
This is the last email I found from Hesham, with his last
implementation. It might be helpful regarding the recent discussions. I
hope it gets the attention it deserves. :)
Good luck,
Hedayat
-------- Original Message --------
Subject: Fwd: multi-threaded ODE
Date: Mon, 16 Jun 2008 07:58:04 +0200
From: H.Ebrahimi <hes...@gm...>
To: Sahar Asadi <sah...@gm...>
CC: Joschka Boedecker <jos...@am...>, Yuan
Xu <xy...@ya...>, Feng Xue <hen...@ma...>, Hedayat
Vatankhah <hed...@ai...>
Hello Sahar,
(cc Joschka, Yuan, Feng and Hedayat)
I forgot to mention in scenserver.cpp on line 47 you see:
tbb::task_scheduler_init tbb_sched;
Sometimes on some machines, it's better to set the number of threads to
get the best performance. But in the code I sent you TBB sets the number
of threads automatically. On my laptop I get a very good result with 5
threads:
tbb::task_scheduler_init tbb_sched(5);
But with the latest version of TBB (released in June 2008), I got a very
good result without setting the number of threads. Apparently this
feature is improved in this version. So if you find time, it would be
great to test with different number of threads and compare the result.
Probably next weekend I can send you a version that doesn't need to
modify the server code. But I'm not sure if we get the same performance.
I forwarded this email since I'd forgotten to send it to Feng and Hedayat.
Best,
Hesham
---------- Forwarded message ----------
From: *H. Ebrahimi* <hes...@gm...
<mailto:hes...@gm...>>
Date: 2008/6/15
Subject: Re: Agent Type discussion and rules
To: Sahar Asadi <sah...@gm... <mailto:sah...@gm...>>
Cc: Joschka Boedecker <jos...@am...
<mailto:jos...@am...>>, Yuan Xu
<xy...@ya... <mailto:xy...@ya...>>
Hi Sahar,
2008/6/15 Sahar Asadi <sah...@gm... <mailto:sah...@gm...>>:
@Hesham and Joschka: I am still waiting for source files to test
with ODE changes
Sorry, last week I was away, couldn't work on this. I didn't manage to
compile the server with gcc 4.3, so had to install gcc 4.2. Probably
until next weekend I cant find time to prepare a patch, so if you don't
mind I send you the files and some small modification that should be done.
To have a clue of the speedup the multi-threaded version of ODE gives, I
use rdtsc to see the time each 100 ODE steps take (sceneserver.cpp
prints this number). On my laptop for 3 agents, with multi-threaded ODE
I get less than 1E7 and with original ODE I get around 1.6E7. But I
expect if we run the agents on other machines, we get even more speedup.
So sceneserver.cpp is the only file of the server I've modified. But
please modify Makefile in /lib/oxygen/ and add -ltbb -lpthread to:
liboxygen_debug_la_LIBADD = -ltbb -lpthread -lode ${spades_libs}
Since it will be linked with the static ODE library, if you want to link
with another version of ODE, need to link oxygen again. And please make
sure the release version of TBB is used. When you compile TBB, it gives
the debug and release versions. And the debug version is around 10 times
slower.
I've also attached all the source files of ODE in /ode/src/, please
replace the original ones with them. And also please add -ltbb -lpthread
to Makefile of ODE:
LIBS = -lstdc++ -lm -lpthread -ltbb -ltbbmalloc -lrt
if you want to compile the tests and other directories in ODE, you may
need to modify their Makefiles as well.
Please let me know if you see any problems with compiling this. By the
way, please set the flag of "setAutoDisableFlag(true)" to false, in
spark.rb. In the tests I ran, in a few of them after running and
connecting the second agent, the server crashed. Please let me know if
you see this, in the previous versions of the server with multi-threaded
ODE I hadn't seen this.
Best,
Hesham
|
|
From: Sander v. D. <sgv...@gm...> - 2011-02-19 16:51:35
|
Hey Joschka, Thanks for your reply. I didn't know about TBB, I will have a look into it. I found a partly copy of the book online, but of course the part about ODE is missing :) I will see if I can find it. Regarding Bullet, I totally agree that for the future that is probably the way forward. However, we hope to have these improvements ready for Istanbul, and preferably for the German and Iran Open too. Using a different physics engine will most likely change the dynamics, having most teams probably have to recreate/relearn their movements. It would not be good to throw that onto them on such short notice. Probably the best time to make this switch is when we use new models/heterogeneous agents, when everybody has to start over anyway. So that's why I am focusing on ODE now, the dynamics should stay the same and it seems like there are relatively straightforward ways of parallelising it. However, that is not a argument against already making a start with Bullet now, and I have started taking a look at the API, to see how well it fits the interfaces we now have after Andreas' very useful work. About the integrated agents, that is a good idea! I will try to include those in my tests. Thanks again, Sander On Sat, Feb 19, 2011 at 6:08 AM, Joschka Boedecker < jos...@am...> wrote: > One thing I forgot: have you tested how running agents as plugins in the > simulator, like the example in rcssserver3d/plugin/soccer/agentintegration, > improves performance (only for training/learning, not in competitions, of > course)? Would be interesting to have actual measurements on that. > > Cheers, > Joschka > > P.S.: did I mention Bullet integration would be a great project? ;-) > > On Feb 19, 2011, at 2:23 PM, Joschka Boedecker wrote: > > > Hey Sander, > > > > On Feb 19, 2011, at 5:23 AM, Sander van Dijk wrote: > > > >> Hello MC, > >> > >> As you may know, the RC federation put out a call for proposals for > projects, among others to work on the competition infrastructure. I sent in > a proposal together with Ubbo Visser, which got accepted. So now I am with > Ubbo to work on simspark for 2 months, and I would like to keep you up to > date with what we're doing. > >> > >> The main aim of our project is to make the simulator usable for bulk > training. One part of that means debugging the simulator and make it faster > and more stable, the other part is to make some external tools. On the > second point we are still working out the details, but on the first part I > did some work: > >> > > > > First of all: great to hear you're working on these things! Congrats to > you and Ubbo on the accepted project proposal :-) Very exciting! > > > >> * Did a lot of profiling, which a.o. showed that the server spent more > than 10% of the time on dynamic casting alone. This was mostly because of > continuous searches for nodes in the scene tree. I have put in some caching > here to alleviate it, reducing the time spent casting to 1%. This extra 10% > has now gone to ODE. I still have to create some performance tests to see if > this made stuff faster. > > > > Nice :-) > > > >> > >> * Multi threading mode is fixed (but see below). Although at first I was > doubtful of whether the current way it is done would help, it should, > because now the second and third most costly things, gathering perception > data (20%) and gathering monitor data (8%) can now be done in parallel. > However, while running a 6vs6 game there is not a real noticeable speed-up. > But again, I still have to do proper performance tests to see what it does. > > > > Very cool. > > > >> > >> However, the biggest opportunity to optimise is ODE, which now eats up > 67-70% of all computation time. There was a project at CMU in 2007 to > parallelize ODE [1], where they made the collision detection parallel. > Profiling shows however that this will not help: collision detection takes > up 0.45% in rcssserver3d. What is expensive for us, is stepping the physics. > Luckily, ODE already splits this work into different parts, updating > 'islands' seperately, where in our case each island is one agent. I am now > working on parallelising this, and if that works we can in theory cut up the > 67% CPU time into 12/18 parts (4vs6/9vs9) that can be run in parallel, > hopefully making having 8 cores actually useful. > >> > > > > Long time ago, Hesham Ebrahimi worked on parallelizing parts of ODE as > team member of the MC. He used the Intel Threading Building Blocks (TBB) > library back then, but unfortunately, I'm not exactly sure anymore what > happened to that code :-( Anyways, I remember that there's a book on Intel > TBB published by O'Reilly (author is James Reinders) which he used. This has > parallelization of ODE as an example towards the end of the book. See if you > can get a hold of that it, it might be a big help (at least that last part > on ODE). > > > > Otherwise, I would suggest considering the integration of the Bullet > physics engine [1] as an alternative to ODE. Bullet has more features, a > very active development team, and increasing support for massively parallel > computation for collision detection and for the solver using OpenCL. This > looks like the better alternative for the future to me. > > > > The project I did with Andreas to move ODE to a plugin and enable other > physics engines was meant to be the first part for a later Bullet > integration, but unfortunately, nobody had time to work on that yet. Give > Bullet integration some thought :-) I don't have any data at hand, but I'm > pretty convinced it will lead to much better performance, especially when > supported by GPU computation and multiple CPUs. > > > > Keep us updated on your progress and all the best, > > Joschka > > > > [1] http://bulletphysics.org/ > > > ------------------------------------------------------------------------------ > > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > > Pinpoint memory and threading errors before they happen. > > Find and fix more than 250 security defects in the development cycle. > > Locate bottlenecks in serial and parallel code that limit performance. > > http://p.sf.net/sfu/intel-dev2devfeb > > _______________________________________________ > > Simspark Generic Physical MAS Simulator > > simspark-devel mailing list > > sim...@li... > > https://lists.sourceforge.net/lists/listinfo/simspark-devel > > -- Adaptive Systems Research Group Department of Computer Science University of Hertfordshire United Kingdom |
|
From: Joschka B. <jos...@am...> - 2011-02-19 06:08:30
|
One thing I forgot: have you tested how running agents as plugins in the simulator, like the example in rcssserver3d/plugin/soccer/agentintegration, improves performance (only for training/learning, not in competitions, of course)? Would be interesting to have actual measurements on that. Cheers, Joschka P.S.: did I mention Bullet integration would be a great project? ;-) On Feb 19, 2011, at 2:23 PM, Joschka Boedecker wrote: > Hey Sander, > > On Feb 19, 2011, at 5:23 AM, Sander van Dijk wrote: > >> Hello MC, >> >> As you may know, the RC federation put out a call for proposals for projects, among others to work on the competition infrastructure. I sent in a proposal together with Ubbo Visser, which got accepted. So now I am with Ubbo to work on simspark for 2 months, and I would like to keep you up to date with what we're doing. >> >> The main aim of our project is to make the simulator usable for bulk training. One part of that means debugging the simulator and make it faster and more stable, the other part is to make some external tools. On the second point we are still working out the details, but on the first part I did some work: >> > > First of all: great to hear you're working on these things! Congrats to you and Ubbo on the accepted project proposal :-) Very exciting! > >> * Did a lot of profiling, which a.o. showed that the server spent more than 10% of the time on dynamic casting alone. This was mostly because of continuous searches for nodes in the scene tree. I have put in some caching here to alleviate it, reducing the time spent casting to 1%. This extra 10% has now gone to ODE. I still have to create some performance tests to see if this made stuff faster. > > Nice :-) > >> >> * Multi threading mode is fixed (but see below). Although at first I was doubtful of whether the current way it is done would help, it should, because now the second and third most costly things, gathering perception data (20%) and gathering monitor data (8%) can now be done in parallel. However, while running a 6vs6 game there is not a real noticeable speed-up. But again, I still have to do proper performance tests to see what it does. > > Very cool. > >> >> However, the biggest opportunity to optimise is ODE, which now eats up 67-70% of all computation time. There was a project at CMU in 2007 to parallelize ODE [1], where they made the collision detection parallel. Profiling shows however that this will not help: collision detection takes up 0.45% in rcssserver3d. What is expensive for us, is stepping the physics. Luckily, ODE already splits this work into different parts, updating 'islands' seperately, where in our case each island is one agent. I am now working on parallelising this, and if that works we can in theory cut up the 67% CPU time into 12/18 parts (4vs6/9vs9) that can be run in parallel, hopefully making having 8 cores actually useful. >> > > Long time ago, Hesham Ebrahimi worked on parallelizing parts of ODE as team member of the MC. He used the Intel Threading Building Blocks (TBB) library back then, but unfortunately, I'm not exactly sure anymore what happened to that code :-( Anyways, I remember that there's a book on Intel TBB published by O'Reilly (author is James Reinders) which he used. This has parallelization of ODE as an example towards the end of the book. See if you can get a hold of that it, it might be a big help (at least that last part on ODE). > > Otherwise, I would suggest considering the integration of the Bullet physics engine [1] as an alternative to ODE. Bullet has more features, a very active development team, and increasing support for massively parallel computation for collision detection and for the solver using OpenCL. This looks like the better alternative for the future to me. > > The project I did with Andreas to move ODE to a plugin and enable other physics engines was meant to be the first part for a later Bullet integration, but unfortunately, nobody had time to work on that yet. Give Bullet integration some thought :-) I don't have any data at hand, but I'm pretty convinced it will lead to much better performance, especially when supported by GPU computation and multiple CPUs. > > Keep us updated on your progress and all the best, > Joschka > > [1] http://bulletphysics.org/ > ------------------------------------------------------------------------------ > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: > Pinpoint memory and threading errors before they happen. > Find and fix more than 250 security defects in the development cycle. > Locate bottlenecks in serial and parallel code that limit performance. > http://p.sf.net/sfu/intel-dev2devfeb > _______________________________________________ > Simspark Generic Physical MAS Simulator > simspark-devel mailing list > sim...@li... > https://lists.sourceforge.net/lists/listinfo/simspark-devel |
|
From: Joschka B. <jos...@am...> - 2011-02-19 05:39:36
|
Hey Sander, On Feb 19, 2011, at 5:23 AM, Sander van Dijk wrote: > Hello MC, > > As you may know, the RC federation put out a call for proposals for projects, among others to work on the competition infrastructure. I sent in a proposal together with Ubbo Visser, which got accepted. So now I am with Ubbo to work on simspark for 2 months, and I would like to keep you up to date with what we're doing. > > The main aim of our project is to make the simulator usable for bulk training. One part of that means debugging the simulator and make it faster and more stable, the other part is to make some external tools. On the second point we are still working out the details, but on the first part I did some work: > First of all: great to hear you're working on these things! Congrats on the accepted project proposal :-) Very exciting! > * Did a lot of profiling, which a.o. showed that the server spent more than 10% of the time on dynamic casting alone. This was mostly because of continuous searches for nodes in the scene tree. I have put in some caching here to alleviate it, reducing the time spent casting to 1%. This extra 10% has now gone to ODE. I still have to create some performance tests to see if this made stuff faster. Nice :-) > > * Multi threading mode is fixed (but see below). Although at first I was doubtful of whether the current way it is done would help, it should, because now the second and third most costly things, gathering perception data (20%) and gathering monitor data (8%) can now be done in parallel. However, while running a 6vs6 game there is not a real noticeable speed-up. But again, I still have to do proper performance tests to see what it does. Very cool. > > However, the biggest opportunity to optimise is ODE, which now eats up 67-70% of all computation time. There was a project at CMU in 2007 to parallelize ODE [1], where they made the collision detection parallel. Profiling shows however that this will not help: collision detection takes up 0.45% in rcssserver3d. What is expensive for us, is stepping the physics. Luckily, ODE already splits this work into different parts, updating 'islands' seperately, where in our case each island is one agent. I am now working on parallelising this, and if that works we can in theory cut up the 67% CPU time into 12/18 parts (4vs6/9vs9) that can be run in parallel, hopefully making having 8 cores actually useful. > Long time ago, Hesham Ebrahimi worked on parallelizing parts of ODE as team member of the MC. He used the Intel Threading Building Blocks (TBB) library back then, but unfortunately, I'm not exactly sure anymore what happened to that code :-( Anyways, I remember that there's a book on Intel TBB published by O'Reilly (author is James Reinders) which he used. This has parallelization of ODE as an example towards the end of the book. See if you can get a hold of that it, it might be a big help (at least that last part on ODE). Otherwise, I would suggest considering the integration of the Bullet physics engine [1] as an alternative to ODE. Bullet has more features, a very active development team, and increasing support for massively parallel computation for collision detection and for the solver using OpenCL. This looks like the better alternative for the future to me. The project I did with Andreas to move ODE to a plugin and enable other physics engines was meant to be the first part for a later Bullet integration, but unfortunately, nobody had time to work on that yet. Give Bullet integration some thought :-) I don't have any data at hand, but I'm pretty convinced it will lead to much better performance, especially when supported by GPU computation and multiple CPUs. Keep us updated on your progress and all the best, Joschka [1] http://bulletphysics.org/ |
|
From: Hedayat V. <hed...@gm...> - 2011-02-18 21:26:53
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<br>
<span>
<style type="text/css">blockquote {color: navy !important; background-color: RGB(245,245,245) !important; padding: 0 15 10 15 !important; margin: 15 0 0 0; border-left: #1010ff 2px solid;} blockquote blockquote {color: maroon !important; background-color: RGB(235,235,235) !important; border-left-color:maroon !important} blockquote blockquote blockquote {color: green !important; background-color: RGB(225,225,225) !important; border-left-color:teal !important} blockquote blockquote blockquote blockquote {color: purple !important; background-color: RGB(215,215,215) !important; border-left-color: purple !important} blockquote blockquote blockquote blockquote blockquote {color: teal !important; background-color: RGB(205,205,205) !important; border-left-color: green !important}</style><i><b>Sander
van Dijk <a class="moz-txt-link-rfc2396E" href="mailto:sgv...@gm..."><sgv...@gm...></a></b></i> wrote on
02/19/2011 12:52:05 AM +0350:</span><br>
<blockquote style="color: navy; background-color: rgb(245, 245,
245); padding-left: 15px; border-left: 2px solid rgb(16, 16,
255);"
cite="mid:AANLkTi=ODZ...@ma..."
type="cite">Hey Hedayat,<br>
<br>
Looking forward to your real reply ;-)<br>
<br>
Thanks for your point! It is indeed true that they will become a
single island then. However, this doesn't change the problem much.
At every physics step the islands are redetermined, after which
they can be spread over different threads. So the only situation
where there is no advantage is when everything is in a single
island (note that this is not the case because all agents are
connected through the ground, the ground is disabled and therefore
not included in islands), which is not likely to happen. What
could perhaps use some consideration is that because of this
islands may not have the same size and that one can do some load
balancing to distribute them over different threads correctly. But
let's first see if it can work at all :)<br>
</blockquote>
:) Yes, I didn't want to stand against processing separating islands
in parallel; just wanted to help a little if possible (e.g. to
prevent an assumption that every agent is a separate island in
implementation).<br>
In fact, I'm really in favor of processing collision detection of
separate islands in parallel, which is also supported by ODE. <br>
<br>
Thanks,<br>
Hedayat<br>
<br>
<br>
<blockquote style="color: navy; background-color: rgb(245, 245,
245); padding-left: 15px; border-left: 2px solid rgb(16, 16,
255);"
cite="mid:AANLkTi=ODZ...@ma..."
type="cite">
<br>
Sander<br>
<br>
<div class="gmail_quote">On Fri, Feb 18, 2011 at 4:08 PM, Hedayat
Vatankhah <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:hed...@gm...">hed...@gm...</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt
0.8ex; border-left: 1px solid rgb(204, 204, 204);
padding-left: 1ex;">
<div bgcolor="#ffffff" text="#000000"> Hi Sander,<br>
Thanks for the report.� :)<br>
I'll post the real reply soon (with some details about what
should be done for RoboCup 2011 in MC). <br>
Just something about ODE islands: I might be wrong but IIRC
if two agents collide with each other, they'll become one
island until they are completely separated again. As I said,
I'm in doubt but it'll probably need some consideration if
I'm right.<br>
<br>
Good luck,<br>
Hedayat<br>
<br>
<span> <i><b>Sander van Dijk <a moz-do-not-send="true"
href="mailto:sgv...@gm..." target="_blank"><sgv...@gm...></a></b></i>
wrote on 02/18/2011 11:53:24 PM +0350:</span><br>
<blockquote style="color: navy; background-color: rgb(245,
245, 245); padding-left: 15px; border-left: 2px solid
rgb(16, 16, 255);" type="cite">
<div>
<div class="h5">Hello MC,<br>
<br>
As you may know, the RC federation put out a call for
proposals for projects, among others to work on the
competition infrastructure. I sent in a proposal
together with Ubbo Visser, which got accepted. So now
I am with Ubbo to work on simspark for 2 months, and I
would like to keep you up to date with what we're
doing.<br>
<br>
The main aim of our project is to make the simulator
usable for bulk training. One part of that means
debugging the simulator and make it faster and more
stable, the other part is to make some external tools.
On the second point we are still working out the
details, but on the first part I did some work:<br>
<br>
* Did a lot of profiling, which a.o. showed that the
server spent more than 10% of the time on dynamic
casting alone. This was mostly because of continuous
searches for nodes in the scene tree. I have put in
some caching here to alleviate it, reducing the time
spent casting to 1%. This extra 10% has now gone to
ODE. I still have to create some performance tests to
see if this made stuff faster.<br>
<br>
* Multi threading mode is fixed (but see below).
Although at first I was doubtful of whether the
current way it is done would help, it should, because
now the second and third most costly things, gathering
perception data (20%) and gathering monitor data (8%)
can now be done in parallel. However, while running a
6vs6 game there is not a real noticeable speed-up. But
again, I still have to do proper performance tests to
see what it does.<br>
<br>
However, the biggest opportunity to optimise is ODE,
which now eats up 67-70% of all computation time.
There was a project at CMU in 2007 to parallelize ODE
[1], where they made the collision detection parallel.
Profiling shows however that this will not help:
collision detection takes up 0.45% in rcssserver3d.
What is expensive for us, is stepping the physics.
Luckily, ODE already splits this work into different
parts, updating 'islands' seperately, where in our
case each island is one agent. I am now working on
parallelising this, and if that works we can in theory
cut up the 67% CPU time into 12/18 parts (4vs6/9vs9)
that can be run in parallel, hopefully making having 8
cores actually useful.<br>
<br>
So far about what I am doing. Now, I would also like
something from you guys ;-) First of all, give the new
stuff I committed a good test. Behaviour of the
simulator should still be the same, but it could be
that I missed something and that timing of messages is
slightly different, breaking agents. Also, give the
multi threaded mode a good test, see if you can make
it crash. And, finally, I will be working full time on
the simulator for 1 1/2 months more, if you think
there is anything that I may be able to squeeze in
there, do let me know!<br>
<br>
Cheers,<br>
Sander<br>
<br>
[1] <a moz-do-not-send="true"
href="http://www.cs.cmu.edu/%7Empa/ode/"
target="_blank">http://www.cs.cmu.edu/~mpa/ode/</a><br>
<br>
-- <br>
Adaptive Systems Research Group<br>
Department of Computer Science<br>
University of Hertfordshire<br>
United Kingdom<br>
</div>
</div>
<pre><fieldset></fieldset>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
<a moz-do-not-send="true" href="http://p.sf.net/sfu/intel-dev2devfeb" target="_blank">http://p.sf.net/sfu/intel-dev2devfeb</a></pre>
<pre><fieldset></fieldset>
_______________________________________________
Simspark Generic Physical MAS Simulator
simspark-devel mailing list
<a moz-do-not-send="true" href="mailto:sim...@li..." target="_blank">sim...@li...</a>
<a moz-do-not-send="true" href="https://lists.sourceforge.net/lists/listinfo/simspark-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/simspark-devel</a>
</pre>
</blockquote>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
Adaptive Systems Research Group<br>
Department of Computer Science<br>
University of Hertfordshire<br>
United Kingdom<br>
</blockquote>
</body>
</html>
|
45 messages has been excluded from this view by a project administrator.
