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 <tt>make dist</tt> 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 <tt>make dist</tt> 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=<where to install SimGrid>
+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
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 <prefix>/bin directory
+The DLL is builded in src/.libs, and installed in the <i>prefix</i>/bin directory
when you run make install.
If you want to use it in a native project on windows, you need to use
\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 <tt>lib</tt> windows tool the
-following way to produce simgrid.lib and mingwm10.lib
+To create the import .lib files, use the <tt>lib</tt> 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
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
You should try to use the surfxml_update.pl script that can be found
<a href="http://gforge.inria.fr/plugins/scmcvs/cvsweb.php/contrib/platform_generation/?cvsroot=cvsroot%2Fsimgrid">here</a>.
-\subsection faq_bugrepport So I've found a bug in SimGrid. How to repport it?
+\subsection faq_surf_network_latency I get weird timings when I play with the latencies.
+
+OK, first of all, remember that units should be Bytes, Flops and
+Seconds. If you don't use such units, some SimGrid constants (e.g. the
+SG_TCP_CTE_GAMMA constant used in most network models) won't have the
+right unit and you'll end up with weird results.
+
+Here is what happens with a single transfer of size L on a link
+(bw,lat) when nothing else happens.
+
+\verbatim
+0-----lat--------------------------------------------------t
+|-----|**** real_bw =min(bw,SG_TCP_CTE_GAMMA/(2*lat)) *****|
+\endverbatim
+
+In more complex situations, this min is the solution of a complex
+max-min linear system. Have a look
+<a href="http://lists.gforge.inria.fr/pipermail/simgrid-devel/2006-April/thread.html">here</a>
+and read the two threads "Bug in SURF?" and "Surf bug not
+fixed?". You'll have a few other examples of such computations. You
+can also read "A Network Model for Simulation of Grid Application" by
+Henri Casanova and Loris Marchal to have all the details. The fact
+that the real_bw is smaller than bw is easy to understand. The fact
+that real_bw is smaller than SG_TCP_CTE_GAMMA/(2*lat) is due to the
+window-based congestion mechanism of TCP. With TCP, you can't exploit
+your huge network capacity if you don't have a good round-trip-time
+because of the acks...
+
+Anyway, what you get is t=lat + L/min(bw,SG_TCP_CTE_GAMMA/(2*lat)).
+
+ * if I you set (bw,lat)=(100 000 000, 0.00001), you get t = 1.00001 (you fully
+use your link)
+ * if I you set (bw,lat)=(100 000 000, 0.0001), you get t = 1.0001 (you're on the
+limit)
+ * if I you set (bw,lat)=(100 000 000, 0.001), you get t = 10.001 (ouch!)
+
+This bound on the effective bandwidth of a flow is not the only thing
+that may make your result be unexpected. For example, two flows
+competing on a saturated link receive an amount of bandwidth inversely
+proportional to their round trip time.
+
+\subsection faq_bugrepport So I've found a bug in SimGrid. How to report it?
We do our best to make sure to hammer away any bugs of SimGrid, but this is
still an academic project so please be patient if/when you find bugs in it.
