you can run your code both in the simulator and on a real platform. For this,
there are two implementations of the GRAS interface, one for simulation, and one
for real execution. So, you just have to relink your code to choose one of
-both worlds.
+both worlds.
\subsection faq_visualization Visualizing and analyzing the results
like colors, you can use <tt>tools/MSG_visualization/colorize.pl </tt>
as a filter to your MSG outputs. It works directly with INFO. Beware,
INFO() prints on stderr. Do not forget to redirect if you want to
-filter (e.g. with bash):
-\verbatim
+filter (e.g. with bash):
+\verbatim
./msg_test small_platform.xml small_deployment.xml 2>&1 | ../../tools/MSG_visualization/colorize.pl
\endverbatim
\subsection faq_C Argh! Do I really have to code in C?
-Currently bindings on top of MSG are supported for Java, Ruby and Lua. You can find a few
+Currently bindings on top of MSG are supported for Java, Ruby and Lua. You can find a few
documentation about them on the doc page. Note that bindings are released separately from the main dist
and so have their own version numbers.
Many people have come to ask me a more complex example and each time,
they have realized afterward that the basics were in the previous three
-examples.
+examples.
Of course they have often been needing more complex functions like
MSG_process_suspend(), MSG_process_resume() and
\subsubsection faq_MIA_asynchronous I want to do asynchronous communications in MSG
-In the past (version <= 3.4), there was no function to perform asynchronous communications.
-It could easily be implemented by creating new process when needed though. Since version 3.5,
+In the past (version <= 3.4), there was no function to perform asynchronous communications.
+It could easily be implemented by creating new process when needed though. Since version 3.5,
we have introduced the following functions:
- MSG_task_isend()
- MSG_task_irecv()
- MSG_comm_waitany()
- MSG_comm_destroy()
-We refer you to the description of these functions for more details on their usage as well
+We refer you to the description of these functions for more details on their usage as well
as to the example section on \ref MSG_ex_asynchronous_communications.
\subsubsection faq_MIA_thread_synchronization I need to synchronize my MSG processes
-You obviously cannot use pthread_mutexes of pthread_conds since we handle every
-scheduling related decision within SimGrid.
+You obviously cannot use pthread_mutexes of pthread_conds since we handle every
+scheduling related decision within SimGrid.
In the past (version <=3.3.4) you could do it by playing with
MSG_process_suspend() and MSG_process_resume() or with fake communications (using MSG_task_get(),
the same within MSG, as in next code snippet. It is very close from what you
would have to do out of the simulator, and thus gives you information that
you could also get in real settings to not hinder the realism of your
-simulation.
+simulation.
\verbatim
double get_host_load() {
case, please detail what you mean on the mailing list, and we will extend
this FAQ section to fit your taste if possible.
-\subsubsection faq_MIA_communication_time How can I get the *real* communication time?
+\subsubsection faq_MIA_communication_time How can I get the *real* communication time?
Communications are synchronous and thus if you simply get the time
before and after a communication, you'll only get the transmission
\verbatim
int sender()
{
- m_task_t task = MSG_task_create("Task", task_comp_size, task_comm_size,
+ m_task_t task = MSG_task_create("Task", task_comp_size, task_comm_size,
calloc(1,sizeof(double)));
*((double*) task->data) = MSG_get_clock();
MSG_task_put(task, slaves[i % slaves_count], PORT_22);
}
}
\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.
switch manually to the pthread version, and provide us with a good
patch for the configure script so that it is done automatically ;)
- - <b>Hundred thousands of simulated processes</b> (hard-core tricks)\n
+ - <b>Hundred thousands of simulated processes</b> (hard-core tricks)\n
As explained above, SimGrid can use UNIX98 contexts to represent
and handle the simulated processes. Thanks to this, the main
limitation to the number of simulated processes becomes the
file, so I wrote a little script
<tt>examples/gras/mutual_exclusion/simple_token/make_deployment.pl</tt>, which you may
want to adapt to your case. You could also think about hijacking
- the SURFXML parser (have look at \ref faq_flexml_bypassing).
+ the SURFXML parser (have look at \ref pf_flexml_bypassing).
- The deployment file became quite big, so I had to do what is in
the FAQ entry \ref faq_flexml_limit
- Each UNIX98 context has its own stack entry. As debugging this is
quite hairy, the default value is a bit overestimated so that
user doesn't get into trouble about this. You want to tune this
size to increase the number of processes. This is the
- <tt>STACK_SIZE</tt> define in
+ <tt>STACK_SIZE</tt> define in
<tt>src/xbt/xbt_context_sysv.c</tt>, which is 128kb by default.
Reduce this as much as you can, but be warned that if this value
is too low, you'll get a segfault. The token ring example, which
- is quite simple, runs with 40kb stacks.
+ is quite simple, runs with 40kb stacks.
- You may tweak the logs to reduce the stack size further. When
logging something, we try to build the string to display in a
char array on the stack. The size of this array is constant (and
sized buffer. In which case, we have to traverse one time the log
event arguments to compute the size we need for the buffer,
malloc it, and traverse the argument list again to do the actual
- job.\n
+ job.\n
The idea here is to move XBT_LOG_BUFF_SIZE to 1, forcing the logs
to use a dynamic array each time. This allows us to lower further
the stack size at the price of some performance loss...\n
\subsubsection faq_MIA_checkpointing I need a checkpointing thing
Actually, it depends on whether you want to checkpoint the simulation, or to
-simulate checkpoints.
+simulate checkpoints.
The first one could help if your simulation is a long standing process you
want to keep running even on hardware issues. It could also help to
<i>rewind</i> the simulation by jumping sometimes on an old checkpoint to
-cancel recent calculations.\n
+cancel recent calculations.\n
Unfortunately, such thing will probably never exist in SG. One would have to
duplicate all data structures because doing a rewind at the simulator level
is very very hard (not talking about the malloc free operations that might
There are 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 much at hand right now.
+don't have much at hand right now.
You should refer to the Platform Description Archive
(http://pda.gforge.inria.fr) project to see the other platform file we
<tt>tools/platform_generation/</tt> directory of the SVN. Dinda et Al.
released a very comparable tool, and called it GridG.
-\subsubsection faq_SURF_multicore Modeling multi-core resources
-
-Since version 3.6 of simgrid we can specify the core number of a resource.
-To use this feature use tag 'host' with 'core' attribute.
-\verbatim
-<?xml version='1.0'?>
-<!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">
-<platform version="3">
- <AS id="AS0" routing="Full">
- <host id="Tremblay" power="98095000" core="6"/>
- </AS>
-</platform>
-\endverbatim
The specified computing power will be available to up to 6 sequential
tasks without sharing. If more tasks are placed on this host, the
note that although sound, this model were never scientifically
assessed. Please keep this fact in mind when using it.
-\subsubsection faq_SURF_dynamic Modeling dynamic resource availability
-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 hosts like that:
-\verbatim
- <host id="host A" power="100.00"/>
-\endverbatim
-
-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
- <host id="host A" power="100.00" availability_file="trace_A.txt" state_file="trace_A_failure.txt"/>
-\endverbatim
-
-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
-PERIODICITY 1.0
-0.0 1.0
-11.0 0.5
-20.0 0.9
-\endverbatim
-
-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 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.
-
-Now let's look at the state file:
-\verbatim
-PERIODICITY 10.0
-1.0 -1.0
-2.0 1.0
-\endverbatim
-
-A negative value means "off" while a positive one means "on". At time
-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.
-
-Now, let's look how the same kind of thing can be done for network
-links. A usual declaration looks like:
-
-\verbatim
- <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 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 How to express multipath routing in platform files?
-
-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">
- <link_ctn id="1"/>
-</route>
-<route src="B" dst="C">
- <link_ctn id="2"/>
-</route>
-<route src="A" dst="C">
- <link_ctn id="3"/>
-</route>
-\endverbatim
-
-Although 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"><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
-symmetric. For example, add the following to the previous file:
-
-\verbatim
-<route src="C" dst="A">
- <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. 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 doing some parameter
-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
-you want to bypass the parser, you need to provide some code mimicking what
-it does and replacing it in its interactions with the SURF code. So, let's
-have a look at these interactions.
-
-FleXML parser are close to classical SAX parsers. It means that a
-well-formed SimGrid platform XML file might result in the following
-"events":
-
- - 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 "host" with attributes id="host1" power="1.0"
-
-let the parser do something roughly equivalent to:
-\verbatim
- 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. 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
- /* Adding callback functions */
- surf_parse_reset_parser();
- 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_assert(!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:
- - 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_environment;
- MSG_create_environment(NULL);
- surf_parse = surf_parse_bypass_application;
- MSG_launch_application(NULL);
-\endverbatim
-
-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
http://cdash.inria.fr/CDash/index.php?project=Simgrid (click on
previous if there is no result for today: results are produced only by
11am, French time) and
-https://buildd.debian.org/status/logs.php?pkg=simgrid if you don't believe us.
+https://buildd.debian.org/status/logs.php?pkg=simgrid if you don't believe us.
If it's failing on your machine in a way not experienced by the
autobuilders above, please drop us a mail on the mailing list so that
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.
+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.
+\subsubsection faq_trouble_lib_msg_deprecated "gcc: undefined reference to MSG_*"
+
+Since version 3.7 all the m_channel_t mecanism is deprecated. So functions
+about this mecanism may get removed in future releases.
+
+List of functions:
+
+\li XBT_PUBLIC(int) MSG_get_host_number(void);
+
+\li XBT_PUBLIC(m_host_t *) MSG_get_host_table(void);
+
+\li XBT_PUBLIC(MSG_error_t) MSG_get_errno(void);
+
+\li XBT_PUBLIC(MSG_error_t) MSG_task_get(m_task_t * task, m_channel_t channel);
+
+\li XBT_PUBLIC(MSG_error_t) MSG_task_get_with_timeout(m_task_t * task, m_channel_t channel, double max_duration);
+
+\li XBT_PUBLIC(MSG_error_t) MSG_task_get_from_host(m_task_t * task, int channel, m_host_t host);
+
+\li XBT_PUBLIC(MSG_error_t) MSG_task_get_ext(m_task_t * task, int channel, double max_duration, m_host_t host);
+
+\li XBT_PUBLIC(MSG_error_t) MSG_task_put(m_task_t task, m_host_t dest, m_channel_t channel);
+
+\li XBT_PUBLIC(MSG_error_t) MSG_task_put_bounded(m_task_t task, m_host_t dest, m_channel_t channel, double max_rate);
+
+\li XBT_PUBLIC(MSG_error_t) MSG_task_put_with_timeout(m_task_t task, m_host_t dest, m_channel_t channel, double max_duration);
+
+\li XBT_PUBLIC(int) MSG_task_Iprobe(m_channel_t channel);
+
+\li XBT_PUBLIC(int) MSG_task_probe_from(m_channel_t channel);
+
+\li XBT_PUBLIC(int) MSG_task_probe_from_host(int channel, m_host_t host);
+
+\li XBT_PUBLIC(MSG_error_t) MSG_set_channel_number(int number);
+
+\li XBT_PUBLIC(int) MSG_get_channel_number(void);
+
+If you want them you have to compile Simgrid v3.7 with option "-Denable_msg_deprecated=ON".
+Using them should print warning to inform what new function you have to use.
+
\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.
+This is because your platform file is too big for the parser.
Actually, the message comes directly from FleXML, the technology on top of
which the parser is built. FleXML has the bad idea of fetching the whole
was done by William Dowling, who use it in his own work. The good point is
that it now use a dynamic buffer, and that the memory usage was greatly
improved. The downside is that William also changed some things internally,
-and it breaks the hack we devised to bypass the parser, as explained in
-\ref faq_flexml_bypassing. Indeed, this is not a classical usage of the
+and it breaks the hack we devised to bypass the parser, as explained in
+\ref pf_flexml_bypassing. Indeed, this is not a classical usage of the
parser, and Will didn't imagine that we may have used (and even documented)
such a crude usage of FleXML. So, we now have to repair the bypassing
functionality to use the lastest FleXML version and fix the memory usage in
- <b>Transport endpoint is not connected</b>: several processes try to open
a server socket on the same port number of the same machine. This is
naturally bad and each process should pick its own port number for this.\n
- Maybe, you just have some processes remaining from a previous experiment
+ Maybe, you just have some processes remaining from a previous experiment
on your machine.\n
Killing them may help, but again if you kill -KILL them, you'll have to
wait for a while: they didn't close there sockets properly and the system
- <b>Socket closed by remote side</b>: if the remote process is not
supposed to close the socket at this point, it may be dead.
-
+
- <b>Connection reset by peer</b>: I found this on Internet about this
- error. I think it's what's happening here, too:\n
+ error. I think it's what's happening here, too:\n
<i>This basically means that a network error occurred while the client was
receiving data from the server. But what is really happening is that the
server actually accepts the connection, processes the request, and sends
\endverbatim
In more complex situations, this min is the solution of a complex
-max-min linear system. Have a look
+max-min linear system. Have a look
<a href="http://lists.gforge.inria.fr/pipermail/simgrid-devel/2006-April/thread.html">here</a>
and read the two threads "Bug in SURF?" and "Surf bug not
fixed?". You'll have a few other examples of such computations. You
also decide to open a formal bug report using the
<a href="https://gforge.inria.fr/tracker/?atid=165&group_id=12&func=browse">relevant
interface</a>. You need to login on the server to get the ability to submit
-bugs.
+bugs.
We will do our best to solve any problem repported, but you need to help us
finding the issue. Just telling "it segfault" isn't enough. Telling "It
http://www.chiark.greenend.org.uk/~sgtatham/bugs.html (it is not SimGrid
specific at all, but it's full of good advices).
-\author Arnaud Legrand (arnaud.legrand::imag.fr)
-\author Martin Quinson (martin.quinson::loria.fr)
-
+\author Da SimGrid team <simgrid-devel@lists.gforge.inria.fr>
*/
environment as distributed in Debian.
After that, you can run all make targets from both directories, and test
-easily that what you change for one arch does not break the other one.
+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
SVN since it's quite fragile, but it's granted to work in any released
-version. If you experience problems, drop us a mail.
+version. If you experience problems, drop us a mail.
Another possible source of issue is that at the moment, building the
examples request to use the gras_stub_generator tool, which is a compiled
wine for example, which is not really pleasant. We are working on this, but
in the meanwhile, simply don't build the examples in cross-compilation
(<tt>cd src</tt> before running make).
-
+
Program (cross-)compiled with mingw32 do request an extra DLL at run-time to be
usable. For example, if you want to test your build with wine, you should do
the following to put this library where wine looks for DLLs.
-\verbatim
+\verbatim
cp /usr/share/doc/mingw32-runtime/mingwm10.dll.gz ~/.wine/c/windows/system/
gunzip ~/.wine/c/windows/system/mingwm10.dll.gz
\endverbatim
The DLL is built in src/.libs, and installed in the <i>prefix</i>/bin directory
-when you run make install.
+when you run make install.
-If you want to use it in a native project on windows, you need to use
+If you want to use it in a native project on windows, you need to use
simgrid.dll and mingwm10.dll. For each DLL, you need to build .def file
under linux (listing the defined symbols), and convert it into a .lib file
under windows (specifying this in a way that windows compilers like). To
