\li You can use two XML files: a platform description file and a deployment
description one.
-As the second one (deployment description) just consists of saying which
-process runs where and which arguments it should take as input, the easier way to
-understand how to write it is just to take a look at the examples. Here is an example of it:
+For the deployment stuff, please takea look at \ref deployment
-\verbatim
-<?xml version='1.0'?>
-<!DOCTYPE platform SYSTEM "http://simgrid.gforge.inria.fr/simgrid.dtd">
-<platform version="3">
- <!-- The master process (with some arguments) -->
- <process host="Tremblay" function="master">
- <argument value="20"/> <!-- Number of tasks -->
- <argument value="50000000"/> <!-- Computation size of tasks -->
- <argument value="1000000"/> <!-- Communication size of tasks -->
- <argument value="Jupiter"/> <!-- First slave -->
- <argument value="Fafard"/> <!-- Second slave -->
- <argument value="Ginette"/> <!-- Third slave -->
- <argument value="Bourassa"/> <!-- Last slave -->
- <argument value="Tremblay"/> <!-- Me! I can work too! -->
- </process>
- <!-- The slave processes (with no argument) -->
- <process host="Tremblay" function="slave"/>
- <process host="Jupiter" function="slave"/>
- <process host="Fafard" function="slave"/>
- <process host="Ginette" function="slave"/>
- <process host="Bourassa" function="slave"/>
-</platform>
-\endverbatim
-
-The platform description is slightly more complicated. This documentation is all about how to write this file: what are the basic concept it relies on, what possibilities are offered, and some hints and tips on how to write a good platform description.
+The platform description may be complicated. This documentation is all about how to write this file: what are the basic concept it relies on, what possibilities are offered, and some hints and tips on how to write a good platform description.
\section pf_overview Some words about XML and DTD
availability changes over time using the availability_file
attribute and a separate text file whose syntax is exemplified below.
-
-<b>IMPORTANT NOTE:</b> the numeric separator in both trace and availability depends on your system locale. Examples below holds for LC_NUMERIC=C.
-
-
<b>Adding a trace file</b>
\verbatim
<platform version="1">
\li <b>bw (mandatory)</b>: bandwidth for the links between nodes and backbone (if any). See <b>link</b> section for syntax/details.
\li <b>lat (mandatory)</b>: latency for the links between nodes and backbone (if any). See <b>link</b> section for syntax/details.
\li <b>sharing_policy</b>: sharing policy for the links between nodes and backbone (if any). See <b>link</b> section for syntax/details.
-\li <b>bb_bw </b>: bandwidth for backbone (if any). See <b>link</b> section for syntax/details. If both bb_* attributes are ommited, no backbone is create (alternative cluster architecture described before).
-\li <b>bb_lat </b>: latency for backbone (if any). See <b>link</b> section for syntax/details. If both bb_* attributes are ommited, no backbone is create (alternative cluster architecture described before).
+\li <b>bb_bw </b>: bandwidth for backbone (if any). See <b>link</b> section for syntax/details. If both bb_* attributes are ommited, no backbone is created (alternative cluster architecture described before).
+\li <b>bb_lat </b>: latency for backbone (if any). See <b>link</b> section for syntax/details. If both bb_* attributes are ommited, no backbone is created (alternative cluster architecture described before).
\li <b>bb_sharing_policy</b>: sharing policy for the backbone (if any). See <b>link</b> section for syntax/details.
\li <b>availability_file</b>: Allow you to use a file as input for 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.
-the router name is defined as the resulting String in the following java line of code: router_name = prefix + "router_ + suffix ;
+the router name is defined as the resulting String in the following java line of code: router_name = prefix + clusterId + router_ + suffix ;
<b>cluster example</b>
radical="0-99" power="1000000000" bw="125000000" lat="5E-5"
bb_bw="2250000000" bb_lat="5E-4"/>
\endverbatim
+The second examples creates 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-99.my_cluster_1.me
+\endverbatim
\subsubsection pf_peer peer
A <b>peer</b> represents a peer, as in Peer-to-Peer (P2P). Basically, as cluster, <b>A PEER IS INTERNALLY INTERPRETED AS AN \<AS\></b>. It's just a kind of shortcut that does the following :
