\subsubsection faq_MIA_asynchronous I want to do asynchronous communications in MSG
-Up until now, there is no asynchronous communications in MSG. However,
-you can create as many process as you want so you should be able to do
-whatever you want... I've written a queue module to help implementing
-some asynchronous communications at low cost (creating thousands of
-process only to handle communications may be problematic in term of
-performance at some point). I'll add it in the distribution asap.
+We can now use asynchronous communication in MSG by using function :
+
+ MSG_task_isend()
+
+ MSG_task_irecv()
+
+ MSG_comm_test()
+
+ MSG_comm_wait()
+
+ MSG_comm_waitall()
+
+ MSG_comm_waitany()
+
+ MSG_comm_destroy()
+
+See page :\ref MSG_ex_asynchronous_communications
\subsubsection faq_MIA_thread_synchronization I need to synchronize my MSG processes
SimGrid behavior. In particular, you can change the default cpu and
network models...
+\subsubsection faq_simgrid_configuration_fullduplex Using Fullduplex
+
+Experimental fullduplex support is now available on the svn branch. In order to fullduple to work your platform must have two links for each pair
+of interconnected hosts, see an example here:
+\verbatim
+ simgrid_svn_sources/exemples/msg/gtnets/fullduplex-p.xml
+\endverbatim
+
+Using fullduplex support ongoing and incoming communication flows are
+treated independently for most models. The exception is the LV08 model which
+adds 0.05 of usage on the opposite direction for each new created flow. This
+can be useful to simulate some important TCP phenomena such as ack compression.
+
+Running a fullduplex example:
+\verbatim
+ cd simgrid_svn_sources/exemples/msg/gtnets
+ ./gtnets fullduplex-p.xml fullduplex-d.xml --cfg=fullduplex:1
+\endverbatim
+
+
+
+
+
\subsubsection faq_simgrid_configuration_gtnets Using GTNetS
It is possible to use a packet-level network simulator
\subsubsubsection Mandatory Functions
-\li <b>\c TRACE_start (const char *filename)</b>: This is the first function to
-be called. It receives a single argument as parameter that contains the name of
-the file that will hold the trace in the end of the simulation. It returns 0 if
-everything was properly initialized, 1 otherwise. All trace functions called
-before TRACE_start do nothing.
+\li <b>\c TRACE_start ()</b>: This is the first function to
+be called. It returns 0 if everything was properly initialized, 1 otherwise.
+All trace functions called before TRACE_start do nothing.
\li <b>\c TRACE_category (const char *category)</b>: This function should be used
to define a user category. The category can be used to differentiate the tasks
that will be used when these functions are called is the one returned by
the function \c MSG_host_self().
+\subsubsection faq_tracing_options Tracing configuration Options
+
+These are the options accepted by the tracing system of SimGrid:
+
+\li <b>\c tracing/filename</b>: use this to specify the name of the trace file
+that will be created during the simulation. For example, after the binary
+of your simulator, you can pass as parameter this:
+\verbatim
+--cfg=tracing/filename:mytracefile.trace
+\endverbatim
+in order to trace the behavior of the simulation in a file with the name
+mytracefile.trace.
+
+\li <b>\c tracing/platform</b>: use this to activate the tracing of the
+platform. For example, you can pass as parameter to your simulator:
+\verbatim
+--cfg=tracing/platform:1
+\endverbatim
+to trace the platform utilization by the categories you declared in your
+simulator. By default, this options is set to 0.
+
\subsubsection faq_tracing_example Example of Instrumentation
A simplified example using the tracing mandatory functions.
\verbatim
int main (int argc, char **argv)
{
- TRACE_start ("traced_simulation.trace");
+ MSG_global_init (&argc, &argv);
+
+ //note that TRACE_start must be called after MSG_global_init
+ TRACE_start ();
TRACE_category ("request");
TRACE_category ("computation");
TRACE_category ("finalize");
-
- MSG_global_init (&argc, &argv);
//(... after deployment ...)
\li set Hosts
\verbatim
- simgrid.Host.new("Tremblay",98095000);
- simgrid.Host.new("Jupiter",76296000);
- simgrid.Host.new("Fafard",76296000);
- simgrid.Host.new("Ginette",48492000);
- simgrid.Host.new("Bourassa",48492000);
+ simgrid.Host.new{id="Tremblay",power=98095000};
+ simgrid.Host.new{id="Jupiter",power=76296000};
+ simgrid.Host.new{id="Fafard",power=76296000};
+ simgrid.Host.new{id="Ginette",power=48492000};
+ simgrid.Host.new{id="Bourassa",power=48492000};
\endverbatim
- we use simgrid.Host.new(host_id,power) to instanciate our hosts.
+ we use simgrid.Host.new{id=id_host,power=power_host} to instanciate our hosts.
\li set Links
\verbatim
for i=0,11 do
- simgrid.Link.new(i,252750+ i*768,0.000270544+i*0.087); -- some crazy values ;)
+ simgrid.Link.new{id=i,bandwidth=252750+ i*768,latency=0.000270544+i*0.087}; -- some crazy values ;)
end
\endverbatim
- we used simgrid.Link.new(link_id,bandwidth,latency) with a simple for loop to create all links we need ( much easier than XML hein ? )
+ we used simgrid.Link.new{id=link_id,bandwidth=bw,latency=lat} with a simple for loop to create all links we need (much easier than XML hein ?)
\li set Routes
\verbatim
header files with tons of __declspec(dllexport) cruft. We only need to do so
for data, but there is no public data in SimGrid so we are good.
+