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
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
<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 Building a dynamic platform, with resource availability
+\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/masterslave/masterslave_bypass.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
