\endverbatim
-\subsection faq_compiling_cvs Compiling SimGrid from the CVS
+\subsection faq_compiling_svn Compiling SimGrid from the SVN
-The project development takes place in the cvs, where all changes are
+The project development takes place in the svn, where all changes are
commited when they happen. Then every once in a while, we make sure that the
code quality meets our standard and release an archive from the code in the
-CVS. We afterward go back to the development in the CVS. So, if you need a
+SVN. We afterward go back to the development in the SVN. So, if you need a
recently added feature and can afford some little problem with the stability
-of the lastest features, you may want to use the CVS version instead of a
+of the lastest features, you may want to use the SVN version instead of a
released one.
For that, you first need to get the "simgrid" module from
We insist on the fact that you really need the latest versions of
autoconf, automake and libtool. Doing this step on exotic architectures/systems
(i.e. anything different from a recent linux distribution) may be
-... uncertain. If you need to compile the CVS version on a machine where all these
-dependencies are not met, the easiest is to do <tt>make dist</tt> in the CVS
+... uncertain. If you need to compile the SVN version on a machine where all these
+dependencies are not met, the easiest is to do <tt>make dist</tt> in the SVN
dir of another machine where all dependencies are met. It will create an
archive you may deploy on other sites just as a regular stable release.
-In summary, the following commands will checkout the CVS, regenerate the
+In summary, the following commands will checkout the SVN, regenerate the
configure script and friends, configure SimGrid and build it.
-\verbatim cvs -d :pserver:anonymous@scm.gforge.inria.fr:/cvsroot/simgrid login
-cvs -d :pserver:anonymous@scm.gforge.inria.fr:/cvsroot/simgrid checkout simgrid
+\verbatim svn checkout svn://scm.gforge.inria.fr/svn/simgrid/simgrid/trunk
+mv trunk simgrid
cd simgrid
./bootstrap
./configure --enable-maintainer-mode --prefix=<where to install SimGrid>
Then, if you want to install SimGrid on the current box, just do:
\verbatim make install \endverbatim
-If you want to build an snapshot of the CVS to deploy it on another box (for
+If you want to build an snapshot of the SVN to deploy it on another box (for
example because the other machine don't have the autotools), do:
\verbatim make dist \endverbatim
Moreover, you should never call the autotools manually since you must run
them in a specific order with specific arguments. Most of the times, the
makefiles will automatically call the tools for you. When it's not possible
-(such as the first time you checkout the CVS), use the ./bootstrap command
+(such as the first time you checkout the SVN), use the ./bootstrap command
to call them explicitely.
environments (MSG and SD) have good chances to work, but we didn't test
ourselves. This section explains how we generate the SimGrid DLL so that you
can build it for yourself. First of all, you need to have a version more
-recent than 3.1 (ie, a CVS version as time of writting).
+recent than 3.1 (ie, a SVN version as time of writting).
In order to cross-compile the package to windows from linux, you need to
install mingw32 (minimalist gnu win32). On Debian, you can do so by
You can use the VPATH support of configure to compile at the same time for
linux and windows without dupplicating the source nor cleaning the tree
-between each. Just run bootstrap (if you use the CVS) to run the autotools.
+between each. Just run bootstrap (if you use the SVN) to run the autotools.
Then, create a linux and a win directories. Then, type:
\verbatim cd linux; ../configure --srcdir=.. <usual configure flags>; make; cd ..
cd win; ../configure --srcdir=.. --host=i586-mingw32msvc <flags>; make; cd ..
easily that what you change for one arch does not break the other one.
It is possible that this VPATH build thing breaks from time to time in the
-CVS since it's quite fragile, but it's granted to work in any released
+SVN since it's quite fragile, but it's granted to work in any released
version. If you experience problems, drop us a mail.
Another possible source of issue is that at the moment, building the
\subsection faq_MIA_SimDag SimDag related questions
+\subsubsection faq_SG_comm Implementing communication delays between tasks.
+
+A classic question of SimDag newcommers is about how to express a
+communication delay between tasks. The thing is that in SimDag, both
+computation and communication are seen as tasks. So, if you want to
+model a data dependency between two DAG tasks t1 and t2, you have to
+create 3 SD_tasks: t1, t2 and c and add dependencies in the following
+way:
+
+\verbatim
+SD_task_dependency_add(NULL, NULL, t1, c);
+SD_task_dependency_add(NULL, NULL, c, t2);
+\endverbatim
+
+This way task t2 cannot start before the termination of communication c
+which in turn cannot start before t1 ends.
+
+When creating task c, you have to associate an amount of data (in bytes)
+corresponding to what has to be sent by t1 to t2.
+
+Finally to schedule the communication task c, you have to build a list
+comprising the workstations on which t1 and t2 are scheduled (w1 and w2
+for example) and build a communication matrix that should look like
+[0;amount ; 0; 0].
+
+\subsubsection faq_SG_DAG How to implement a distributed dynamic scheduler of DAGs.
+
+Distributed is somehow "contagious". If you start making distributed
+decisions, there is no way to handle DAGs directly anymore (unless I
+am missing something). You have to encode your DAGs in term of
+communicating process to make the whole scheduling process
+distributed. Here is an example of how you could do that. Assume T1
+has to be done before T2.
+
+\verbatim
+ int your_agent(int argc, char *argv[] {
+ ...
+ T1 = MSG_task_create(...);
+ T2 = MSG_task_create(...);
+ ...
+ while(1) {
+ ...
+ if(cond) MSG_task_execute(T1);
+ ...
+ if((MSG_task_get_remaining_computation(T1)=0.0) && (you_re_in_a_good_mood))
+ MSG_task_execute(T2)
+ else {
+ /* do something else */
+ }
+ }
+ }
+\endverbatim
+
+If you decide that the distributed part is not that much important and that
+DAG is really the level of abstraction you want to work with, then you should
+give a try to \ref SD_API.
+
\subsubsection faq_SG Where has SG disappeared?
OK, it's time to explain what's happening to the SimGrid project. Let's
an API rather close to the old SG:
\verbatim
-______________________
-| User code |
-|____________________|
-| | MSG | GRAS | SD |
-| -------------------|
-| | SURF |
-| -------------------|
-| XBT |
-----------------------
+_________________________
+| User code |
+|________________________|
+| | MSG | GRAS | SimDag |
+| -----------------------|
+| | SURF |
+| -----------------------|
+| XBT |
+--------------------------
\endverbatim
The nice thing is that, as it is writen on top of SURF, it seamlessly
patterns. Some old codes using SG are currently under rewrite using
\ref SD_API to check that all needful functions are provided.
-\subsubsection faq_SG_DAG How to implement a distributed dynamic scheduler of DAGs.
-
-Distributed is somehow "contagious". If you start making distributed
-decisions, there is no way to handle DAGs directly anymore (unless I
-am missing something). You have to encode your DAGs in term of
-communicating process to make the whole scheduling process
-distributed. Here is an example of how you could do that. Assume T1
-has to be done before T2.
-
-\verbatim
- int your_agent(int argc, char *argv[] {
- ...
- T1 = MSG_task_create(...);
- T2 = MSG_task_create(...);
- ...
- while(1) {
- ...
- if(cond) MSG_task_execute(T1);
- ...
- if((MSG_task_get_remaining_computation(T1)=0.0) && (you_re_in_a_good_mood))
- MSG_task_execute(T2)
- else {
- /* do something else */
- }
- }
- }
-\endverbatim
-
-If you decide that the distributed part is not that much important and that
-DAG is really the level of abstraction you want to work with, then you should
-give a try to \ref SD_API.
-
\subsection faq_MIA_generic Generic features
\subsubsection faq_more_processes Increasing the amount of simulated processes
planned because this is a very specific need (and doing it in a
generic way is thus very hard). However some people have implemented
their own batch schedulers. Vincent Garonne wrote one during his PhD
-and put his code in the contrib directory of our CVS so that other can
+and put his code in the contrib directory of our SVN so that other can
keep working on it. You may find inspinring ideas in it.
\subsubsection faq_MIA_checkpointing I need a checkpointing thing
bandwidth_file and latency_file do not express fraction of available
power but are expressed directly in bytes per seconds and seconds.
+\subsubsection faq_platform_multipath Is it possible to have several paths between two given hosts?
+
+The answer is no, unfortunately. Let's consider the following platform
+file:
+
+\verbatim
+<route src="A" dst="B">
+ <route_element name="1"/>
+</route>
+<route src="B" dst="C">
+ <route_element name="2"/>
+</route>
+<route src="A" dst="C">
+ <route_element name="3"/>
+</route>
+\endverbatim
+
+Althrough it is perfectly valid, it does not mean that data traveling
+from A to C can either go directly (using link 3) or through B (using
+links 1 and 2). It simply means that the routing on the graph is not
+trivial, and that data do not following the shortest path in number of
+hops on this graph. Another way to say it is that there is no implicit
+in these routing descriptions. The system will only use the routes you
+declare (such as <route src="A" dst="C"><route_element
+name="3"/></route>), without trying to build new routes by aggregating
+the provided ones.
+
+You are also free to declare platform where the routing is not
+symetric. For example, add the following to the previous file:
+
+\verbatim
+<route src="C" dst="A">
+ <route_element name="2"/>
+ <route_element name="1"/>
+</route>
+\endverbatim
+
+This makes sure that data from C to A go through B where data from A
+to C go directly. Do not worry about realism of such settings since
+we've seen ways more weird situation in real settings.
+
\subsubsection faq_flexml_bypassing Bypassing the XML parser with your own C functions
So you want to bypass the XML files parser, uh? Maybe doin some parameter
MSG_create_environment(NULL);
\endverbatim
-An example of this trick is distributed in the file examples/msg/msg_test_surfxml_bypassed.c
+An example of this trick is distributed in the file examples/msg/masterslave/masterslave_bypass.c
\section faq_troubleshooting Troubleshooting
-\subsection faq_trouble_compil Compilation and installation problems
+\subsection faq_trouble_lib_compil SimGrid compilation and installation problems
-\subsubsection faq_trouble_config ./configure fails!
+\subsubsection faq_trouble_lib_config ./configure fails!
We now only one reason for the configure to fail:
By default, SimGrid uses something called ucontexts. This is part of the
libc, but it's quite undertested. For example, some (old) versions of the
glibc on alpha do not implement these functions, but provide the stubs
- (which return ENOSYS: not implemented). It fools our detection mecanism
+ (which return ENOSYS: not implemented). It may fool our detection mecanism
and leads to segfaults. There is not much we can do to fix the bug.
A workaround is to compile with --with-context=pthread to avoid
ucontext completely. You'll be a bit more limitated in the number
that we can check it out. Make sure to read \ref faq_bugrepport
before you do so.
-\subsection faq_trouble_errors Understanding error messages
+\subsection faq_trouble_compil User code compilation problems
\subsubsection faq_trouble_err_logcat "gcc: _simgrid_this_log_category_does_not_exist__??? undeclared (first use in this function)"
for all the details, but you simply forgot to call one of
XBT_LOG_NEW_DEFAULT_CATEGORY() or XBT_LOG_NEW_DEFAULT_SUBCATEGORY().
+\subsubsection faq_trouble_pthreadstatic "gcc: undefinded reference to pthread_key_create"
+
+This indicates that one of the library SimGrid depends on (libpthread
+here) was missing on the linking command line. Dependencies of
+libsimgrid are expressed directly in the dynamic library, so it's
+quite impossible that you see this message when doing dynamic linking.
+
+If you compile your code statically (and if you use a pthread version
+of SimGrid -- see \ref faq_more_processes), you must absolutely
+specify <tt>-lpthread</tt> on the linker command line. As usual, this should
+come after <tt>-lsimgrid</tt> on this command line.
+
+\subsection faq_trouble_errors Runtime error messages
+
\subsubsection faq_flexml_limit "surf_parse_lex: Assertion `next limit' failed."
This is because your platform file is too big for the parser.
<platform_description version="1">
\endverbatim
You should try to use the surfxml_update.pl script that can be found
-<a href="http://gforge.inria.fr/plugins/scmcvs/cvsweb.php/contrib/platform_generation/?cvsroot=cvsroot%2Fsimgrid">here</a>.
+<a href="https://gforge.inria.fr/plugins/scmsvn/viewcvs.php/contrib/trunk/platform_generation/?rev=4721&root=simgrid"">here</a>.
\subsection faq_trouble_valgrind Valgrind-related issues
If you don't, you really should use valgrind to debug your code, it's
almost magic.
+\subsubsection faq_trouble_vg_context Stack switching problems and truncated backtraces
+
+With the default version of simgrid, valgrind will probably spit tons
+of warnings about stack switching like the following, and produce
+truncated bactraces where only one call appears instead of the whole
+stack.
+
+\verbatim
+==14908== Warning: client switching stacks? SP change: 0xBEA2A48C --> 0x476F350
+==14908== to suppress, use: --max-stackframe=1171541700 or greater
+==14908== Warning: client switching stacks? SP change: 0x476E1E4 --> 0xBEA2A48C
+==14908== to suppress, use: --max-stackframe=1171537240 or greater
+==14908== Warning: client switching stacks? SP change: 0xBEA2A48C --> 0x4792420
+==14908== to suppress, use: --max-stackframe=1171685268 or greater
+==14908== further instances of this message will not be shown.
+\endverbatim
+
+This is because valgrind don't like too much the UNIX98 contextes we
+use by default in simgrid for efficiency reasons. Simply add the
+--with-pthread flag to your configure when debugging your code. You
+may also find --disable-compiler-optimization usefull if valgrind or
+gdb get fooled by the optimization done by the compiler. But you
+should remove these flages when everything works before going in
+production (before launching your 1252135 experiments), or everything
+will run only one third of the true SimGrid potential.
+
\subsubsection faq_trouble_vg_longjmp longjmp madness in valgrind
This is when valgrind starts complaining about longjmp things, just like:
