\endverbatim
\remark
-Other supported values for the routing attribute can be found below, Section
-\ref pf_raf.
-\endremark
+ Other supported values for the routing attribute can be found below, Section
+ \ref pf_raf.
There is also the ``<route>`` tag; this tag takes two attributes, ``src`` (source)
and ``dst`` (destination). Both source and destination must be valid identifiers
how to reach a router from another router.
\remark
-More information and (code-)examples can be found in the Section \ref pf_rm.
-\endremark
-
-An AS can also contain one or more AS; this allows you to
-define the hierarchy of your platform.
-
-Within each AS, the following types of resources exist:
-\li <b>host</b>: a hostmachine; contains processors/cores etc.
-\li <b>router</b>: a router or a gateway.
-\li <b>link</b>: a link that defines a connection between two (or
- more) resources. Every link has a bandwidth and a latency.
-\li <b>cluster</b>: like a real cluster, contains many hosts
- interconnected by some dedicated network.
-
-Between these elements, a routing has to be defined. The AS is
-supposed to be Autonomous, hence this has to be done at the AS level. The AS
-handles two different types of entities (<b>host/router</b> and
-<b>AS</b>); you are responsible to define routes between those elements,
+ More information and (code-)examples can be found in Section \ref pf_rm.
+
+An AS can also contain itself one or more AS; this allows you to
+model the hierarchy of your platform.
+
+### Within each AS, the following types of resources exist:
+
+%Resource | Documented in Section | Description
+--------------- | --------------------- | -----------
+AS | | Every Autonomous System (AS) may contain one or more AS.
+host | \ref pf_host | This entity carries out the actual computation. For this reason, it contains processors (with potentially multiple cores).
+router | \ref pf_router | In SimGrid, routers are used to provide helpful information to routing algorithms. Routers may also act as gateways, connecting several autonomous systems with each other.
+link | \ref pf_link | In SimGrid, (network)links define a connection between two or potentially even more resources. Every link has a bandwidth and a latency and may potentially experience congestion.
+cluster | \ref pf_cluster | In SimGrid, clusters were introduced to model large and homogenous environments. They are not really a resource by themselves - technically, they are only a shortcut, as they will internally set up all the hosts, network and routing for you, i.e., using this resource, one can easily setup thousands of hosts and links in a few lines of code. Each cluster is itself an AS.
+
+%As it is desirable to interconnect these resources, a routing has to be
+defined. The AS is supposed to be Autonomous, hence this has to be done at the
+AS level. The AS handles two different types of entities (<b>host/router</b>
+and <b>AS</b>). However, the user is responsible to define routes between those resources,
otherwise entities will be unconnected and therefore unreachable from other
-entities. Although several algorithms for routing are built into SimGrid (see
-\ref pf_rm), you might encounter a case where you want to define
-routes manually (for instance, due to specific requirements of your
-platform).
+entities. Although several routing algorithms are built into SimGrid (see
+\ref pf_rm), you might encounter a case where you want to define routes
+manually (for instance, due to specific requirements of your platform).
There are three tags to use:
\li <b>ASroute</b>: to define routes between two <b>AS</b>
\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>
-A <b>cluster</b> represents a cluster. It is most of the time used
-when you want to have a bunch of machine defined quickly. It must be
-noted that cluster is meta-tag : <b>from the inner SimGrid point of
+``<cluster />`` represents a machine-cluster. It is most commonly used
+when one wants to define many hosts and a network quickly. Technically,
+``cluster`` is a meta-tag: <b>from the inner SimGrid point of
view, a cluster is an AS where some optimized routing is defined</b>.
The default inner organization of the cluster is as follow:
\verbatim
- _________
+ __________
| |
| router |
____________|__________|_____________ backbone
c-0.me c-99.me
\endverbatim
-You have a set of <b>host</b> defined. Each of them has a <b>link</b>
-to a central backbone (backbone is a <b>link</b> itself, as a link can
-be used to represent a switch, see the switch or <b>link</b> section
-below for more details about it). A <b>router</b> gives a way to the
-<b>cluster</b> to be connected to the outside world. Internally,
-cluster is then an AS containing all hosts : the router is the default
+Here, a set of <b>host</b>s is defined. Each of them has a <b>link</b>
+to a central backbone (backbone is a link itself, as a link can
+be used to represent a switch, see the switch / link section
+below for more details about it). A <b>router</b> allows to connect a
+<b>cluster</b> to the outside world. Internally,
+SimGrid treats a cluster as an AS containing all hosts: the router is the default
gateway for the cluster.
-There is an alternative organization, which is as follow :
+There is an alternative organization, which is as follows:
\verbatim
- _________
+ __________
| |
| router |
|__________|
host0 host1 host2
\endverbatim
-The principle is the same, except we don't have the backbone. The way
-to obtain it is simple : you just have to let bb_* attributes
-unset.
+The principle is the same, except that there is no backbone. This representation
+can be obtained easily: just do not set the bb_* attributes.
Attribute name | Mandatory | Values | Description
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
\subsection pf_ne Network equipments: links and routers
-There are two tags available to represent network entities:
+There are two tags at all times available to represent network entities and
+several other tags that are available only in certain contexts.
1. ``<link>``: Represents a entity that has a limited bandwidth, a
latency, and that can be shared according to TCP way to share this
bandwidth.
\remark
-The concept of links in SimGrid may not be intuitive, as links are not limited
-to connecting (exactly) two entities; in fact, you can have more than two equipments
-connected to it. (In graph theoretical terms: A link in SimGrid is not an edge,
-but a hyperedge)
-\endremark
+ The concept of links in SimGrid may not be intuitive, as links are not limited
+ to connecting (exactly) two entities; in fact, you can have more than two equipments
+ connected to it. (In graph theoretical terms: A link in SimGrid is not an edge,
+ but a hyperedge)
2. ``<router/>``: Represents an entity that a message can be routed
to, but that is unable to execute any code. In SimGrid, routers have also
do they increase latency. As a matter of fact, routers are (almost) ignored
by the simulator when the simulation has begun.
+3. ``<backbone/>``: This tag is only available when the containing AS is
+ used as a cluster (i.e., mode="Cluster")
+
\remark
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).
-\endremark
-\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
-through a link, the bandwidth is shared fairly among the data flows. This
+\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,
-each flow going through this link will be allocated the complete bandwidth,
-i.e., no sharing occurs and the bandwidth is only limiting single flows:
+\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``.
+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.
\remark
-Transfers from one side to the other will interact similarly as
-TCP when ACK returning packets circulate on the other direction. More
-discussion about it is available in the description of link_ctn description.
-\endremark
+ Transfers from one side to the other will interact similarly as
+ TCP when ACK returning packets circulate on the other direction. More
+ discussion about it is available in the description of link_ctn description.
In other words: The SHARED policy defines a physical limit for the bandwidth.
The FATPIPE mode defines a limit for each application,
with no upper total limit.
\remark
-Tip: By using the FATPIPE mode, you can model big backbones that
-won't affect performance (except latency).
-\endremark
+ Tip: By using the FATPIPE mode, you can model big backbones that
+ won't affect performance (except latency).
#### Example ####
#### 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.
\endverbatim
\note
-Even if the syntax is the same, the semantic of bandwidth and latency
-trace files differs from that of host availability files. For bandwidth and
-latency, the corresponding files do not
-express availability as a fraction of the available capacity but directly in
- bytes per seconds for the bandwidth and in seconds for the latency. This is
-because most tools allowing to capture traces on real platforms (such as NWS)
- express their results this way.
- \endnote
+ Even if the syntax is the same, the semantic of bandwidth and latency
+ trace files differs from that of host availability files. For bandwidth and
+ latency, the corresponding files do not
+ express availability as a fraction of the available capacity but directly in
+ bytes per seconds for the bandwidth and in seconds for the latency. This is
+ because most tools allowing to capture traces on real platforms (such as NWS)
+ express their results this way.
##### Example of "link1.bw" file #####
#### 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.
TODO
+\subsubsection pf_backbone <backbone/>
+
+\note
+ This tag is <b>only available</b> when the containing AS uses the "Cluster" mode!
+
+Using this tag, you can designate an already existing link to be a backbone.
+
+Attribute name | Mandatory | Values | Description
+--------------- | --------- | ------ | -----------
+id | yes | string | Name of the link that is supposed to act as a backbone.
+
\subsection pf_storage Storage
\note
-This is a prototype version that should evolve quickly, this
-is just some doc valuable only at the time of writing this doc</b>
-This section describes the storage management under SimGrid ; nowadays
-it's only usable with MSG. It relies basically on linux-like concepts.
-You also may want to have a look to its corresponding section in \ref
-msg_file_management ; functions access are organized as a POSIX-like
-interface.
-\endnote
+ This is a prototype version that should evolve quickly, this
+ is just some doc valuable only at the time of writing this doc
+ This section describes the storage management under SimGrid ; nowadays
+ it's only usable with MSG. It relies basically on linux-like concepts.
+ You also may want to have a look to its corresponding section in \ref
+ msg_file_management ; functions access are organized as a POSIX-like
+ interface.
\subsubsection pf_sto_conc Storage Main concepts
Basically there is 3 different entities to know :
<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();
