+You have the following functions to get informations about a task:
+MSG_task_get_name(), MSG_task_get_compute_duration(),
+MSG_task_get_remaining_computation(), MSG_task_get_data_size(),
+and MSG_task_get_data().
+
+You could use a dictionnary (#xbt_dict_t) of dynars (#xbt_dynar_t). If
+you still don't see how to do it, please come back to us...
+
+\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.
+
+\subsubsection faq_MIA_thread_synchronization I need to synchronize my MSG processes
+
+You obviously cannot use pthread_mutexes of pthread_conds. The best
+thing would be to propose similar structures. Unfortunately, we
+haven't found time to do it yet. However you can try to play with
+MSG_process_suspend() and MSG_process_resume(). You can even do some
+synchronization with fake communications (using MSG_task_get(),
+MSG_task_put() and MSG_task_Iprobe()).
+
+\subsubsection faq_MIA_host_load Where is the get_host_load function hidden in MSG?
+
+There is no such thing because its semantic wouldn't be really
+clear. Of course, it is something about the amount of host throughput,
+but there is as many definition of "host load" as people asking for
+this function. First, you have to remember that resource availability
+may vary over time, which make any load notion harder to define.
+
+It may be instantaneous value or an average one. Moreover it may be only the
+power of the computer, or may take the background load into account, or may
+even take the currently running tasks into account. In some SURF models,
+communications have an influence on computational power. Should it be taken
+into account too?
+
+First of all, it's near to impossible to predict the load beforehands in the
+simulator since it depends on too much parameters (background load
+variation, bandwidth sharing algorithmic complexity) some of them even being
+not known beforehands (other task starting at the same time). So, getting
+this information is really hard (just like in real life). It's not just that
+we want MSG to be as painful as real life. But as it is in some way
+realistic, we face some of the same problems as we would face in real life.
+
+How would you do it for real? The most common option is to use something
+like NWS that performs active probes. The best solution is probably to do
+the same within MSG, as in next code snippet. It is very close from what you
+would have to do out of the simulator, and thus gives you information that
+you could also get in real settings to not hinder the realism of your
+simulation.
+
+\verbatim
+double get_host_load() {
+ m_task_t task = MSG_task_create("test", 0.001, 0, NULL);
+ double date = MSG_get_clock();
+
+ MSG_task_execute(task);
+ date = MSG_get_clock() - date;
+ MSG_task_destroy(task);
+ return (0.001/date);
+}
+\endverbatim
+
+Of course, it may not match your personal definition of "host load". In this
+case, please detail what you mean on the mailing list, and we will extend
+this FAQ section to fit your taste if possible.
+
+\subsubsection 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_SimDag SimDag related questions
+
+\subsubsection faq_SG_comm Implementing communication delays between tasks.
+
+A classic question of SimDag newcommers is about how to express a
+communication delay between tasks. The thing is that in SimDag, both
+computation and communication are seen as tasks. So, if you want to
+model a data dependency between two DAG tasks t1 and t2, you have to
+create 3 SD_tasks: t1, t2 and c and add dependencies in the following
+way:
+
+\verbatim
+SD_task_dependency_add(NULL, NULL, t1, c);
+SD_task_dependency_add(NULL, NULL, c, t2);
+\endverbatim
+
+This way task t2 cannot start before the termination of communication c
+which in turn cannot start before t1 ends.
+
+When creating task c, you have to associate an amount of data (in bytes)
+corresponding to what has to be sent by t1 to t2.
+
+Finally to schedule the communication task c, you have to build a list
+comprising the workstations on which t1 and t2 are scheduled (w1 and w2
+for example) and build a communication matrix that should look like
+[0;amount ; 0; 0].
+
+\subsubsection faq_SG_DAG How to implement a distributed dynamic scheduler of DAGs.
+
+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. Here is an example of how you could do that. Assume T1
+has to be done before T2.
+
+\verbatim
+ int your_agent(int argc, char *argv[] {
+ ...
+ T1 = MSG_task_create(...);
+ T2 = MSG_task_create(...);
+ ...
+ while(1) {
+ ...
+ if(cond) MSG_task_execute(T1);
+ ...
+ if((MSG_task_get_remaining_computation(T1)=0.0) && (you_re_in_a_good_mood))
+ MSG_task_execute(T2)
+ else {
+ /* do something else */
+ }
+ }
+ }
+\endverbatim
+
+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, then you should
+give a try to \ref SD_API.
+
+\subsection faq_MIA_generic Generic features
+
+\subsubsection faq_more_processes Increasing the amount of simulated processes
+
+Here are a few tricks you can apply if you want to increase the amount
+of processes in your simulations.
+
+ - <b>A few thousands of simulated processes</b> (soft tricks)\n
+ SimGrid can use either pthreads library or the UNIX98 contextes. On
+ most systems, the number of pthreads is limited and then your
+ simulation may be limited for a stupid reason. This is especially
+ true with the current linux pthreads, and I cannot get more than
+ 2000 simulated processes with pthreads on my box. The UNIX98
+ contexts allow me to raise the limit to 25,000 simulated processes
+ on my laptop.\n\n
+ The <tt>--with-context</tt> option of the <tt>./configure</tt>
+ script allows you to choose between UNIX98 contextes
+ (<tt>--with-context=ucontext</tt>) and the pthread version
+ (<tt>--with-context=pthread</tt>). The default value is ucontext
+ when the script detect a working UNIX98 context implementation. On
+ Windows boxes, the provided value is discarded and an adapted
+ version is picked up.\n\n
+ We experienced some issues with contextes on some rare systems
+ (solaris 8 and lower or old alpha linuxes comes to mind). The main
+ problem is that the configure script detect the contextes as being
+ functional when it's not true. If you happen to use such a system,
+ switch manually to the pthread version, and provide us with a good
+ patch for the configure script so that it is done automatically ;)
+
+ - <b>Hundred thousands of simulated processes</b> (hard-core tricks)\n
+ As explained above, SimGrid can use UNIX98 contextes to represent
+ and handle the simulated processes. Thanks to this, the main
+ limitation to the number of simulated processes becomes the
+ available memory.\n\n
+ Here are some tricks I had to use in order to run a token ring
+ between 25,000 processes on my laptop (1Gb memory, 1.5Gb swap).\n
+ - First of all, make sure your code runs for a few hundreds
+ processes before trying to push the limit. Make sure it's
+ valgrind-clean, ie that valgrind does not report neither memory
+ error nor memory leaks. Indeed, numerous simulated processes
+ result in *fat* simulation hindering debugging.
+ - It was really boring to write 25,000 entries in the deployment
+ file, so I wrote a little script
+ <tt>examples/gras/mutual_exclusion/simple_token/make_deployment.pl</tt>, which you may
+ 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
+ - Each UNIX98 context has its own stack entry. As debugging this is
+ quite hairly, the default value is a bit overestimated so that
+ user don't get into trouble about this. You want to tune this
+ size to increse the number of processes. This is the
+ <tt>STACK_SIZE</tt> define in
+ <tt>src/xbt/xbt_context_sysv.c</tt>, which is 128kb by default.
+ Reduce this as much as you can, but be warned that if this value
+ is too low, you'll get a segfault. The token ring example, which
+ is quite simple, runs with 40kb stacks.
+ - You may tweak the logs to reduce the stack size further. When
+ logging something, we try to build the string to display in a
+ char array on the stack. The size of this array is constant (and
+ equal to XBT_LOG_BUFF_SIZE, defined in include/xbt/log/h). If the
+ string is too large to fit this buffer, we move to a dynamically
+ sized buffer. In which case, we have to traverse one time the log
+ event arguments to compute the size we need for the buffer,
+ malloc it, and traverse the argument list again to do the actual
+ job.\n
+ The idea here is to move XBT_LOG_BUFF_SIZE to 1, forcing the logs
+ to use a dynamic array each time. This allows us to lower further
+ the stack size at the price of some performance loss...\n
+ This allowed me to run the reduce the stack size to ... 4k. Ie,
+ on my 1Gb laptop, I can run more than 250,000 processes!
+
+\subsubsection 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
+planned because this is a very specific need (and doing it in a
+generic way is thus very hard). However some people have implemented
+their own batch schedulers. Vincent Garonne wrote one during his PhD
+and put his code in the contrib directory of our SVN so that other can
+keep working on it. You may find inspinring ideas in it.
+
+\subsubsection faq_MIA_checkpointing I need a checkpointing thing
+
+Actually, it depends on whether you want to checkpoint the simulation, or to
+simulate checkpoints.
+
+The first one could help if your simulation is a long standing process you
+want to keep running even on hardware issues. It could also help to
+<i>rewind</i> the simulation by jumping sometimes on an old checkpoint to
+cancel recent calculations.\n
+Unfortunately, such thing will probably never exist in SG. One would have to
+duplicate all data structures because doing a rewind at the simulator level
+is very very hard (not talking about the malloc free operations that might
+have been done in between). Instead, you may be interested in the Libckpt
+library (http://www.cs.utk.edu/~plank/plank/www/libckpt.html). This is the
+checkpointing solution used in the condor project, for example. It makes it
+easy to create checkpoints (at the OS level, creating something like core
+files), and rerunning them on need.
+
+If you want to simulate checkpoints instead, it means that you want the
+state of an executing task (in particular, the progress made towards
+completion) to be saved somewhere. So if a host (and the task executing on
+it) fails (cf. #MSG_HOST_FAILURE), then the task can be restarted
+from the last checkpoint.\n
+
+Actually, such a thing does not exists in SimGrid either, but it's just
+because we don't think it is fundamental and it may be done in the user code
+at relatively low cost. You could for example use a watcher that
+periodically get the remaining amount of things to do (using
+MSG_task_get_remaining_computation()), or fragment the task in smaller
+subtasks.
+
+\subsection faq_platform Platform building and Dynamic resources
+
+\subsubsection faq_platform_example Where can I find SimGrid platform files?
+
+There is several little examples in the archive, in the examples/msg
+directory. From time to time, we are asked for other files, but we
+don't have any at hand right now.
+
+We do have a description of the Grid'5000 platform, but because of
+some flaws in the current formalism, this file is actually 500Mb,
+which is ways too big to be used in the parser. We have an internship
+currently working on xml syntax improvements which will allow to
+reduce the size of this file and release it.
+
+Once it's done, we plan to model manually other existing platforms the
+same way we did for G5K and also release those files in some sort of
+SimGrid platform catalog project.
+
+\subsubsection faq_platform_alnem How can I automatically map an existing platform?
+
+We are working on a project called ALNeM (Application-Level Network
+Mapper) which goal is to automatically discover the topology of an
+existing network. Its output will be a platform description file
+following the SimGrid syntax, so everybody will get the ability to map
+their own lab network (and contribute them to the catalog project).
+This tool is not ready yet, but it move quite fast forward. Just stay
+tuned.
+
+\subsubsection faq_platform_synthetic Generating synthetic but realistic platforms
+
+The third possibility to get a platform file (after manual or
+automatic mapping of real platforms) is to generate synthetic
+platforms. Getting a realistic result is not a trivial task, and
+moreover, nobody is really able to define what "realistic" means when
+speaking of topology files. You can find some more thoughts on this
+topic in these
+<a href="http://graal.ens-lyon.fr/~alegrand/articles/Simgrid-Introduction.pdf">slides</a>.
+
+If you are looking for an actual tool, there we have a little tool to
+annotate Tiers-generated topologies. This perl-script is in
+<tt>tools/platform_generation/</tt> directory of the SVN. Dinda et Al.
+released a very comparable tool, and called it GridG.
+
+\subsubsection faq_SURF_dynamic Expressing dynamic resource availability in platform files
+
+A nice feature of SimGrid is that it enables you to seamlessly have
+resources whose availability change over time. When you build a
+platform, you generally declare hosts like that:
+
+\verbatim
+ <host id="host A" power="100.00"/>
+\endverbatim
+
+If you want the availability of "host A" to change over time, the only
+thing you have to do is change this definition like that:
+
+\verbatim
+ <host id="host A" power="100.00" availability_file="trace_A.txt" state_file="trace_A_failure.txt"/>
+\endverbatim
+
+For hosts, availability files are expressed in fraction of available
+power. Let's have a look at what "trace_A.txt" may look like:
+
+\verbatim
+PERIODICITY 1.0
+0.0 1.0
+11.0 0.5
+20.0 0.9
+\endverbatim