/*! \page faq Frequently Asked Questions
-\author Arnaud Legrand <arnaud.legrand@imag.fr>
+\author Arnaud Legrand <arnaud.legrand#imag.fr>
\section faq_installation Installing the SimGrid library
often, the questions were not really about SimGrid but on the
installation process. This section is intended to help people that are
not familiar with compiling C files under UNIX. If you follow these
-instructions and still have some troubles, drop me an e-mail.
+instructions and still have some troubles, drop an e-mail to
+<simgrid-user@lists.gforge.inria.fr>.
\subsection faq_compiling Compiling SimGrid
href="http://graal.ens-lyon.fr/~alegrand/articles/Simgrid-Introduction.pdf">slides</a>
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.
+MSG_examples. There is also a mailing list: <simgrid-user#lists.gforge.inria.fr>.
\subsection faq_generic Building a generic simulator
-Please read carefully the \ref MSG_examples.
-
- \li Start by reading \ref masterslave1.c. It is the most
- complicated example since all the platform and all the
- deployment are done directly in the code.
-
- \li As you may notice, building a big platform with functions like
- MSG_host_create() and MSG_link_create() is quite boring. That
- is why it is possible to import a complex platform with
- MSG_create_environment(). Have a look at \ref masterslave2.c
- and look at the differences with the previous version.
-
- \li Now, deploying your application on an extern platform is not
- really convenient either. Having an external way of specifying
- which agents should be run on which machine would be much more
- convenient. That is why MSG_launch_application() has been
- designed for. Have a look at \ref masterslave3.c and look at
- the differences with the previous versions. Much more clean and
- simple, isnt'it ? In fact, all the complexity of the deployment
- that was in the test_all function of \ref masterslave1.c has
- been moved to more generic functions : unix_emitter() and
- unix_receiver().
+Please read carefully the \ref MSG_examples. You'll find in \ref
+MSG_ex_master_slave a very simple consisting of a master (that owns a bunch of
+tasks and distributes them) , some slaves (that process tasks whenever
+they receive one) and some forwarder agents (that simply pass the
+tasks they receive to some slaves).
\subsection faq_examples I want some more complex examples !
\subsection faq_visualization Visualizing the schedule
It is sometime convenient to "see" how the agents are behaving. If you
-like colors, you can use <tt>tools/colorize.pl</tt> as a filter to you
-MSG outputs. It is intended to work with the output generated by
-PRINT_MESSAGE() (a macro defined in
-<tt>example/msg/messages.h</tt>). Beware, PRINT_MESSAGE() prints on
-stderr. Do not forget to redirect if you want to filter (e.g. with
-bash):
-\verbatim ./masterslave3 platform.txt deployment.txt 2>&1 | ../../tools/colorize.pl \endverbatim
-
-That would be great to have something more graphical. As soon as I'll
-have a little bit more time, I will write a piece of code that
+like colors, you can use <tt>tools/MSG_visualization/colorize.pl </tt>
+as a filter to your MSG outputs. It works directly with INFO. Beware,
+INFO() prints on stderr. Do not forget to redirect if you want to
+filter (e.g. with bash):
+\verbatim
+./msg_test small_platform.xml small_deployment.xml 2>&1 | ../../tools/MSG_visualization/colorize.pl
+\endverbatim
+
+We also have a more graphical output. Have a look at MSG_paje_output(). It
generates an input to <a href="http://www-id.imag.fr/Logiciels/paje/">Paje</a>.
+<center>
+\htmlonly
+ <a href="Paje_MSG_screenshot.jpg"><img src="Paje_MSG_screenshot_thn.jpg"></a>
+\endhtmlonly
+</center>
\subsection faq_context I have tons of process and it is limiting my simulation.
is not very clean. As usual, as soon as I will have a little bit more
time, I will recode it in a cleaner way.
-\section faq_stupid Stupid Questions
-
-\subsection faq_GridSim Are SimGrid and GridSim the same ?
-
-Are you kidding ? SimGrid is plain C and GridSim is written in
-Java... I'm sarcastic but I'm pissed of all these poeple arguing that
-their software is well-structured and higly portable thanks to Java. A
-C program can also be structured in an object-oriented way and be
-highly portable (just try to run Java on IRIX... ;).
-
-According to different published papers, both SimGrid and GridSim seem
-to have the same kind of goal but I have never succeeded in compiling
-GridSim (but I may not be very objective since I always have troubles
-when trying to run java programs) and its documentation has not
-enlightened me. If you have suceeded and can tell me more about it,
-please tell me.
-
-\subsection faq_stupid_MSG What is MSG and why do you like it ?
+\section 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 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. Let me recall you the way SimGrid 3 is organized:
-Monosodium glutamate (MSG) is used as a flavor enhancer in a variety
-of foods prepared at home, in restaurants, and by food processors. Its
-use has become controversial in the past 30 years because of reports of
-adverse reactions in people who've eaten foods that contain MSG. Research
-on the role of glutamate--a group of chemicals that includes MSG--in the
-nervous system also has raised questions about the chemical's safety.
-
-For more information, see http://www.truthinlabeling.org/ or
-http://www.msg.net/
+\verbatim
+________________
+| User code |
+|______________|
+| | MSG | GRAS |
+| -------------|
+| | SURF |
+| -------------|
+| XBT |
+----------------
+\endverbatim
-It also stands for Meta-SimgGrid. It is a simulator written on top of
-Simgrid that can be used to easily simulate many process running on a
-computing platform.
+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 it could
+still be brought back if people really need it. Here is how it would fit.
-I also like it because it gives flavor and it's addictive. ;)
+\verbatim
+______________________
+| User code |
+|____________________|
+| | MSG | GRAS | SG |
+| -------------------|
+| | SURF |
+| -------------------|
+| XBT |
+----------------------
+\endverbatim
-*/
\ No newline at end of file
+Re-implementing SG on top of SURF is really straightforward (it only
+requires a little bit of time that I really don't have right now)
+since the only thing that lacks to SURF is the DAG part. But adding it
+to SURF would slow it down and therefore slow MSG and GRAS which is
+not a good thing. However it is really not on the top of our TODO
+list because we have to work on GRAS, and its MPI counterpart, and a
+parallel task model, and ... Anyway, we finally have migrated our CVS
+to gforge so people that are interested by helping on this part will
+have the possibility to do it.
+
+\subsection But I wanted to implement a distributed dynamic scheduler of DAGs... How can I do that it SG is not available anymore in the next versions ?
+
+Distributed is somehow "contagious". If you start making distributed
+decisions, there is no way to handle DAGs directly anymore (unless I am
+missing something). You have to encode your DAGs in term of communicating
+process to make the whole scheduling process distributed. Believe me, it is
+worth the effort since you'll then be able to try your algorithms in a very
+wide variety of conditions.
+
+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 (but it
+prevents you from having "realistic" platform modeling), then you should
+keep using the 2.18.5 versions until somebody has ported SG on top of SURF.
+Note however that SURF will be slower than the old SG to handle traces with
+a lots of variations (there is no trace integration anymore).
+
+*/
