\section pf_pftags Resource description
-\subsection pf_As Platform: The \<AS\> tag
+\subsection pf_As Platform: The <AS> tag
The concept of an AS was already outlined above (Section \ref pf_basics);
recall that the AS is so important because it groups other resources (such
\subsection pf_Cr Computing resources: hosts, clusters and peers.
-\subsubsection pf_host The tag <host/>
+\subsubsection pf_host <host/>
A <b>host</b> represents a computer/node card. Every host is able to execute
code and it can send and receive data to/from other hosts. Most importantly,
--------------- | --------- | ------ | -----------
id | yes | String | The identifier of the host. facilitates referring to this AS.
power | yes | double (must be > 0.0) | Computational power of every core of this host in FLOPS. Must be larger than 0.0.
-core | no | int (Default: 1) | The number of cores of this host. If more than one core is specified, the "power" parameter refers to every core, i.e., the total computational power is #cores*power.<br /> If 6 cores are specified, up to 6 tasks can be executed without sharing the computational power; if more than 6 tasks are executed, computational power will be shared among these tasks. <br /> <b>Warning:</b> Although functional, this model was never scientifically assessed.
+core | no | int (Default: 1) | The number of cores of this host. If more than one core is specified, the "power" parameter refers to every core, i.e., the total computational power is no_of_cores*power.<br /> If 6 cores are specified, up to 6 tasks can be executed without sharing the computational power; if more than 6 tasks are executed, computational power will be shared among these tasks. <br /> <b>Warning:</b> Although functional, this model was never scientifically assessed.
availability | no | int | <b>Specify if the percentage of power available.</b> (What? TODO)
availability_file| no | string | (Relative or absolute) filename to use as input; must contain availability traces for this host. The syntax of this file is defined below. <br /> <b>Note:</b> The filename must be specified with your system's format.
state | no | ON\|OFF<br/> (Default: ON) | Is this host running or not?
Tag name | Description | Documentation
------------ | ----------- | -------------
-<mount/> | Defines mounting points between some storage resource and the host. | \ref pf_sto_mo
-<prop/> | The prop tag allows you to define additional information on this host following the attribute/value schema. You may want to use it to give information to the tool you use for rendering your simulation, for example. | N/A
+\<mount/\> | Defines mounting points between some storage resource and the host. | \ref pf_sto_mo
+\<prop/\> | The prop tag allows you to define additional information on this host following the attribute/value schema. You may want to use it to give information to the tool you use for rendering your simulation, for example. | N/A
### Example ###
### Expressing dynamism ###
SimGrid provides mechanisms to change a hosts' availability over
-time, using the ``availability_file`` attribute to the ``<host>`` tag
+time, using the ``availability_file`` attribute to the ``\<host\>`` tag
and a separate text file whose syntax is exemplified below.
#### Adding a trace file ####
Let us begin to explain this example by looking at line 2. (Line 1 will become clear soon).
The first column describes points in time, in this case, time 0. The second column
describes the relative amount of power this host is able to deliver (relative
-to the maximum performance specified in the ``<host>`` tag). (Clearly, the
+to the maximum performance specified in the ``\<host\>`` tag). (Clearly, the
second column needs to contain values that are not smaller than 0 and not larger than 1).
In this example, our host will deliver 500 Mflop/s at time 0, as 500 Mflop/s is the
maximum performance of this host. At time 11.0, it will
-\subsubsection pf_cluster <cluster>
+\subsubsection pf_cluster <cluster>
``<cluster />`` represents a machine-cluster. It is most commonly used
when one wants to define many hosts and a network quickly. Technically,
prefix | yes | string | Each node of the cluster has to have a name. This name will be prefixed with this prefix.
suffix | yes | string | Each node of the cluster will be suffixed with this suffix
radical | yes | string | Regexp used to generate cluster nodes name. Syntax: "10-20" will give you 11 machines numbered from 10 to 20, "10-20;2" will give you 12 machines, one with the number 2, others numbered as before. The produced number is concatenated between prefix and suffix to form machine names.
-power | yes | int | Same as the ``power`` attribute of the ``<host>`` tag.
-core | no | int (default: 1) | Same as the ``core`` attribute of the ``<host>`` tag.
+power | yes | int | Same as the ``power`` attribute of the ``\<host\>`` tag.
+core | no | int (default: 1) | Same as the ``core`` attribute of the ``\<host\>`` tag.
bw | yes | int | Bandwidth for the links between nodes and backbone (if any). <b>See <b>link</b> section for syntax/details.</b>
lat | yes | int | Latency for the links between nodes and backbone (if any). See <b>link</b> section for syntax/details.
sharing_policy | no | string | Sharing policy for the links between nodes and backbone (if any). See <b>link</b> section for syntax/details.
bb_sharing_policy | no | string | Sharing policy for the backbone (if any). See <b>link</b> section for syntax/details.
availability_file | no | string | Allows you to use a file as input for availability. Similar to <b>hosts</b> attribute.
state_file | no | string | Allows you to use a file as input for states. Similar to <b>hosts</b> attribute.
-loopback_bw | no | int | Bandwidth for loopback (if any). See <b>link</b> section for syntax/details. If loopback_bw and loopback_lat (see below) attributes are omitted, no loopback link is created and all intra-node communication will use the main network link of the node. Loopback link is a <b>FATPIPE</b>.
+loopback_bw | no | int | Bandwidth for loopback (if any). See <b>link</b> section for syntax/details. If loopback_bw and loopback_lat (see below) attributes are omitted, no loopback link is created and all intra-node communication will use the main network link of the node. Loopback link is a \ref sharing_policy_fatpipe "\b FATPIPE".
loopback_lat | no | int | Latency for loopback (if any). See <b>link</b> section for syntax/details. See loopback_bw for more info.
topology | no | FLAT\|TORUS\|FAT_TREE (default: FLAT) | Network topology to use. SimGrid currently supports FLAT (with or without backbone, as described before), <a href="http://en.wikipedia.org/wiki/Torus_interconnect">TORUS </a> and FAT_TREE attributes for this tag.
topo_parameters | no | string | Specific parameters to pass for the topology defined in the topology tag. For torus networks, comma-separated list of the number of nodes in each dimension of the torus. For fat trees, refer to \ref AsClusterFatTree "AsClusterFatTree documentation".
c-99.me
\endverbatim
-\subsubsection pf_peer <peer/>
+\subsubsection pf_peer The <peer> tag
This tag represents a peer, as in Peer-to-Peer (P2P) networks. However, internally,
SimGrid transforms a peer into an AS (similar to Cluster). Hence, this tag
availability_file| no | string | Availability file for the peer. Same as host availability file. See <b>host</b> description for details.
state_file | no | string | State file for the peer. Same as host state file. See <b>host</b> description for details.
-Internally, SimGrid transforms any ``<peer/>`` construct such as
+Internally, SimGrid transforms any ``\<peer/\>`` construct such as
\verbatim
<peer id="FOO"
coordinates="12.8 14.4 6.4"
bw_out="2.25GBps"
lat="500us" />
\endverbatim
-into an ``<AS>`` (see Sections \ref pf_basics and \ref pf_As). In fact, this example of the ``<peer/>`` tag
+into an ``\<AS\>`` (see Sections \ref pf_basics and \ref pf_As). In fact, this example of the ``\<peer/\>`` tag
is completely equivalent to the following declaration:
\verbatim
If you want to represent an entity like a switch, you must use ``<link>`` (see section). Routers are used
to run some routing algorithm and determine routes (see Section \ref pf_routing for details).
-\subsubsection pf_router <router/>
+\subsubsection pf_router <router/>
%As said before, <b>router</b> is used only to give some information
for routing algorithms. So, it does not have any attributes except :
<router id="gw_dc1_horizdist"/>
\endverbatim
-\subsubsection pf_link <link>
+\subsubsection pf_link <link/>
Network links can represent one-hop network connections. They are
characterized by their id and their bandwidth; links can (but may not) be subject
id | yes | string | The identifier of the link to be used when referring to it.
bandwidth | yes | int | Maximum bandwidth for this link, given in bytes/s
latency | no | double (default: 0.0) | Latency for this link.
-sharing_policy | no | SHARED\|FATPIPE\|FULLDUPLEX (default: SHARED) | Sharing policy for the link.
+sharing_policy | no | \ref sharing_policy_shared "SHARED"\|\ref sharing_policy_fatpipe "FATPIPE"\|\ref sharing_policy_fullduplex "FULLDUPLEX" (default: SHARED) | Sharing policy for the link.
state | no | ON\|OFF (default: ON) | Allows you to to turn this link on or off (working / not working)
bandwidth_file | no | string | Allows you to use a file as input for bandwidth.
latency_file | no | string | Allows you to use a file as input for latency.
#### Sharing policy ####
-By default a network link is SHARED, i.e., if two or more data flows go
+\anchor sharing_policy_shared
+By default a network link is \b SHARED, i.e., if two or more data flows go
through a link, the bandwidth is shared fairly among all data flows. This
is similar to the sharing policy TCP uses.
-On the other hand, if a link is defined as a FATPIPE,
+\anchor sharing_policy_fatpipe
+On the other hand, if a link is defined as a \b FATPIPE,
each flow going through this link will be provided with the complete bandwidth,
i.e., no sharing occurs and the bandwidth is only limiting each flow individually.
+Please note that this is really on a per-flow basis, not only on a per-host basis!
The complete bandwidth provided by this link in this mode
-is ``#flows*bandwidth``, with at most ``bandwidth`` being available per flow.
+is ``number_of_flows*bandwidth``, with at most ``bandwidth`` being available per flow.
Using the FATPIPE mode allows to model backbones that won't affect performance
(except latency).
-The last mode available is FULLDUPLEX. This means that SimGrid will
+\anchor sharing_policy_fullduplex
+The last mode available is \b FULLDUPLEX. This means that SimGrid will
automatically generate two links (one carrying the suffix _UP and the other the
suffix _DOWN) for each ``<link>`` tag. This models situations when the direction
of traffic is important.
#### Expressing dynamism and failures ####
Similar to hosts, it is possible to declare links whose state, bandwidth
-or latency changes over time (see Section \ref pf_hosts_dynamism for details).
+or latency changes over time (see Section \ref pf_host_dynamism for details).
In the case of network links, the ``bandwidth`` and ``latency`` attributes are
replaced by the ``bandwidth_file`` and ``latency_file`` attributes.
#### The ``<prop/>`` tag ####
-Similar to ``
<host>``, the link may also contain the ``<prop/>`` tag; see the host
+Similar to ``
\<host\>``, the link may also contain the ``<prop/>`` tag; see the host
documentation (Section \ref pf_host) for an example.
\note
This tag is <b>only available</b> when the containing AS uses the "Cluster" mode!
-TODO: Is default=shared correct?
+Using this tag, you can designate an already existing link to be a backbone.
Attribute name | Mandatory | Values | Description
--------------- | --------- | ------ | -----------
-id | yes | string | The identifier of the link to be used when referring to it.
-bandwidth | yes | int | Maximum bandwidth for this link, given in bytes/s
-latency | no | double (default: 0.0) | Latency for this link.
-sharing_policy | no | SHARED\|FATPIPE\|FULLDUPLEX (default: SHARED) | Sharing policy for the link.
+id | yes | string | Name of the link that is supposed to act as a backbone.
\subsection pf_storage Storage
<config id="General">
<prop id="maxmin/precision" value="0.000010"></prop>
<prop id="cpu/optim" value="TI"></prop>
- <prop id="workstation/model" value="compound"></prop>
+ <prop id="host/model" value="compound"></prop>
<prop id="network/model" value="SMPI"></prop>
<prop id="path" value="~/"></prop>
<prop id="smpi/bw_factor" value="65472:0.940694;15424:0.697866;9376:0.58729"></prop>
pointer functions to some the right surf functions. Since there can be
more than one callback attached to the same event (if more than one
model is in use, for example), they are stored in a dynar. Example in
-workstation_ptask_L07.c:
+host_ptask_L07.c:
\verbatim
/* Adding callback functions */
surf_parse_reset_parser();
