]> AND Public Git Repository - simgrid.git/blobdiff - doc/FAQ.doc
Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Updating the FAQ
[simgrid.git] / doc / FAQ.doc
index 88960dbdaa1b4a5e86eeddf0ae883874f30a87a5..faf4165020004c7958f0ffcb79962152af4fbcf6 100644 (file)
@@ -480,12 +480,20 @@ 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?
 
-So, we decided not to include such a function into MSG and let people do it
-thereselves so that they get the value matching exactly what they mean. One
-possibility is to run active measurement 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. 
+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() {
@@ -754,10 +762,10 @@ PERIODICITY 1.0
 20.0 0.9
 \endverbatim
 
-At time 0, our CPU will deliver 100 Mflop/s. At time 11.0, it will
-deliver only 50 Mflop/s until time 20.0 where it will will start
-delivering 90 Mflop/s. Last at time 21.0 (20.0 plus the periodicity
-1.0), we'll be back to the beginning and it will deliver 100Mflop/s.
+At time 0, our CPU will deliver 100 flop/s. At time 11.0, it will
+deliver only 50 flop/s until time 20.0 where it will will start
+delivering 90 flop/s. Last at time 21.0 (20.0 plus the periodicity
+1.0), we'll be back to the beginning and it will deliver 100 flop/s.
 
 Now let's look at the state file:
 \verbatim
@@ -781,7 +789,7 @@ links. A usual declaration looks like:
 You have at your disposal the following options: bandwidth_file,
 latency_file and state_file. The only difference with CPUs is that
 bandwidth_file and latency_file do not express fraction of available
-power but are expressed directly in Mb/s and seconds.
+power but are expressed directly in bytes per seconds and seconds.
 
 \subsection faq_flexml_bypassing How can I have some C functions do what the platform file does?
 
@@ -1073,6 +1081,17 @@ These are changes to FleXML itself, not SimGrid. But since we kinda hijacked
 the development of FleXML, I can grant you that any patches would be really
 welcome and quickly integrated.
 
+<b>Update:</b> A new version of FleXML (1.7) was released. Most of the work
+was done by William Dowling, who use it in his own work. The good point is
+that it now use a dynamic buffer, and that the memory usage was greatly
+improved. The downside is that William also changed some things internally,
+and it breaks the hack we devised to bypass the parser, as explained in 
+\ref faq_flexml_bypassing. Indeed, this is not a classical usage of the
+parser, and Will didn't imagine that we may have used (and even documented)
+such a crude usage of FleXML. So, we now have to repare the bypassing
+functionnality to use the lastest FleXML version and fix the memory usage in
+SimGrid.
+
 \subsection faq_gras_transport GRAS spits networking error messages
 
 Gras, on real platforms, naturally use regular sockets to communicate. They