X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/af1dd538906ccadfd744f9959ab73dbab9801400..b47649fd1bd845d7c3d4c07e4400382570d080db:/doc/FAQ.doc diff --git a/doc/FAQ.doc b/doc/FAQ.doc index 58b7a3b3c8..e353e180f6 100644 --- a/doc/FAQ.doc +++ b/doc/FAQ.doc @@ -80,14 +80,13 @@ 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. +(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, libtool, automake +(>1.9) and doxygen (>1.4). 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 @@ -493,8 +492,9 @@ speed provided by SURF. Those two things are working, but we want to make everything as clean as possible before releasing SimGrid v.3. -So what about those nice DAGs we used to have in SimGrid v.1.? They're not -anymore in SimGrid v.3. Let me recall you the way SimGrid 3 is organized: +So what about those nice DAGs we used to have in SimGrid v.1.? They're +not anymore in SimGrid v.3. At least not in their original form... Let +me recall you the way SimGrid 3 is organized: \verbatim ________________ @@ -508,15 +508,17 @@ ________________ ---------------- \endverbatim -XBT is our tool box and now, you should have an idea of what the other ones -are. As you can see, the primitive SG is not here anymore. However it could -still be brought back if people really need it. Here is how it would fit. +XBT is our tool box and now, you should have an idea of what the other +ones are. As you can see, the primitive SG is not here +anymore. However we have written a brand new and cleaner API for this +purpose: \ref SD_API. It is built directly on top of SURF and provides +an API rather close to the old SG: \verbatim ______________________ | User code | |____________________| -| | MSG | GRAS | SG | +| | MSG | GRAS | SD | | -------------------| | | SURF | | -------------------| @@ -524,25 +526,19 @@ ______________________ ---------------------- \endverbatim -Re-implementing SG on top of SURF is really straightforward (it only -requires a little bit of time that I really don't have right now) -since the only thing that lacks to SURF is the DAG part. But adding it -to SURF would slow it down and therefore slow MSG and GRAS which is -not a good thing. However it is really not on the top of our TODO -list because we have to work on GRAS, and its MPI counterpart, and a -parallel task model, and ... Anyway, we finally have migrated our CVS -to gforge so people that are interested by helping on this part will -have the possibility to do it. +The nice thing is that, as it is writen on top of SURF, it seamlessly +support DAG of parallel tasks as well as complex communications +patterns. Some old codes using SG are currently under rewrite using +\ref SD_API to check that all needful functions are provided. \subsection 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. Believe me, it is -worth the effort since you'll then be able to try your algorithms in a very -wide variety of conditions. Here is an example of how you could do that. -Assume T1 has to be done before T2. +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[] { @@ -564,57 +560,8 @@ Assume T1 has to be done before T2. \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 (but it -prevents you from having "realistic" platform modeling), then you should -keep using the 2.18.5 versions until somebody has ported SG on top of SURF. -Note however that SURF will be slower than the old SG to handle traces with -a lots of variations (there is no trace integration anymore). - -\subsection faq_SG_future Will SG come back in the maintained branch one day? - -Sure. In fact, we already have thought about a new and cleaner API: -\verbatim -void* SG_link_get_data(SG_link_t link); -void SG_link_set_data(SG_link_t link, void *data); -const char* SG_link_get_name(SG_link_t link); -double SG_link_get_capacity(SG_link_t link); -double SG_link_get_current_bandwidth(SG_link_t link); -double SG_link_get_current_latency(SG_link_t link); - -SG_workstation_t SG_workstation_get_by_name(const char *name); -SG_workstation_t* SG_workstation_get_list(void); -int SG_workstation_get_number(void); -void SG_workstation_set_data(SG_workstation_t workstation, void *data); -void * SG_workstation_get_data(SG_workstation_t workstation); -const char* SG_workstation_get_name(SG_workstation_t workstation); -SG_link_t* SG_workstation_route_get_list(SG_workstation_t src, SG_workstation_t dst); -int SG_workstation_route_get_size(SG_workstation_t src, SG_workstation_t dst); -double SG_workstation_get_power(SG_workstation_t workstation); -double SG_workstation_get_available_power(SG_workstation_t workstation); - -SG_task_t SG_task_create(const char *name, void *data, double amount); -int SG_task_schedule(SG_task_t task, int workstation_nb, - SG_workstation_t **workstation_list, double *computation_amount, - double *communication_amount, double rate); - -void* SG_task_get_data(SG_task_t task); -void SG_task_set_data(SG_task_t task, void *data); -const char* SG_task_get_name(SG_task_t task); -double SG_task_get_amount(SG_task_t task); -double SG_task_get_remaining_amount(SG_task_t task); -void SG_task_dependency_add(const char *name, void *data, SG_task_t src, SG_task_t dst); -void SG_task_dependency_remove(SG_task_t src, SG_task_t dst); -e_SG_task_state_t SG_task_state_get(SG_task_t task); /* e_SG_task_state_t can be either SG_SCHEDULED, SG_RUNNING, SG_DONE, or SG_FAILED */ -void SG_task_watch(SG_task_t task, e_SG_task_state_t state); /* SG_simulate will stop as soon as the state of this task is the one given in argument. - Watch-point is then automatically removed */ -void SG_task_unwatch(SG_task_t task, e_SG_task_state_t state); - -void SG_task_unschedule(SG_task_t task); /* change state and rerun.. */ - -SG_task_t *SG_simulate(double how_long); /* returns a NULL-terminated array of SG_task_t whose state has changed */ -\endverbatim - -We're just looking for somebody to implement it... :) +DAG is really the level of abstraction you want to work with, then you should +give a try to \ref SD_API. \section faq_dynamic Dynamic resources and platform building @@ -773,13 +720,6 @@ Don't assume we never run this target, because we do. Really. Promise! There is several reasons which may cause the make check to fail on your machine: - - You are using a borken compiler.\n - The symptom may be that the "make check" fails within testsuite/gras - directory.\n - For example, the breezy release of Ubuntu comes with a prerelease of the - 4.0 gcc compiler. This version happens to be completely unusable, and you - should install a gcc-3.4 compiler and change the /usr/bin/gcc link to let - it point on /usr/bin/gcc-3.4. - You are using a borken libc (probably concerning the contextes).\n The symptom is that the "make check" fails within the examples/msg directory.\n By default, SimGrid uses something called ucontexts. This is part of the @@ -797,7 +737,10 @@ machine: concurently, but 5000 processes is still enough for most purposes, isn't it?\n This limitation is the reason why we insist on using this piece of ... - software even if it's so troublesome. + software even if it's so troublesome.\n + => use --with-pthread on AMD64 architecture that do not have an + ultra-recent libc. + - There is a bug in SimGrid we aren't aware of.\n If none of the above apply, please drop us a mail on the mailing list so that we can check it out. @@ -841,7 +784,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 @@ -983,6 +927,18 @@ list. Just be aware that you'll be severely punished if the mistake is on your side... We have plenty of FAQ entries to redact and new features to implement for the impenitents! ;) +\subsection faq_big_fat_warning A BIG FAT WARNING is reported telling me that my platform and deployment files are too old. + +We have decided to change the units in SimGrid. Now we use Bytes, Flops and +seconds instead of MBytes, MFlops and seconds... Units should be updated +accordingly and the version of platform_description should be set to a +valuer greater than 1: +\verbatim + +\endverbatim +You should try to use the surfxml_update.pl script that can be found +here. + \author Arnaud Legrand (arnaud.legrand::imag.fr) \author Martin Quinson (martin.quinson::loria.fr)