update the mmrpc example to adapt to the changes in the matrix module (which is still...

[simgrid.git] / doc / FAQ.doc

diff --git a/doc/FAQ.doc b/doc/FAQ.doc
index 88960db..fd1a06c 100644 (file)
--- a/doc/FAQ.doc
+++ b/doc/FAQ.doc
@@ -313,6 +313,30 @@ may give you some insights on what SimGrid can help you to do and what
 are its limitations. Then you definitely should read the \ref
 MSG_examples. There is also a mailing list: <simgrid-user@lists.gforge.inria.fr>.
 
 are its limitations. Then you definitely should read the \ref
 MSG_examples. There is also a mailing list: <simgrid-user@lists.gforge.inria.fr>.
 

+\subsection faq_interfaces What is the difference between MSG, SimDag, and GRAS? Do they serve the same purpose?
+
+It depend on how you define "purpose", I guess ;)
+
+They all allow you to build a prototype of application which you can run
+within the simulator afterward. They all share the same simulation kernel,
+which is the core of the SimGrid project. They differ by the way you express
+your application.
+
+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. 
+
+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
+on their own.
+
+The difference between both is that MSG is somehow easier to use, but GRAS
+is not limitated to the simulator. Once you're done writing your GRAS code,
+you can run your code both in the simulator or on a real platform. For this,
+there is two implementations of the GRAS interface, one for simulation, one
+for real execution. So, you just have to relink your code to chose one of
+both world.
+

 \subsection faq_generic Building a generic simulator
 
 Please read carefully the \ref MSG_examples. You'll find in \ref
 \subsection faq_generic Building a generic simulator
 
 Please read carefully the \ref MSG_examples. You'll find in \ref


@@ -480,12 +504,20 @@ even take the currently running tasks into account. In some SURF models,
 communications have an influence on computational power. Should it be taken
 into account too?
 
 communications have an influence on computational power. Should it be taken
 into account too?
 

-So, we decided not to include such a function into MSG and let people do it
-thereselves so that they get the value matching exactly what they mean. One
-possibility is to run active measurement 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. 
+First of all, it's near to impossible to predict the load beforehands in the
+simulator since it depends on too much parameters (background load
+variation, bandwidth sharing algorithmic complexity) some of them even being
+not known beforehands (other task starting at the same time). So, getting
+this information is really hard (just like in real life). It's not just that
+we want MSG to be as painful as real life. But as it is in some way
+realistic, we face some of the same problems as we would face in real life.
+
+How would you do it for real? The most common option is to use something
+like NWS that performs active probes. The best solution is probably to do
+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. 

 
 \verbatim
 double get_host_load() {
 
 \verbatim
 double get_host_load() {


@@ -754,10 +786,10 @@ PERIODICITY 1.0
 20.0 0.9
 \endverbatim
 
 20.0 0.9
 \endverbatim
 

-At time 0, our CPU will deliver 100 Mflop/s. At time 11.0, it will
-deliver only 50 Mflop/s until time 20.0 where it will will start
-delivering 90 Mflop/s. Last at time 21.0 (20.0 plus the periodicity
-1.0), we'll be back to the beginning and it will deliver 100Mflop/s.
+At time 0, our CPU 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.

 
 Now let's look at the state file:
 \verbatim
 
 Now let's look at the state file:
 \verbatim


@@ -781,7 +813,7 @@ links. A usual declaration looks like:
 You have at your disposal the following options: bandwidth_file,
 latency_file and state_file. The only difference with CPUs is that
 bandwidth_file and latency_file do not express fraction of available
 You have at your disposal the following options: bandwidth_file,
 latency_file and state_file. The only difference with CPUs is that
 bandwidth_file and latency_file do not express fraction of available

-power but are expressed directly in Mb/s and seconds.
+power but are expressed directly in bytes per seconds and seconds.

 
 \subsection faq_flexml_bypassing How can I have some C functions do what the platform file does?
 
 
 \subsection faq_flexml_bypassing How can I have some C functions do what the platform file does?
 


@@ -1073,6 +1105,17 @@ These are changes to FleXML itself, not SimGrid. But since we kinda hijacked
 the development of FleXML, I can grant you that any patches would be really
 welcome and quickly integrated.
 
 the development of FleXML, I can grant you that any patches would be really
 welcome and quickly integrated.
 

+<b>Update:</b> A new version of FleXML (1.7) was released. Most of the work
+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
+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 repare the bypassing
+functionnality to use the lastest FleXML version and fix the memory usage in
+SimGrid.
+

 \subsection faq_gras_transport GRAS spits networking error messages
 
 Gras, on real platforms, naturally use regular sockets to communicate. They
 \subsection faq_gras_transport GRAS spits networking error messages
 
 Gras, on real platforms, naturally use regular sockets to communicate. They