doc/tracing.doc

   1 /*! \page tracing Tracing Simulations for Visualization
   2
   3 \htmlinclude .tracing.doc.toc
   4
   5 \section tracing_tracing Tracing Simulations for Visualization
   6
   7 The trace visualization is widely used to observe and understand the behavior
   8 of parallel applications and distributed algorithms. Usually, this is done in a
   9 two-step fashion: the user instruments the application and the traces are
  10 analyzed after the end of the execution. The visualization itself can highlights
  11 unexpected behaviors, bottlenecks and sometimes can be used to correct
  12 distributed algorithms. The SimGrid team has instrumented the library
  13 in order to let users trace their simulations and analyze them. This part of the
  14 user manual explains how the tracing-related features can be enabled and used
  15 during the development of simulators using the SimGrid library.
  16
  17 \subsection tracing_tracing_howitworks How it works
  18
  19 For now, the SimGrid library is instrumented so users can trace the <b>platform
  20 utilization</b> using the MSG, SimDAG and SMPI interface. This means that the tracing will
  21 register how much power is used for each host and how much bandwidth is used for
  22 each link of the platform. The idea with this type of tracing is to observe the
  23 overall view of resources utilization in the first place, especially the
  24 identification of bottlenecks, load-balancing among hosts, and so on.
  25
  26 The idea of the tracing facilities is to give SimGrid users to possibility to
  27 classify MSG and SimDAG tasks by category, tracing the platform utilization
  28 (hosts and links) for each of the categories. For that,
  29 the tracing interface enables the declaration of categories and a function to
  30 mark a task with a previously declared category. <em>The tasks that are not
  31 classified according to a category are not traced</em>. Even if the user
  32 does not specify any category, the simulations can still be traced in terms
  33 of resource utilization by using a special parameter that is detailed below.
  34
  35 \subsection tracing_tracing_enabling Enabling using CMake
  36
  37 With the sources of SimGrid, it is possible to enable the tracing
  38 using the parameter <b>-Denable_tracing=ON</b> when the cmake is executed.
  39 The section \ref tracing_tracing_functions describes all the functions available
  40 when this Cmake options is activated. These functions will have no effect
  41 if SimGrid is configured without this option (they are wiped-out by the
  42 C-preprocessor).
  43
  44 \verbatim
  45 $ cmake -Denable_tracing=ON .
  46 $ make
  47 \endverbatim
  48
  49 \subsection tracing_tracing_functions Tracing Functions
  50
  51 \li <b>\c TRACE_category (const char *category)</b>: This function should be used
  52 to define a user category. The category can be used to differentiate the tasks
  53 that are created during the simulation (for example, tasks from server1,
  54 server2, or request tasks, computation tasks, communication tasks).
  55 All resource utilization (host power and link bandwidth) will be
  56 classified according to the task category. Tasks that do not belong to a
  57 category are not traced. The color for the category that is being declared
  58 is random (use next function to specify a color).
  59
  60 \li <b>\c TRACE_category_with_color (const char *category, const char *color)</b>: Same
  61 as TRACE_category, but let user specify a color encoded as a RGB-like string with
  62 three floats from 0 to 1. So, to specify a red color, the user can pass "1 0 0" as
  63 color parameter. A light-gray color can be specified using "0.7 0.7 0.7" as color.
  64
  65 \li <b>\c TRACE_msg_set_task_category (m_task_t task, const char *category)</b>:
  66 This function should be called after the creation of a MSG task, to define the
  67 category of that task. The first parameter \c task must contain a task that was
  68 created with the function \c MSG_task_create. The second parameter
  69 \c category must contain a category that was previously defined by the function
  70 \c TRACE_category.
  71
  72 \li <b>\c TRACE_sd_set_task_category (SD_task_t task, const char *category)</b>:
  73 This function should be called after the creation of a SimDAG task, to define the
  74 category of that task. The first parameter \c task must contain a task that was
  75 created with the function \c MSG_task_create. The second parameter
  76 \c category must contain a category that was previously defined by the function
  77 \c TRACE_category.
  78
  79 \li <b>\c TRACE_declare_mark(const char *mark_type)</b>: This function
  80 declares a new Paje event type in the trace file that can be used by
  81 simulators to declare application-level marks. This function is
  82 independent of which API is used in SimGrid.
  83
  84 \li <b>\c TRACE_mark(const char *mark_type, const char *mark_value)</b>:
  85 This function creates a mark in the trace file. The first parameter
  86 had to be previously declared using \c TRACE_declare_mark, the second
  87 is the identifier for this mark instance. We recommend that the \c
  88 mark_value (the second parameter) is a unique value for the whole
  89 trace file (the whole simulation). Nevertheless, this is not a strong
  90 requirement: the trace will be valid if there are multiple mark
  91 identifiers for the same trace.
  92
  93 \li <b>\c TRACE_[host|link]_variable_declare (const char *variable)</b>:
  94 Declare a user variable that will be associated to host/link. A variable can
  95 be used to trace user variables such as the number of tasks in a server,
  96 the number of clients in an application (for hosts), and so on.
  97
  98 \li <b>\c TRACE_[host|link]_variable_declare_with_color (const char
  99 *var, const char *color)</b>: Same as \c
 100 TRACE_[host|link]_variable_declare, but user decides which color will
 101 be assigned to the variable. The color needs to be a string with three
 102 numbers separated by spaces in the range [0,1]. A light-gray color can
 103 be specified using "0.7 0.7 0.7" as color.
 104
 105 \li <b>\c TRACE_[host|link]_variable_[set|add|sub] (const char *[host|link], const char *variable, double value)</b>:
 106 Set the value of a given user variable for a given host/link. The value
 107 of this variable is always associated to the host/link. The host/link
 108 parameters should be its name as the one listed in the platform file.
 109
 110 \li <b>\c TRACE_[host|link]_variable_[set|add|sub]_with_time (double time, const char *[host|link], const char *variable, double value)</b>:
 111 Same as TRACE_[host|link]_variable_[set|add|sub], but let user specify
 112 the time used to trace it. Users can specify a time that is not the
 113 simulated clock time as defined by the core simulator. This allows
 114 a fine-grain control of time definition, but should be used with
 115 caution since the trace can be inconsistent if resource utilization
 116 traces are also traced.
 117
 118 \li <b>\c TRACE_link_srcdst_variable_[set|add|sub] (const char *src, const char *dst, const char *variable, double value)</b>:
 119 Same as TRACE_link_variable_[set|add|sub], but now users specify a source and
 120 destination hosts (as the names from the platform file). The tracing library
 121 will get the corresponding route that connects those two hosts (src and dst) and
 122 [set|add|sub] the value's variable for all the links of the route.
 123
 124 \li <b>\c TRACE_link_srcdst_variable_[set|add|sub]_with_time (double time, const char *src, const char *dst, const char *variable, double value)</b>:
 125 Same as TRACE_link_srcdst_variable_[set|add|sub], but user specify a time different from the simulated time.
 126
 127 \subsection tracing_tracing_options Tracing configuration Options
 128
 129 To check which tracing options are available for your simulator, you
 130 can just run it with the option <b>--help-tracing</b>. These are the
 131 options accepted by the tracing system of SimGrid as of today, you
 132 can use them by running your simulator with the <b>--cfg=</b> switch:
 133
 134 \li <b>\c
 135 tracing
 136 </b>:
 137   Safe switch. It activates (or deactivates) the tracing system.
 138   No other tracing options take effect if this one is not activated.
 139 \verbatim
 140 --cfg=tracing:1
 141 \endverbatim
 142
 143 \li <b>\c
 144 tracing/categorized
 145 </b>:
 146   It activates the categorized resource utilization tracing. It should
 147   be enabled if tracing categories are used by this simulator.
 148 \verbatim
 149 --cfg=tracing/categorized:1
 150 \endverbatim
 151
 152 \li <b>\c
 153 tracing/uncategorized
 154 </b>:
 155   It activates the uncategorized resource utilization tracing. Use it if
 156   this simulator do not use tracing categories and resource use have to be
 157   traced.
 158 \verbatim
 159 --cfg=tracing/uncategorized:1
 160 \endverbatim
 161
 162 \li <b>\c
 163 tracing/filename
 164 </b>:
 165   A file with this name will be created to register the simulation. The file
 166   is in the Paje format and can be analyzed using Triva or Paje visualization
 167   tools. More information can be found in these webpages:
 168      <a href="http://triva.gforge.inria.fr/">http://triva.gforge.inria.fr/</a>
 169      <a href="http://paje.sourceforge.net/">http://paje.sourceforge.net/</a>
 170 \verbatim
 171 --cfg=tracing/filename:mytracefile.trace
 172 \endverbatim
 173   If you do not provide this parameter, the trace file will be named simgrid.trace.
 174
 175 \li <b>\c
 176 tracing/onelink_only
 177 </b>:
 178   By default, the tracing system uses all routes in the platform file
 179   to re-create a "graph" of the platform and register it in the trace file.
 180   This option let the user tell the tracing system to use only the routes
 181   that are composed with just one link.
 182 \verbatim
 183 --cfg=tracing/onelink_only:1
 184 \endverbatim
 185
 186 \li <b>\c
 187 tracing/smpi
 188 </b>:
 189   This option only has effect if this simulator is SMPI-based. Traces the MPI
 190   interface and generates a trace that can be analyzed using Gantt-like
 191   visualizations. Every MPI function (implemented by SMPI) is transformed in a
 192   state, and point-to-point communications can be analyzed with arrows.
 193 \verbatim
 194 --cfg=tracing/smpi:1
 195 \endverbatim
 196
 197 \li <b>\c
 198 tracing/smpi/group
 199 </b>:
 200   This option only has effect if this simulator is SMPI-based. The processes
 201   are grouped by the hosts where they were executed.
 202 \verbatim
 203 --cfg=tracing/smpi/group:1
 204 \endverbatim
 205
 206 \li <b>\c
 207 tracing/msg/task
 208 </b>:
 209   This option only has effect if this simulator is MSG-based. It traces the
 210   behavior of all categorized MSG tasks, grouping them by hosts.
 211 \verbatim
 212 --cfg=tracing/msg/task:1
 213 \endverbatim
 214
 215 \li <b>\c
 216 tracing/msg/process
 217 </b>:
 218   This option only has effect if this simulator is MSG-based. It traces the
 219   behavior of all categorized MSG processes, grouping them by hosts. This option
 220   can be used to track process location if this simulator has process migration.
 221 \verbatim
 222 --cfg=tracing/msg/process:1
 223 \endverbatim
 224
 225 \li <b>\c
 226 tracing/buffer
 227 </b>:
 228  This option put some events in a time-ordered buffer using the
 229  insertion sort algorithm. The process of acquiring and releasing
 230  locks to access this buffer and the cost of the sorting algorithm
 231  make this process slow. The simulator performance can be severely
 232  impacted if this option is activated, but you are sure to get a trace
 233  file with events sorted.
 234 \verbatim
 235 --cfg=tracing/buffer:1
 236 \endverbatim
 237
 238 \li <b>\c
 239 tracing/onelink_only
 240 </b>:
 241 This option changes the way SimGrid register its platform on the trace
 242 file. Normally, the tracing considers all routes (no matter their
 243 size) on the platform file to re-create the resource topology. If this
 244 option is activated, only the routes with one link are used to
 245 register the topology within an AS.  Routes among AS continue to be
 246 traced as usual.
 247 \verbatim
 248 --cfg=tracing/onelink_only:1
 249 \endverbatim
 250
 251 \li <b>\c
 252 tracing/disable_destroy
 253 </b>:
 254 Disable the destruction of containers at the end of simulation. This
 255 can be used with simulators that have a different notion of time
 256 (different from the simulated time).
 257 \verbatim
 258 --cfg=tracing/disable_destroy:1
 259 \endverbatim
 260
 261 \li <b>\c
 262 triva/categorized
 263 </b>:
 264   This option generates a graph configuration file for Triva considering
 265   categorized resource utilization.
 266 \verbatim
 267 --cfg=triva/categorized:graph_categorized.plist
 268 \endverbatim
 269
 270 \li <b>\c
 271 triva/uncategorized
 272 </b>:
 273   This option generates a graph configuration file for Triva considering
 274   uncategorized resource utilization.
 275 \verbatim
 276 --cfg=triva/uncategorized:graph_uncategorized.plist
 277 \endverbatim
 278
 279 \subsection tracing_tracing_example_parameters Case studies
 280
 281 Some scenarios that might help you decide which tracing options
 282 you should use to analyze your simulator.
 283
 284 \li I want to trace the resource utilization of all hosts
 285 and links of the platform, and my simulator <b>does not</b> use
 286 the tracing API. For that, you can run a uncategorized trace
 287 with the following parameters (it will work with <b>any</b> Simgrid
 288 simulator):
 289 \verbatim
 290 ./your_simulator \
 291           --cfg=tracing:1 \
 292           --cfg=tracing/uncategorized:1 \
 293           --cfg=tracing/filename:mytracefile.trace \
 294           --cfg=triva/uncategorized:uncat.plist
 295 \endverbatim
 296
 297 \li I want to trace only a subset of my MSG (or SimDAG) tasks.
 298 For that, you will need to create tracing categories using the
 299 <b>TRACE_category (...)</b> function (as explained above),
 300 and then classify your tasks to a previously declared category
 301 using the <b>TRACE_msg_set_task_category (...)</b>
 302 (or <b>TRACE_sd_set_task_category (...)</b> for SimDAG tasks). After
 303 recompiling, run your simulator with the following parameters:
 304 \verbatim
 305 ./your_simulator \
 306           --cfg=tracing:1 \
 307           --cfg=tracing/categorized:1 \
 308           --cfg=tracing/filename:mytracefile.trace \
 309           --cfg=triva/categorized:cat.plist
 310 \endverbatim
 311
 312
 313 \subsection tracing_tracing_example Example of Instrumentation
 314
 315 A simplified example using the tracing mandatory functions.
 316
 317 \verbatim
 318 int main (int argc, char **argv)
 319 {
 320   MSG_global_init (&argc, &argv);
 321
 322   //(... after deployment ...)
 323
 324   //note that category declaration must be called after MSG_create_environment
 325   TRACE_category_with_color ("request", "1 0 0");
 326   TRACE_category_with_color ("computation", "0.3 1 0.4");
 327   TRACE_category ("finalize");
 328
 329   m_task_t req1 = MSG_task_create("1st_request_task", 10, 10, NULL);
 330   m_task_t req2 = MSG_task_create("2nd_request_task", 10, 10, NULL);
 331   m_task_t req3 = MSG_task_create("3rd_request_task", 10, 10, NULL);
 332   m_task_t req4 = MSG_task_create("4th_request_task", 10, 10, NULL);
 333   TRACE_msg_set_task_category (req1, "request");
 334   TRACE_msg_set_task_category (req2, "request");
 335   TRACE_msg_set_task_category (req3, "request");
 336   TRACE_msg_set_task_category (req4, "request");
 337
 338   m_task_t comp = MSG_task_create ("comp_task", 100, 100, NULL);
 339   TRACE_msg_set_task_category (comp, "computation");
 340
 341   m_task_t finalize = MSG_task_create ("finalize", 0, 0, NULL);
 342   TRACE_msg_set_task_category (finalize, "finalize");
 343
 344   //(...)
 345
 346   MSG_clean();
 347   return 0;
 348 }
 349 \endverbatim
 350
 351 \subsection tracing_tracing_analyzing Analyzing the SimGrid Traces
 352
 353 The SimGrid library, during an instrumented simulation, creates a trace file in
 354 the Paje file format that contains the platform utilization for the simulation
 355 that was executed. The visualization analysis of this file is performed with the
 356 visualization tool <a href="http://triva.gforge.inria.fr">Triva</a>, with
 357 special configurations tunned to SimGrid needs. This part of the documentation
 358 explains how to configure and use Triva to analyse a SimGrid trace file.
 359
 360 - <b>Installing Triva</b>: the tool is available in the Inria's Forge,
 361 at <a href="http://triva.gforge.inria.fr">http://triva.gforge.inria.fr</a>.
 362 Use the following command to get the sources, and then check the file
 363 <i>INSTALL</i>. This file contains instructions to install
 364 the tool's dependencies in a Ubuntu/Debian Linux. The tool can also
 365 be compiled in MacOSX natively, check <i>INSTALL.mac</i> file.
 366 \verbatim
 367 $ git clone git://scm.gforge.inria.fr/triva/triva.git
 368 $ cd triva
 369 $ cat INSTALL
 370 \endverbatim
 371
 372 - <b>Executing Triva</b>: a binary called <i>Triva</i> is available after the
 373   installation (you can execute it passing <em>--help</em> to check its
 374 options). If the triva binary is not available after following the
 375 installation instructions, you may want to execute the following command to
 376 initialize the GNUstep environment variables. We strongly recommend that you
 377 use the latest GNUstep packages, and not the packages available through apt-get
 378 in Ubuntu/Debian packaging systems. If you install GNUstep using the latest
 379 available packages, you can execute this command:
 380 \verbatim
 381 $ source /usr/GNUstep/System/Library/Makefiles/GNUstep.sh
 382 \endverbatim
 383 You should be able to see this output after the installation of triva:
 384 \verbatim
 385 $ ./Triva.app/Triva --help
 386 Usage: Triva [OPTIONS...] TRACE0 [TRACE1]
 387 Trace Analysis through Visualization
 388
 389 TimeInterval
 390     --ti_frequency {double}    Animation: frequency of updates
 391     --ti_hide                  Hide the TimeInterval window
 392     --ti_forward {double}      Animation: value to move time-slice
 393     --ti_apply                 Apply the configuration
 394     --ti_update                Update on slider change
 395     --ti_animate               Start animation
 396     --ti_start {double}        Start of time slice
 397     --ti_size {double}         Size of time slice
 398 Triva
 399     --comparison               Compare Trace Files (Experimental)
 400     --graph                    Configurable Graph
 401     --list                     Print Trace Type Hierarchy
 402     --hierarchy                Export Trace Type Hierarchy (dot)
 403     --stat                     Trace Statistics and Memory Utilization
 404     --instances                List All Trace Entities
 405     --linkview                 Link View (Experimental)
 406     --treemap                  Squarified Treemap
 407     --merge                    Merge Trace Files (Experimental)
 408     --check                    Check Trace File Integrity
 409 GraphConfiguration
 410     --gc_conf {file}           Graph Configuration in Property List Format
 411     --gc_apply                 Apply the configuration
 412     --gc_hide                  Hide the GraphConfiguration window
 413 \endverbatim
 414 Triva expects that the user choose one of the available options
 415 (currently <em>--graph</em> or <em>--treemap</em> for a visualization analysis)
 416 and the trace file from the simulation.
 417
 418 - <b>Understanding Triva - time-slice</b>: the analysis of a trace file using
 419   the tool always takes into account the concept of the <em>time-slice</em>.
 420 This concept means that what is being visualized in the screen is always
 421 calculated considering a specific time frame, with its beggining and end
 422 timestamp. The time-slice is configured by the user and can be changed
 423 dynamically through the window called <em>Time Interval</em> that is opened
 424 whenever a trace file is being analyzed. The next figure depicts the time-slice
 425 configuration window.
 426 In the top of the window, in the space named <i>Trace Time</i>,
 427 the two fields show the beggining of the trace (which usually starts in 0) and
 428 the end (that depends on the time simulated by SimGrid). The middle of the
 429 window, in the square named <i>Time Slice Configuration</i>, contains the
 430 aspects related to the time-slice, including its <i>start</i> and its
 431 <i>size</i>. The gray rectangle in the bottom of this part indicates the
 432 <i>current time-slice</i> that is considered for the drawings. If the checkbox
 433 <i>Update Drawings on Sliders Change</i> is not selected, the button
 434 <i>Apply</i> must be clicked in order to inform triva that the
 435 new time-slice must be considered. The bottom part of the window, in the space
 436 indicated by the square <i>Time Slice Animation</i> can be used to advance
 437 the time-frame automatically. The user configures the amount of time that the
 438 time-frame will forward and how frequent this update will happen. Once this is
 439 configured, the user clicks the <i>Play</i> button in order to see the dynamic
 440 changes on the drawings.
 441 <center>
 442 \htmlonly
 443 <a href="triva-time_interval.png" border=0><img src="triva-time_interval.png" width="50%" border=0></a>
 444 \endhtmlonly
 445 </center>
 446 <b>Remarks:</b> when the trace has too many hosts or links, the computation to
 447 take into account a new time-slice can be expensive. When this happens, the
 448 <i>Frequency</i> parameter, but also updates caused by change on configurations
 449 when the checkbox <i>Update Drawings on Sliders
 450 Change</i> is selected will not be followed.
 451
 452 - <b>Understanding Triva - graph</b>: one possibility to analyze
 453   SimGrid traces is to use Triva's graph view, using the
 454   <em>--graph</em> parameter to activate this view, and
 455   <em>--gc_conf</em> with a graph configuration to customize the graph
 456   according to the traces. A valid graph configuration (we are using
 457   the non-XML <a
 458   href="http://en.wikipedia.org/wiki/Property_list">Property List
 459   Format</a> to describe the configuration) can be created for any
 460   SimGrid-based simulator using the
 461   <em>--cfg=triva/uncategorized:graph_uncategorized.plist</em> or
 462   <em>--cfg=triva/categorized:graph_categorized.plist</em> (if the
 463   simulator defines resource utilization categories) when executing
 464   the simulation.
 465
 466 <b>Basic SimGrid Configuration</b>: The basic description of the configuration
 467 is as follows:
 468 \verbatim
 469 {
 470   node = (LINK, HOST, );
 471   edge = (HOST-LINK, LINK-HOST, LINK-LINK, );
 472 \endverbatim
 473
 474 The nodes of the graph will be created based on the <i>node</i>
 475 parameter, which in this case is the different <em>"HOST"</em>s and
 476 <em>"LINK"</em>s of the platform used to simulate. The <i>edge</i>
 477 parameter indicates that the edges of the graph will be created based
 478 on the <em>"HOST-LINK"</em>s, <em>"LINK-HOST"</em>s, and
 479 <em>"LINK-LINK"</em>s of the platform.  After the definition of these
 480 two parameters, the configuration must detail how the nodes
 481 (<em>HOST</em>s and <em>LINK</em>s) should be drawn.
 482
 483 For that, the configuration must have an entry for each of
 484 the types used. For <em>HOST</em>, as basic configuration, we have:
 485
 486 \verbatim
 487   HOST = {
 488     type = square;
 489     size = power;
 490     values = (power_used);
 491   };
 492 \endverbatim
 493
 494 The parameter <em>size</em> indicates which variable from the trace
 495 file will be used to define the size of the node HOST in the
 496 visualization. If the simulation was executed with availability
 497 traces, the size of the nodes will be changed according to these
 498 traces. The parameter <em>type</em> indicates which geometrical shape
 499 will be used to represent HOST, and the <em>values</em> parameter
 500 indicates which values from the trace will be used to fill the shape.
 501
 502 For <em>LINK</em> we have:
 503
 504 \verbatim
 505   LINK = {
 506     type = rhombus;
 507     size = bandwidth;
 508     values = (bandwidth_used);
 509   };
 510 }
 511 \endverbatim
 512
 513 The same configuration parameters are used here: <em>type</em> (with a
 514 rhombus), the <em>size</em> (whose value is from trace's bandwidth
 515 variable) and the <em>values</em>.
 516
 517 <b>Customizing the Graph Representation</b>: triva is capable to handle
 518 a customized graph representation based on the variables present in the trace
 519 file. In the case of SimGrid, every time a category is created for tasks, two
 520 variables in the trace file are defined: one to indicate node utilization (how
 521 much power was used by that task category), and another to indicate link
 522 utilization (how much bandwidth was used by that category). For instance, if the
 523 user declares a category named <i>request</i>, there will be variables named
 524 <b>p</b><i>request</i> and a <b>b</b><i>request</i> (<b>p</b> for power and
 525 <b>b</b> for bandwidth). It is important to notice that the variable
 526 <i>prequest</i> in this case is only available for HOST, and
 527 <i>brequest</i> is only available for LINK. <b>Example</b>: suppose there are
 528 two categories for tasks: request and compute. To create a customized graph
 529 representation with a proportional separation of host and link utilization, use
 530 as configuration for HOST and LINK this:
 531
 532 \verbatim
 533   HOST = {
 534     type = square;
 535     size = power;
 536     values = (prequest, pcomputation);
 537   };
 538   LINK = {
 539     type = rhombus;
 540     size = bandwidth;
 541     values = (brequest, bcomputation);
 542   };
 543 \endverbatim
 544
 545 This configuration enables the analysis of resource utilization by MSG tasks,
 546 and the identification of load-balancing issues, network bottlenecks, for
 547 instance. \n
 548
 549 <b>The Graph Visualization</b>: The next figure shows a graph visualization of a
 550 given time-slice of the masterslave_forwarder example (present in the SimGrid
 551 sources). The red color indicates tasks from the <i>compute</i> category. This
 552 visualization was generated with the following configuration:
 553
 554 \verbatim
 555 {
 556   node = (LINK, HOST, );
 557   edge = (HOST-LINK, LINK-HOST, LINK-LINK, );
 558
 559   host = {
 560     type = square;
 561     size = power;
 562     values = (pcompute, pfinalize);
 563   };
 564   link = {
 565     type = rhombus;
 566     size = bandwidth;
 567     values = (bcompute, bfinalize);
 568   };
 569 }
 570 \endverbatim
 571
 572 <center>
 573 \htmlonly
 574 <a href="triva-graph_visualization.png" border=0><img src="triva-graph_visualization.png" width="50%" border=0></a>
 575 \endhtmlonly
 576 </center>
 577
 578 - <b>Understading Triva - colors</b>: Colors are now registered in
 579 trace files. See the tracing API to how to define them for your
 580 simulator.
 581
 582 */