doc/doxygen/FAQ.doc

   1 /*! @page FAQ Frequently Asked Questions
   2
   3 @tableofcontents
   4
   5 Some entries are a bit aging and it should be refreshed at some point.
   6
   7 @section faq_howto Feature related questions
   8
   9 @subsection faq_MIA_SimDag SimDag related questions
  10
  11 @subsubsection faq_SG_comm Implementing communication delays between tasks.
  12
  13 A classic question of SimDag newcomers is about how to express a
  14 communication delay between tasks. The thing is that in SimDag, both
  15 computation and communication are seen as tasks.  So, if you want to
  16 model a data dependency between two DAG tasks t1 and t2, you have to
  17 create 3 SD_tasks: t1, t2 and c and add dependencies in the following
  18 way:
  19
  20 @code
  21 SD_task_dependency_add(t1, c);
  22 SD_task_dependency_add(c, t2);
  23 @endcode
  24
  25 This way task t2 cannot start before the termination of communication c
  26 which in turn cannot start before t1 ends.
  27
  28 When creating task c, you have to associate an amount of data (in bytes)
  29 corresponding to what has to be sent by t1 to t2.
  30
  31 Finally to schedule the communication task c, you have to build a list
  32 comprising the workstations on which t1 and t2 are scheduled (w1 and w2
  33 for example) and build a communication matrix that should look like
  34 [0;amount ; 0; 0].
  35
  36 @section faq_troubleshooting Troubleshooting
  37
  38 @subsection faq_surf_network_latency I get weird timings when I play with the latencies.
  39
  40 OK, first of all, remember that units should be Bytes, Flops and
  41 Seconds. If you don't use such units, some SimGrid constants (e.g. the
  42 SG_TCP_CTE_GAMMA constant used in most network models) won't have the
  43 right unit and you'll end up with weird results.
  44
  45 Here is what happens with a single transfer of size L on a link
  46 (bw,lat) when nothing else happens.
  47
  48 @verbatim
  49 0-----lat--------------------------------------------------t
  50 |-----|**** real_bw =min(bw,SG_TCP_CTE_GAMMA/(2*lat)) *****|
  51 @endverbatim
  52
  53 In more complex situations, this min is the solution of a complex
  54 max-min linear system.  Have a look
  55 <a href="http://lists.gforge.inria.fr/pipermail/simgrid-devel/2006-April/thread.html">here</a>
  56 and read the two threads "Bug in SURF?" and "Surf bug not
  57 fixed?". You'll have a few other examples of such computations. You
  58 can also read "A Network Model for Simulation of Grid Application" by
  59 Henri Casanova and Loris Marchal to have all the details. The fact
  60 that the real_bw is smaller than bw is easy to understand. The fact
  61 that real_bw is smaller than SG_TCP_CTE_GAMMA/(2*lat) is due to the
  62 window-based congestion mechanism of TCP. With TCP, you can't exploit
  63 your huge network capacity if you don't have a good round-trip-time
  64 because of the acks...
  65
  66 Anyway, what you get is t=lat + L/min(bw,SG_TCP_CTE_GAMMA/(2*lat)).
  67
  68   * if I you set (bw,lat)=(100 000 000, 0.00001), you get t =  1.00001 (you fully
  69 use your link)
  70   * if I you set (bw,lat)=(100 000 000, 0.0001),  you get t =  1.0001 (you're on the
  71 limit)
  72   * if I you set (bw,lat)=(100 000 000, 0.001),   you get t = 10.001  (ouch!)
  73
  74 This bound on the effective bandwidth of a flow is not the only thing
  75 that may make your result be unexpected. For example, two flows
  76 competing on a saturated link receive an amount of bandwidth inversely
  77 proportional to their round trip time.
  78
  79 */