./configure --enable-maintainer-mode
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.
+
+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, on another machine where all dependencies are met. It will create an
+archive you may deploy on other sites just as a regular stable release.
+
\subsection faq_setting_MSG Setting up your own MSG code
Do not build your simulator by modifying the SimGrid examples. Go
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.
