X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/a51b0592d154aeb047e32e94240613535d79eed1..4e936ea2a66fc4a22ae23f96baa68cc0f55f870f:/doc/FAQ.doc diff --git a/doc/FAQ.doc b/doc/FAQ.doc index 0cddc2983d..fd1a06c450 100644 --- a/doc/FAQ.doc +++ b/doc/FAQ.doc @@ -89,23 +89,36 @@ command that resides in the top of the source tree. Then just follow the instructions of Section \ref faq_compiling. We insist on the fact that you really need the latest versions of -autoconf and automake. Doing this step on exotic architectures/systems +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 want to use the CVS version on another -architecture/system, you should do the previous steps on a perfectly -standard box, then do a make dist that will build you a -perfectly portable SimGrid archive. +... uncertain. If you need to compile the CVS version on a machine where all these +dependencies are not met, the easiest is to do make dist in the CVS +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 -configure script and friends, configure SimGrid and build an archive you can -use on another machine afterward. +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 cd simgrid ./bootstrap -./configure --enable-maintainer-mode -make dist \endverbatim +./configure --enable-maintainer-mode --prefix= +make \endverbatim + +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 +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 +to call them explicitely. + \subsection faq_setting_MSG Setting up your own MSG code @@ -238,11 +251,12 @@ in the meanwhile, simply don't build the examples in cross-compilation 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 cp /usr/share/doc/mingw32-runtime/mingwm10.dll.gz ~/.wine/c/windows/system/ +\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 builded in src/.libs, and installed in the /bin directory +The DLL is builded in src/.libs, and installed in the prefix/bin directory when you run make install. If you want to use it in a native project on windows, you need to use @@ -253,18 +267,26 @@ generate the def files, run (under linux): \verbatim echo "LIBRARY libsimgrid-0.dll" > simgrid.def echo EXPORTS >> simgrid.def nm libsimgrid-0.dll | grep ' T _' | sed 's/.* T _//' >> simgrid.def +nm libsimgrid-0.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> simgrid.def echo "LIBRARY mingwm10.dll" > mingwm10.def echo EXPORTS >> mingwm10.def nm mingwm10.dll | grep ' T _' | sed 's/.* T _//' >> mingwm10.def +nm mingwm10.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> mingwm10.def \endverbatim -To create the import .lib files, use the lib windows tool the -following way to produce simgrid.lib and mingwm10.lib +To create the import .lib files, use the lib windows tool (from +MSVC) the following way to produce simgrid.lib and mingwm10.lib \verbatim lib /def:simgrid.def lib /def:mingwm10.def \endverbatim +If you happen to use Borland C Builder, the right command line is the +following (note that you don't need any file.def to get this working). +\verbatim implib simgrid.lib libsimgrid-0.dll +implib mingwm10.lib mingwm10.dll +\endverbatim + Then, set the following parameters in Visual C++ 2005: Linker -> Input -> Additional dependencies = simgrid.lib mingwm10.lib @@ -291,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 @@ -458,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() { @@ -481,6 +535,42 @@ Of course, it may not match your personal definition of "host load". In this case, please detail what you mean on the mailing list, and we will extend this FAQ section to fit your taste if possible. +\subsection 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 +time and the time spent to really communicate (it will also take into +account the time spent waiting for the other party to be +ready). However, getting the *real* communication time is not really +hard either. The following solution is a good starting point. + +\verbatim +int sender() +{ + 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); + INFO0("Send completed"); + return 0; +} +int receiver() +{ + m_task_t task = NULL; + double time1,time2; + + time1 = MSG_get_clock(); + a = MSG_task_get(&(task), PORT_22); + time2 = MSG_get_clock(); + if(time1<*((double *)task->data)) + time1 = *((double *) task->data); + INFO1("Communication time : \"%f\" ", time2-time1); + free(task->data); + MSG_task_destroy(task); + return 0; +} +\endverbatim + \subsection faq_MIA_batch_scheduler Is there a native support for batch schedulers in SimGrid ? No, there is no native support for batch schedulers and none is @@ -696,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 @@ -723,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? @@ -1015,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