X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/5425a82cd81e3ef2c24d6e75027954a04dce1735..40bdb11e84c563daed9fcd3d81e7ad5971f3367b:/doc/FAQ.doc diff --git a/doc/FAQ.doc b/doc/FAQ.doc index 0aac3fa350..16712f6710 100644 --- a/doc/FAQ.doc +++ b/doc/FAQ.doc @@ -11,8 +11,10 @@ not familiar with compiling C files under UNIX. If you follow these instructions and still have some troubles, drop an e-mail to . -\subsection faq_compiling Compiling SimGrid +\subsection faq_compiling Compiling SimGrid from an archive +First of all, you need to download the latest version of SimGrid from +here. Suppose you have uncompressed SimGrid in some temporary location of your home directory (say /home/joe/tmp/simgrid-3.0.1 ). The simplest way to use SimGrid is to install it in your home @@ -63,6 +65,49 @@ Thus, there is two ways to link your program with SimGrid: \verbatim export LD_LIBRARY_PATH=$HOME/lib/:$LD_LIBRARY_PATH \endverbatim + +\subsection faq_compiling_cvs Compiling SimGrid from the CVS + +The project development takes place in the cvs, where all changes are +commited when they happen. Then every once in a while, we make sure that the +code quality meets our standard and release an archive from the code in the +CVS. We afterward go back to the development in the CVS. So, if you need a +recently added feature and can afford some little problem with the stability +of the lastest features, you may want to use the CVS version instead of a +released one. + +For that, you first need to get the "simgrid" module from +here. + +You won't find any configure and a few other things +(Makefile.in's, documentation, ...) will be missing as +well. The reason for that is that all these files have to be +regenerated using the latest versions of autoconf, +automake (1.9) and doxygen. To generate the +configure and the Makefile.in's, you just have to +launch the bootstrap 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 +(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. + +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. + +\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 + \subsection faq_setting Setting up your own code Do not build your simulator by modifying the SimGrid examples. Go @@ -145,7 +190,9 @@ perform some more complex compilations... \section faq_simgrid I'm new to SimGrid. I have some questions. Where should I start? You are at the right place... Having a look to these -slides +slides +(or to these +"obsolete" slides) 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: . @@ -794,7 +841,8 @@ Here are some tricks I had to use in order to run a token ring between - It was really boring to write 25,000 entries in the deployment file, so I wrote a little script examples/gras/tokenS/make_deployment.pl, which you may - want to adapt to your case. + want to adapt to your case. You could also think about hijacking + the SURFXML parser (have look at \ref faq_flexml_bypassing). - The deployment file became quite big, so I had to do what is in the FAQ entry \ref faq_flexml_limit @@ -881,6 +929,47 @@ 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. +\subsection faq_gras_transport GRAS spits networking error messages + +Gras, on real platforms, naturally use regular sockets to communicate. They +are deeply hiden in the gras abstraction, but when things go wrong, you may +get some weird error messages. Here are some example, with the probable +reason: + + - Transport endpoint is not connected: several processes try to open + a server socket on the same port number of the same machine. This is + naturally bad and each process should pick its own port number for this.\n + Maybe, you just have some processes remaining from a previous experiment + on your machine.\n + Killing them may help, but again if you kill -KILL them, you'll have to + wait for a while: they didn't close there sockets properly and the system + needs a while to notice that this port is free again. + + - Socket closed by remote side: if the remote process is not + supposed to close the socket at this point, it may be dead. + + - Connection reset by peer: I found this on internet about this + error. I think it's what's happening here, too:\n + This basically means that a network error occurred while the client was + receiving data from the server. But what is really happening is that the + server actually accepts the connection, processes the request, and sends + a reply to the client. However, when the server closes the socket, the + client believes that the connection has been terminated abnormally + because the socket implementation sends a TCP reset segment telling the + client to throw away the data and report an error.\n + Sometimes, this problem is caused by not properly closing the + input/output streams and the socket connection. Make sure you close the + input/output streams and socket connection properly. If everything is + closed properly, however, and the problem persists, you can work around + it by adding a one-second sleep before closing the streams and the + socket. This technique, however, is not reliable and may not work on all + systems.\n + Since GRAS sockets are closed properly (repeat after me: there is no bug + in GRAS), it is either that you are closing your sockets on server side + before the client get a chance to read them (use gras_os_sleep() to delay + the server), or the server died awfully before the client got the data. + + \subsection faq_deadlock There is a deadlock !!! Unfortunately, we cannot debug every code written in SimGrid. We