X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/8400efb989370b37b801ed83f85384040a457278..3f0cae3446fd30a51edafc8c73c56b95d6f10802:/doc/FAQ.doc diff --git a/doc/FAQ.doc b/doc/FAQ.doc index aab3da423a..d0f8e1233c 100644 --- a/doc/FAQ.doc +++ b/doc/FAQ.doc @@ -23,7 +23,8 @@ 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. +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 @@ -202,8 +203,7 @@ archive you may deploy on other sites just as a regular stable release. In summary, the following commands will checkout the SVN, regenerate the configure script and friends, configure SimGrid and build it. -\verbatim svn checkout svn://scm.gforge.inria.fr/svn/simgrid/simgrid/trunk -mv trunk simgrid +\verbatim svn checkout svn://scm.gforge.inria.fr/svn/simgrid/simgrid/trunk simgrid cd simgrid ./bootstrap ./configure --enable-maintainer-mode --prefix= @@ -637,111 +637,6 @@ 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. -\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 @@ -842,16 +737,48 @@ subtasks. \subsection faq_platform Platform building and Dynamic resources -\subsubsection faq_platform Building a realistic platform +\subsubsection faq_platform_example Where can I find SimGrid platform files? + +There is 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 any at hand right now. + +We do have a description of the Grid'5000 platform, but because of +some flaws in the current formalism, this file is actually 500Mb, +which is ways too big to be used in the parser. We have an internship +currently working on xml syntax improvements which will allow to +reduce the size of this file and release it. + +Once it's done, we plan to model manually other existing platforms the +same way we did for G5K and also release those files in some sort of +SimGrid platform catalog project. -We can speak more than an hour on this subject and we still do not have -the right answer, just some ideas. You can read the following +\subsubsection faq_platform_alnem How can I automatically map an existing platform? + +We are working on a project called ALNeM (Application-Level Network +Mapper) which goal is to automatically discover the topology of an +existing network. Its output will be a platform description file +following the SimGrid syntax, so everybody will get the ability to map +their own lab network (and contribute them to the catalog project). +This tool is not ready yet, but it move quite fast forward. Just stay +tuned. + +\subsubsection faq_platform_synthetic Generating synthetic but realistic platforms + +The third possibility to get a platform file (after manual or +automatic mapping of real platforms) is to generate synthetic +platforms. Getting a realistic result is not a trivial task, and +moreover, nobody is really able to define what "realistic" means when +speaking of topology files. You can find some more thoughts on this +topic in these slides. -It may give you some hints. You can also have a look at the -tools/platform_generation/ directory. There is a perl-script -we use to annotate a Tiers generated platform. -\subsubsection faq_SURF_dynamic Building a dynamic platform, with resource availability +If you are looking for an actual tool, there we have a little tool to +annotate Tiers-generated topologies. This perl-script is in +tools/platform_generation/ directory of the SVN. Dinda et Al. +released a very comparable tool, and called it GridG. + +\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 @@ -907,10 +834,11 @@ 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 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 @@ -945,8 +873,10 @@ symetric. For example, add the following to the previous file: \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