With SimDag, you express your code as a collection of interdependent
parallel tasks. So, in this model, applications can be seen as a DAG of
-tasks.
+tasks. This is the interface of choice for people wanting to port old
+code designed for SimGrid v1 or v2 to the lastest framework.
With both GRAS and MSG, your application is seen as a set of communicating
processes, exchanging data by the way of messages and performing computation
\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 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
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
-start with a little bit of history.
-
-* Historically, SimGrid was a low-level toolkit for scheduling with
-classical models such as DAGs. That was SimGrid v.1.* aka SG, written
-by Henri Casanova. I (Arnaud) had been using it in its earliest
-versions during an internship at UCSD.
-
-Then we have realized that encoding distributed algorithm in SG was a
-real pain.
-
-* So we have built MSG on top of SG and have released SimGrid v.2.*. MSG
-offered a very basic API to encode a distributed application easily.
-However encoding MSG on top of SG was not really convenient and did not
-use the DAG part since the control of the task synchronization was done
-on top of MSG and no more in SG. We have been playing a little bit with
-MSG. We have realized that:
-
- \li 1) the platform modeling was quite flexible and could be "almost"
- automated (e.g. using random generator and post-annotations);
-
- \li 2) SG was the bottleneck because of the way we were using
- it. We needed to simulate concurrent transfers, complex load
- sharing mechanisms. Many optimizations (e.g. trace integration)
- were totally inefficient when combined with MSG and made extending SG
- to implement new sharing policies, parallel tasks models, or failures
- (many people were asking for these kind of features) a real pain;
-
- \li 3) the application modeling was not really easy. Even though the
- application modeling depends on people's applications, we thought
- we could improve things here. One of our target here was realistic
-distributed applications ranging from computer sensor networks like
-the NWS to peer-to-peer applications;
-
-* So we have been planning mainly two things for SimGrid 3:
-
- \li 1) I have proposed to get rid of SG and to re-implement a new kernel
- that would be faster and more flexible. That is what I did in the
-end of 2004: SURF. SURF is based on a fast max-min linear solver
-using O(1) data-structures. I have quickly replaced SG by SURF in
-MSG and the result has been that on the MSG example, the new
-version was more than 10 times faster while we had gain a lot of
-flexibility. I think I could still easily make MSG faster but I
-have to work on MSG now (e.g. using some of the O(1)
-data-structures I've been using to build SURF) since it has become
-the bottleneck. Some MSG functions have been removed from the API
-but they were mainly intended to build the platform by hand (they
-had appeared in the earliest versions of MSG) and were therefore
-not useful anymore since we are providing a complete mechanism to
-automatically build the platform and deploy the agents on it.;
-
- \li 2) GRAS is a new project Martin and I have come up with. The idea is
-to have a programming environment that let you program real
-distributed applications while letting you the ability to run it in
-the simulator without having to change the slightest line of your
-code. From the simulation point of view, GRAS performs the
-application modeling automatically... Up until now, GRAS works on
-top MSG for historical reasons but I'm going to make it work
-directly on top of SURF so that it can use all the flex and the
-speed provided by SURF.
-
-Those two things are working, but we want to make everything as clean as
-possible before releasing SimGrid v.3.
-
-So what about those nice DAGs we used to have in SimGrid v.1.? They're
-not anymore in SimGrid v.3. At least not in their original form... Let
-me recall you the way SimGrid 3 is organized:
-
-\verbatim
-________________
-| User code |
-|______________|
-| | MSG | GRAS |
-| -------------|
-| | SURF |
-| -------------|
-| XBT |
-----------------
-\endverbatim
-
-XBT is our tool box and now, you should have an idea of what the other
-ones are. As you can see, the primitive SG is not here
-anymore. However we have written a brand new and cleaner API for this
-purpose: \ref SD_API. It is built directly on top of SURF and provides
-an API rather close to the old SG:
-
-\verbatim
-_________________________
-| User code |
-|________________________|
-| | MSG | GRAS | SimDag |
-| -----------------------|
-| | SURF |
-| -----------------------|
-| XBT |
---------------------------
-\endverbatim
-
-The nice thing is that, as it is writen on top of SURF, it seamlessly
-support DAG of parallel tasks as well as complex communications
-patterns. Some old codes using SG are currently under rewrite using
-\ref SD_API to check that all needful functions are provided.
-
\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
\subsection faq_platform Platform building and Dynamic resources
-\subsubsection faq_platform Building a realistic platform
+\subsubsection faq_platform_example Where can I find SimGrid platform files?
+
+There is several little examples in the archive, in the examples/msg
+directory. From time to time, we are asked for other files, but we
+don't have any at hand right now.
+
+We do have a description of the Grid'5000 platform, but because of
+some flaws in the current formalism, this file is actually 500Mb,
+which is ways too big to be used in the parser. We have an internship
+currently working on xml syntax improvements which will allow to
+reduce the size of this file and release it.
+
+Once it's done, we plan to model manually other existing platforms the
+same way we did for G5K and also release those files in some sort of
+SimGrid platform catalog project.
+
+\subsubsection faq_platform_alnem How can I automatically map an existing platform?
+
+We are working on a project called ALNeM (Application-Level Network
+Mapper) which goal is to automatically discover the topology of an
+existing network. Its output will be a platform description file
+following the SimGrid syntax, so everybody will get the ability to map
+their own lab network (and contribute them to the catalog project).
+This tool is not ready yet, but it move quite fast forward. Just stay
+tuned.
+
+\subsubsection faq_platform_synthetic Generating synthetic but realistic platforms
-We can speak more than an hour on this subject and we still do not have
-the right answer, just some ideas. You can read the following
+The third possibility to get a platform file (after manual or
+automatic mapping of real platforms) is to generate synthetic
+platforms. Getting a realistic result is not a trivial task, and
+moreover, nobody is really able to define what "realistic" means when
+speaking of topology files. You can find some more thoughts on this
+topic in these
<a href="http://graal.ens-lyon.fr/~alegrand/articles/Simgrid-Introduction.pdf">slides</a>.
-It may give you some hints. You can also have a look at the
-<tt>tools/platform_generation/</tt> directory. There is a perl-script
-we use to annotate a Tiers generated platform.
-\subsubsection faq_SURF_dynamic Building a dynamic platform, with resource availability
+If you are looking for an actual tool, there we have a little tool to
+annotate Tiers-generated topologies. This perl-script is in
+<tt>tools/platform_generation/</tt> directory of the SVN. Dinda et Al.
+released a very comparable tool, and called it GridG.
+
+\subsubsection faq_SURF_dynamic Expressing dynamic resource availability in platform files
A nice feature of SimGrid is that it enables you to seamlessly have
resources whose availability change over time. When you build a
-platform, you generally declare CPUs like that:
+platform, you generally declare hosts like that:
\verbatim
- <cpu name="Cpu A" power="100.00"/>
+ <host id="host A" power="100.00"/>
\endverbatim
-If you want the availability of "CPU A" to change over time, the only
+If you want the availability of "host A" to change over time, the only
thing you have to do is change this definition like that:
\verbatim
- <cpu name="Cpu A" power="100.00" availability_file="trace_A.txt" state_file="trace_A_failure.txt"/>
+ <host id="host A" power="100.00" availability_file="trace_A.txt" state_file="trace_A_failure.txt"/>
\endverbatim
-For CPUs, availability files are expressed in fraction of available
+For hosts, availability files are expressed in fraction of available
power. Let's have a look at what "trace_A.txt" may look like:
\verbatim
20.0 0.9
\endverbatim
-At time 0, our CPU will deliver 100 flop/s. At time 11.0, it will
+At time 0, our host will deliver 100 flop/s. At time 11.0, it will
deliver only 50 flop/s until time 20.0 where it will will start
delivering 90 flop/s. Last at time 21.0 (20.0 plus the periodicity
1.0), we'll be back to the beginning and it will deliver 100 flop/s.
\endverbatim
A negative value means "off" while a positive one means "on". At time
-1.0, the CPU is on. At time 1.0, it is turned off and at time 2.0, it
+1.0, the host is on. At time 1.0, it is turned off and at time 2.0, it
is turned on again until time 12 (2.0 plus the periodicity 10.0). It
will be turned on again at time 13.0 until time 23.0, and so on.
links. A usual declaration looks like:
\verbatim
- <network_link name="LinkA" bandwidth="10.0" latency="0.2"/>
+ <link id="LinkA" bandwidth="10.0" latency="0.2"/>
\endverbatim
You have at your disposal the following options: bandwidth_file,
-latency_file and state_file. The only difference with CPUs is that
+latency_file and state_file. The only difference with hosts is that
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?
+\subsubsection faq_platform_multipath How to express multipath routing in platform files?
-The answer is no, unfortunately. Let's consider the following platform
-file:
+It is unfortunately impossible to express the fact that there is more
+than one routing path between two given hosts. Let's consider the
+following platform file:
\verbatim
<route src="A" dst="B">
- <route_element name="1"/>
+ <link:ctn id="1"/>
</route>
<route src="B" dst="C">
- <route_element name="2"/>
+ <link:ctn id="2"/>
</route>
<route src="A" dst="C">
- <route_element name="3"/>
+ <link:ctn id="3"/>
</route>
\endverbatim
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
+declare (such as <route src="A" dst="C"><link:ctn
+id="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
\verbatim
<route src="C" dst="A">
- <route_element name="2"/>
- <route_element name="1"/>
+ <link:ctn id="2"/>
+ <link:ctn id="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.
+to C go directly. Don't worry about realism of such settings since
+we've seen ways more weird situation in real settings (in fact, that's
+the realism of very regular platforms which is questionable, but
+that's another story).
\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
-sweep experiments on your simulations or so? This is possible, but it's not
-really easy. Here is how it goes.
+sweep experiments on your simulations or so? This is possible, and
+it's not even really difficult (well. Such a brutal idea could be
+harder to implement). Here is how it goes.
For this, you have to first remember that the XML parsing in SimGrid is done
using a tool called FleXML. Given a DTD, this gives a flex-based parser. If
well-formed SimGrid platform XML file might result in the following
"events":
- - start "platform_description"
- - start "cpu" with attributes name="host1" power="1.0"
- - end "cpu"
- - start "cpu" with attributes name="host2" power="2.0"
- - end "cpu"
- - start "network_link" with ...
- - end "network_link"
- - start "route" with ...
- - end "route"
+ - start "platform_description" with attribute version="2"
+ - start "host" with attributes id="host1" power="1.0"
+ - end "host"
+ - start "host" with attributes id="host2" power="2.0"
+ - end "host"
+ - start "link" with ...
+ - end "link"
- start "route" with ...
+ - start "link:ctn" with ...
+ - end "link:ctn"
- end "route"
- end "platform_description"
The communication from the parser to the SURF code uses two means:
Attributes get copied into some global variables, and a surf-provided
function gets called by the parser for each event. For example, the event
- - start "cpu" with attributes name="host1" power="1.0"
+ - start "host" with attributes id="host1" power="1.0"
-let the parser do the equivalent of:
+let the parser do something roughly equivalent to:
\verbatim
- strcpy("host1",A_cpu_name);
- A_cpu_power = 1.0;
- (*STag_cpu_fun)();
+ strcpy(A_host_id,"host1");
+ A_host_power = 1.0;
+ STag_host();
\endverbatim
In SURF, we attach callbacks to the different events by initializing the
-pointer functions to some the right surf functions. Example in
-workstation_KCCFLN05.c (surf_parse_open() ends up calling surf_parse()):
+pointer functions to some the right surf functions. Since there can be
+more than one callback attached to the same event (if more than one
+model is in use, for example), they are stored in a dynar. Example in
+workstation_ptask_L07.c:
\verbatim
- // Building the routes
+ /* Adding callback functions */
surf_parse_reset_parser();
- STag_route_fun=parse_route_set_endpoints;
- ETag_route_element_fun=parse_route_elem;
- ETag_route_fun=parse_route_set_route;
+ surfxml_add_callback(STag_surfxml_host_cb_list, &parse_cpu_init);
+ surfxml_add_callback(STag_surfxml_prop_cb_list, &parse_properties);
+ surfxml_add_callback(STag_surfxml_link_cb_list, &parse_link_init);
+ surfxml_add_callback(STag_surfxml_route_cb_list, &parse_route_set_endpoints);
+ surfxml_add_callback(ETag_surfxml_link_c_ctn_cb_list, &parse_route_elem);
+ surfxml_add_callback(ETag_surfxml_route_cb_list, &parse_route_set_route);
+
+ /* Parse the file */
surf_parse_open(file);
- xbt_assert1((!surf_parse()),"Parse error in %s",file);
+ xbt_assert1((!surf_parse()), "Parse error in %s", file);
surf_parse_close();
\endverbatim
So, to bypass the FleXML parser, you need to write your own version of the
surf_parse function, which should do the following:
- - Call the corresponding STag_<tag>_fun function to simulate tag start
- Fill the A_<tag>_<attribute> variables with the wanted values
+ - Call the corresponding STag_<tag>_fun function to simulate tag start
- Call the corresponding ETag_<tag>_fun function to simulate tag end
- (do the same for the next set of values, and loop)
Then, tell SimGrid that you want to use your own "parser" instead of the stock one:
\verbatim
- surf_parse = surf_parse_bypass;
+ surf_parse = surf_parse_bypass_environment;
MSG_create_environment(NULL);
+ surf_parse = surf_parse_bypass_application;
+ MSG_launch_application(NULL);
\endverbatim
-An example of this trick is distributed in the file examples/msg/msg_test_surfxml_bypassed.c
+A set of macros are provided at the end of
+include/surf/surfxml_parse.h to ease the writing of the bypass
+functions. 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:
