referring to it.
\li <b>power (mandatory)</b>:the peak number FLOPS the CPU can manage.
Expressed in flop/s.
-\li <b>core</b>: The number of core of this host. If set, the power
- gives the power of one core. The specified computing power will be
+\li <b>core</b>: The number of core of this host (by default, 1). If
+ you specify the amount of cores, the 'power' parameter is the power
+ of each core.
+ For example, if you specify that your host has 6 cores, it will be
available to up to 6 sequential tasks without sharing. If more
tasks are placed on this host, the resource will be shared
- accordingly. For example, if you schedule 12 tasks on the host,
- each will get half of the computing power. Please note that
- although sound, this model were never scientifically assessed.
+ accordingly. For example, if you schedule 12 tasks on that host,
+ each will get half of the specified computing power. Please note
+ that although sound, this model were never scientifically assessed.
Please keep this fact in mind when using it.
-
\li <b>availability</b>: specify if the percentage of power available.
\li <b>availability_file</b>: Allow you to use a file as input. This
file will contain availability traces for this computer. The
availability. Similar to <b>hosts</b> attribute.
\li <b>state_file</b>: Allow you to use a file as input for states.
Similar to <b>hosts</b> attribute.
+\li <b>loopback_bw </b>: bandwidth for loopback (if any). See <b>link</b>
+ section for syntax/details. If both loopback_* 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>.
+\li <b>loopback_lat </b>: latency for loopback (if any). See <b>link</b>
+ section for syntax/details. See loopback_bw for more info.
+\li <b>topology </b>: network topology to use. For now SimGrid supports FLAT
+ (default, 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.
+\li <b>topo_parameters </b>: 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".
+
the router name is defined as the resulting String in the following
java line of code:
@verbatim
-router_name = prefix + clusterId + router_ + suffix;
+router_name = prefix + clusterId + _router + suffix;
@endverbatim
<b>cluster example</b>
\verbatim
-<cluster id="my_cluster_1" prefix="" suffix=""
- radical="0-262144" power="1000000000" bw="125000000" lat="5E-5"/>
-<cluster id="my_cluster_1" prefix="c-" suffix=".me"
- radical="0-99" power="1000000000" bw="125000000" lat="5E-5"
- bb_bw="2250000000" bb_lat="5E-4"/>
+<cluster id="my_cluster_1" prefix="" suffix="" radical="0-262144"
+ power="1e9" bw="125e6" lat="5E-5"/>
+
+<cluster id="my_cluster_1" prefix="c-" suffix=".me" radical="0-99"
+ power="1e9" bw="125e6" lat="5E-5"
+ bb_bw="2.25e9" bb_lat="5E-4"/>
\endverbatim
-The second examples creates 100 machines, which names are the following:
+The second examples creates one router and 100 machines, which names
+are the following:
\verbatim
-c-0.my_cluster_1.me
-c-1.my_cluster_1.me
-c-2.my_cluster_1.me
+c-my_cluster_1_router.me
+c-0.me
+c-1.me
+c-2.me
...
-c-99.my_cluster_1.me
+c-99.me
\endverbatim
\subsubsection pf_peer peer
\li <b>content</b>: default value 0. The file containing the disk
content. (may be moved soon or later to <b>storage</b> tag.
-The tag must contains some predefined prop, as may do some other
-resources tags. This should moved to attributes soon or later.
-<b>storage_type</b> mandatory <b>prop</b> :
+The tag must contains some predefined model prop, as may do some other
+resources tags.
+<b>storage_type</b> mandatory <b>model_prop</b> :
\li <b>Bwrite</b>: value in B/s. Write throughput
\li <b>Bread</b>: value in B/s. Read throughput
\li <b>Bconnexion</b>: value in B/s. Connection throughput (i.e. the
throughput of the storage connector).
+A storage_type can also contain the <b>prop</b> tag. The prop tag allows you
+to define additional information on this storage_type 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.
+
+\verbatim
+<storage_type id="single_HDD" model="linear_no_lat" size="4000" content_type="txt_unix">
+ <model_prop id="Bwrite" value="30MBps" />
+ <model_prop id="Bread" value="100MBps" />
+ <model_prop id="Bconnection" value="150MBps" />
+ <b><prop id="Brand" value="Western Digital" /></b>
+</storage_type>
+\endverbatim
+
\subsubsection pf_sto_st storage
<b>storage_type</b> attributes :
\li <b>id (mandatory)</b>: the identifier of the storage to be used
when referring to it.
\li <b>typeId (mandatory)</b>: the identifier of the storage_type that
- this storage belongs to.
-
+ this storage belongs to.
+\li <b>attach (mandatory)</b>: the host (name) to which the storage is
+ attached to.
\subsubsection pf_sto_mo mount
to give routes with one link only in it, as SimGrid needs to know
which host are at the end of the link.
-\subsubsection pf_byro bypassASroute
+\subsubsection pf_byASro bypassASroute
<b>Note : bypassASroute and bypassRoute are under rewriting to perform
better ; so you may not use it yet</b> As said before, once you choose
