core | int (defaults to 1) | Number of cores (see @ref howto_multicore)
state | optionally "OFF" | If set to OFF, the host is initially turned off.
availability_file | File name (optional) | (Relative or absolute) filename to use as input; must contain availability traces for this host. The syntax of this file is defined below.
-state_file | File name (optional) | Same mechanism as availability_file.<br />
+state_file | File name (optional) | File to use as a state profile (see @ref howto_churn)
coordinates | String (mandatory when using Vivaldi routing) | The coordinates of this host (see @ref pf_P2P_tags).
pstate | Double (Defaults to 0) | FIXME: Not yet documented.
Since the periodicity in line 1 was set to be 1.0, i.e., 1 timestep, this host will
continue to provide 500 Mflop/s from time 21. From time 32 it will provide 250 MFlop/s and so on.
-\anchor pf_host_churn
-### Expressing churn ###
-
-To express the fact that a host can change state over time (as in P2P
-systems, for instance), it is possible to use a file describing the time
-at which the host is turned on or off. An example of the content
-of such a file is presented below.
-
-#### Adding a state file ####
-
-\verbatim
-<platform version="4">
- <host id="bob" power="500Gf" state_file="bob.fail" />
-</platform>
-\endverbatim
-
-#### Example of "bob.fail" file ####
-
-~~~{.py}
- PERIODICITY 10.0
- 1.0 0
- 2.0 1
-~~~
-
-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.
-
-
\subsubsection pf_tag_cluster <cluster>
``<cluster />`` represents a machine-cluster. It is most commonly used
#### The ``<prop/>`` tag ####
Similar to the ``<host>`` tag, a link may also contain the ``<prop/>`` tag; see the host
-documentation (Section \ref pf_host) for an example.
+documentation (Section \ref pf_tag_host) for an example.
\subsubsection pf_backbone <backbone/>
Attribute name | Mandatory | Values | Description
--------------- | --------- | ------ | -----------
id | yes | string | Identifier of this storage_type; used when referring to it
-model | yes | string | For reasons of future backwards compatibility only; specifies the name of the model for the storage that should be used
+model | no | string | In the future, this will allow to change the performance model to use
size | yes | string | Specifies the amount of available storage space; you can specify storage like "500GiB" or "500GB" if you want. (TODO add a link to all the available abbreviations)
content | yes | string | Path to a \ref pf_storage_content_file "Storage Content File" on your system. This file must exist.
-content_type | no | ("txt_unix"\|"txt_win") | Determines which kind of filesystem you're using; make sure the filenames (stored in that file, see \ref pf_storage_content_file_structure "Storage Content File Structure"!)
This tag must contain some predefined model properties, specified via the <model_prop> tag. Here is a list,
see below for an example:
--------------- | --------- | ------ | -----------
Bwrite | yes | string | Bandwidth for write access; in B/s (but you can also specify e.g. "30MBps")
Bread | yes | string | Bandwidth for read access; in B/s (but you can also specify e.g. "30MBps")
-Bconnexion | yes | string | Throughput (of the storage connector) in B/s.
\note
A storage_type can also contain the <b><prop></b> tag. The <prop> tag allows you
Here is a complete example for the ``storage_type`` tag:
\verbatim
-<storage_type id="single_HDD" model="linear_no_lat" size="4000" content_type="txt_unix">
+<storage_type id="single_HDD" size="4000">
<model_prop id="Bwrite" value="30MBps" />
<model_prop id="Bread" value="100MBps" />
- <model_prop id="Bconnection" value="150MBps" />
<prop id="Brand" value="Western Digital" />
</storage_type>
\endverbatim
-------------- | --------- | ------ | -----------
id | yes | string | Identifier of this ``storage``; used when referring to it
typeId | yes | string | Here you need to refer to an already existing \ref pf_storage_entity_storage_type "\<storage_type\>"; the storage entity defined by this tag will then inherit the properties defined there.
-attach | yes | string | Name of a host (see Section \ref pf_host) to which this storage is <i>physically</i> attached to (e.g., a hard drive in a computer)
+attach | yes | string | Name of a host (see Section \ref pf_tag_host) to which this storage is <i>physically</i> attached to (e.g., a hard drive in a computer)
content | no | string | When specified, overwrites the content attribute of \ref pf_storage_entity_storage_type "\<storage_type\>"
-content_type | no | string | When specified, overwrites the content_type attribute of \ref pf_storage_entity_storage_type "\<storage_type\>"
Here are two examples:
<storage id="Disk1" typeId="single_HDD" attach="bob" />
<storage id="Disk2" typeId="single_SSD"
- content="content/win_storage_content.txt"
- content_type="txt_windows" attach="alice" />
+ content="content/win_storage_content.txt" />
\endverbatim
The first example is straightforward: A disk is defined and called "Disk1"; it is
Here is a simple example, taken from the file ``examples/platform/storage.xml``:
\verbatim
- <storage_type id="single_SSD" model="linear_no_lat" size="500GiB">
+ <storage_type id="single_SSD" size="500GiB">
<model_prop id="Bwrite" value="60MBps" />
<model_prop id="Bread" value="200MBps" />
- <model_prop id="Bconnection" value="220MBps" />
</storage_type>
<storage id="Disk2" typeId="single_SSD"
content="content/win_storage_content.txt"
- content_type="txt_windows" attach="alice" />
+ attach="alice" />
<storage id="Disk4" typeId="single_SSD"
content="content/small_content.txt"
- content_type="txt_unix" attach="denise"/>
+ attach="denise"/>
<host id="alice" speed="1Gf">
<mount storageId="Disk2" name="c:"/>
\verbinclude example_filelist_routing_cluster
\anchor pf_routing_model_none
+
### None ###
This model does exactly what it's name advertises: Nothing. There is no routing
uses this model, SimGrid will fail unless you have explicitly activated the
\ref options_model_select_network_constant "Constant Network Model" (this model charges
the same for every single communication). It should
-be noted, however, that you can still attach an \ref pf_tag_asroute "ASroute",
+be noted, however, that you can still attach an \ref pf_tag_zoneroute "ZoneRoute",
as is demonstrated in the example below:
\verbinclude platforms/cluster_and_one_host.xml
\subsubsection pf_tag_zoneroute <zoneRoute>
-The purpose of this entity is to define a route between two ASes.
-This is mainly useful when you're in the \ref pf_routing_model_full "Full routing model".
+The purpose of this entity is to define a route between two
+NetZones. Recall that all zones form a tree, so to connect two
+sibiling zones, you must give such a zoneRoute specifying the source
+and destination zones, along with the gateway in each zone (ie, the
+point to reach within that zone to reach the netzone), and the list of
+links in the ancestor zone to go from one zone to another.
+
+So, to go from an host \c src_host that is within zone \c src, to an
+host \c dst_host that is within \c dst, you need to:
+
+ - move within zone \c src, from \c src_host to the specified \c gw_src;
+ - traverse all links specified by the zoneRoute (they are supposed to be within the common ancestor);
+ - move within zone \c dst, from \c gw_dst to \c dst_host.
#### Attributes ####
\subsubsection pf_tag_route <route>
The principle is the same as for
-\ref pf_tag_zoneroute "ASroute": The route contains a list of links that
+\ref pf_tag_zoneroute "ZoneRoute": The route contains a list of links that
provide a path from \c src to \c dst. Here, \c src and \c dst can both be either a
\ref pf_tag_host "host" or \ref pf_router "router". This is mostly useful for the
\ref pf_routing_model_full "Full routing model" as well as for the
\subsection pf_trace trace and trace_connect
Both tags are an alternate way to pass files containing information on
-availability, state etc. to an entity. (See also, for instance, Section \ref
-pf_host_churn "Churn", as described for the host entity.) Instead of referring
-to the file directly in the host, link, or cluster tag, you proceed by defining
-a trace with an id corresponding to a file, later a host/link/cluster, and
-finally using trace_connect you say that the file trace must be used by the
-entity.
+availability, state etc. to an entity. (See also @ref howto_churn).
+Instead of referring to the file directly in the host, link, or
+cluster tag, you proceed by defining a trace with an id corresponding
+to a file, later a host/link/cluster, and finally using trace_connect
+you say that the file trace must be used by the entity.
#### Example ####
./two_hosts.xml:17: <trace_connect trace="Tremblay_power" element="Tremblay" kind="SPEED"/>
@endverbatim
+\subsection pf_hint_generating How to generate different platform files?
+
+This is actually a good idea to search for a better platform file,
+that better fit the need of your study. To be honest, the provided
+examples are not representative of anything. They exemplify our XML
+syntax, but that's all. small_platform.xml for example was generated
+without much thought beyond that.
+
+The best thing to do when possible is to write your own platform file,
+that model the platform on which you run your code. For that, you
+could use <a href="https://gitlab.inria.fr/simgrid/platform-calibration">our
+calibration scripts</a>. This leads to very good fits between the
+platform, the model and the needs. The g5k.xml example resulted of
+such an effort, which also lead to <a href="https://github.com/lpouillo/topo5k/">an
+ongoing attempt</a> to automatically extract the SimGrid platform from
+the <a href="http://grid5000.fr/">Grid'5000</a> experimental platform.
+But it's hard to come up with generic models. Don't take these files
+too seriously. Actually, you should always challenge our models and
+your instanciation if the accuracy really matters to you (see <a
+href="https://hal.inria.fr/hal-00907887">this discussion</a>).
+
+But such advices only hold if you have a real platform and a real
+application at hand. It's moot for more abstract studies working on
+ideas and algorithms instead of technical artefacts. Well, in this
+case, there unfortunately is nothing better than this old and rusty
+<a href="http://pda.gforge.inria.fr/tools/download.html">simulacrum</a>.
+This project is dormant since over 10 years (and you will have to
+update the generated platforms with <tt>bin/simgrid_update_xml</tt> to
+use them), but that's the best we have for this right now....
+
\subsection pf_as_h AS Hierarchy
The AS design allows SimGrid to go fast, because computing route is
done only for the set of resources defined in this AS. If you're using
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).
-\verbatim
+@verbatim
<?xml version='1.0'?>
<!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">
<platform version="4">
<peer id="peer-2" coordinates="243.4 58.8 1.4" speed="730Mf" bw_in="13.38MBps" bw_out="1.024MBps" lat="500us" />
</AS>
</platform>
-\endverbatim
+@endverbatim
In such a case though, we connect the AS created by the <b>peer</b> tag with the Vivaldi routing mechanism.
This means that to route between AS1 and AS2, it will use the coordinates of router_AS1 and router_AS2.
This is currently a convention and we may offer to change this convention in the DTD later if needed.
