~~~{.py}
PERIODICITY 10.0
- 1.0 -1.0
- 2.0 1.0
+ 1.0 0
+ 2.0 1
~~~
-A negative value means <b>down</b> (i.e., OFF) while a positive one means <b>up and
- running</b> (i.e., ON). From time 0.0 to time 1.0, the host is on. At time 1.0, it is
-turned off and at time 2.0, it is turned on again until time 12 (2.0 plus the
-periodicity 10.0). It will be turned on again at time 13.0 until time 23.0, and
+A zero value means <b>down</b> (i.e., OFF) while a positive one means <b>up and
+ running</b> (i.e., ON). From time 0.0 to time 1.0, the host is on as usual. At time 1.0, it is
+turned off and at time 2.0, it is turned on again until time 12 (2 plus the
+periodicity 10). It will be turned off again at time 13.0 until time 23.0, and
so on.
bb_lat | no | int | Latency for backbone (if any). See <b>link</b> section for syntax/details. If bb_lat and bb_bw (see above) attributes are omitted, no backbone is created (alternative cluster architecture <b>described before</b>).
bb_sharing_policy | no | string | Sharing policy for the backbone (if any). See <b>link</b> section for syntax/details.
limiter_link | no | int | Bandwidth for limiter link (if any). This adds a specific link for each node, to set the maximum bandwidth reached when communicating in both directions at the same time. In theory this value should be 2*bw for fullduplex links, but in reality this might be less. This value will depend heavily on the communication model, and on the cluster's hardware, so no default value can be set, this has to be measured. More details can be obtained in <a href="https://hal.inria.fr/hal-00919507/"> "Toward Better Simulation of MPI Applications on Ethernet/TCP Networks"</a>
-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 \ref pf_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.
\verbinclude example_filelist_xmltag_mount
-\anchor pf_storage_entity_mstorage
-#### <mstorage> ####
-\note
- This is currently unused.
-
-<b>mstorage</b> attributes :
-\li <b>typeId (mandatory)</b>: the id of the <b>storage</b> that must
- be mounted on that computer.
-\li <b>name (mandatory)</b>: the name that will be the logical
- reference to this disk (the mount point).
-
\subsubsection pf_storage_example_files Example files
Several examples were already discussed above; if you're interested in full examples,
\subsection pf_include include
-The \c include tag allows you to import other platforms into your
+Even if it can be used in other contexts, this tag was originally created
+to be used with \ref pf_trace. The idea was to have a file describing the
+platform, and another file attaching traces of a given period to the platform.
+
+The drawback is that the file chuncks that will be included do not
+constitute valid XML files. This may explain why this feature was never really
+used in practice (as far as we know). Other mechanisms, such as the ability to load
+several platform files one after the other, could be considered in the future.
+
+In the meanwhile, the \c include tag allows you to import other platforms into your
local file. This is done with the intention to help people
combine their different AS and provide new platforms. Those files
should contain XML that consists of
\ref pf_include "include", \ref pf_cluster "cluster", \ref pf_peer "peer", \ref pf_As "AS", \ref pf_trace "trace", \ref pf_trace "tags".
-\note
- Due to some obscure technical reasons, you have to open
- and close the tag in order to make it work.
+Do not forget to close the tag to make it work, or you will end up with an invalid XML file.
#### Attributes ####
| Attribute name | Mandatory | Values | Description |
| --------------- | --------- | ---------------------- | ----------- |
-| file | yes | String | Filename of the path you want to include with either relative or absolute path. Syntax is defined by your OS |
+| file | yes | String | Filename of the path you want to include with either relative or absolute path. |
#### Example ####
\verbatim
<?xml version='1.0'?>
-<!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">
+<!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid/simgrid.dtd">
<platform version="4">
<AS id="main" routing="Full">
<include file="clusterA.xml"></include>
</platform>
\endverbatim
-Coordinates are then used to calculate latency between two hosts by
-calculating the euclidean distance between the two hosts coordinates.
-The results express the latency in ms.
+Coordinates are then used to calculate latency (in microseconds)
+between two hosts by calculating the distance between the two hosts
+coordinates with the following formula: distance( (x1, y1, z1), (x2,
+y2, z2) ) = euclidian( (x1,y1), (x2,y2) ) + abs(z1) + abs(z2)
+
+In other words, we take the euclidian distance on the two first
+dimensions, and then add the absolute values found on the third
+dimension. This may seem strange, but it was found to allow better
+approximations of the latency matrices (see the paper describing
+Vivaldi).
Note that the previous example defines a routing directly between hosts but it could be also used to define a routing between AS.
That is for example what is commonly done when using peers (see Section \ref pf_peer).
<platform version="4">
<config id="General">
-
<prop id="network/coordinates" value="yes"></prop>
+ <prop id="network/coordinates" value="yes"></prop>
</config>
<AS id="AS0" routing="Vivaldi">
<peer id="peer-0" coordinates="173.0 96.8 0.1" power="730Mf" bw_in="13.38MBps" bw_out="1.024MBps" lat="500us"/>
\li <b>Cluster</b>: Cluster routing, specific to cluster tag, should
not be used.
-\subsection pf_switch I want to describe a switch but there is no switch tag !
+\subsection pf_switch How to describe a switch given that is no switch tag?
Actually we did not include switch tag, ok. But when you're trying to
simulate a switch, the only major impact it has when you're using
(as a link is not an edge by a hyperedge, you can connect more than 2
other links to it).
+\subsection pf_multicabinets How to model multi-cabinets clusters?
+
+You have several possibilities, as usual when modeling things. If your
+cabinets are homogeneous and the intercabinet network negligible for
+your study, you should just create a larger cluster with all hosts at
+the same layer.
+
+In the rare case where your hosts are not homogeneous between the
+cabinets, you can create your cluster completely manually. For that,
+create an As using the Cluster routing, and then use one
+<cabinet> for each cabinet. This cabinet tag can only be used an
+As using the Cluster routing schema, and creating
+
+Be warned that creating a cluster manually from the XML with
+<cabinet>, <backbone> and friends is rather tedious. The
+easiest way to retrieve some control of your model without diving into
+the <cluster> internals is certainly to create one separate
+<cluster> per cabinet and interconnect them together. This is
+what we did in the G5K example platform for the Graphen cluster.
+
\subsection pf_platform_multipath How to express multipath routing in platform files?
It is unfortunately impossible to express the fact that there is more
