X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/ee2bb49eaa4b0a08d8569c3dabf1f3535c2f2b5c..3ae39088350ad665caa35db1731009d9e3f1bda2:/doc/FAQ.doc diff --git a/doc/FAQ.doc b/doc/FAQ.doc index 88960dbdaa..fd1a06c450 100644 --- 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: . +\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 @@ -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? -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() { @@ -754,10 +786,10 @@ PERIODICITY 1.0 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 @@ -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 -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? @@ -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. +Update: 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