3 <object id="TOC" data="graphical-toc.svg" type="image/svg+xml"></object>
5 window.onload=function() { // Wait for the SVG to be loaded before changing it
6 var elem=document.querySelector("#TOC").contentDocument.getElementById("ReferenceBox")
7 elem.style="opacity:0.93999999;fill:#ff0000;fill-opacity:0.1;stroke:#000000;stroke-width:0.35277778;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1";
13 .. _platform_reference:
15 Complete XML Reference
16 **********************
18 Your platform description should follow the specification presented in the
19 `simgrid.dtd <https://simgrid.org/simgrid.dtd>`_ DTD file. The same DTD is used for both platform and deployment files.
21 Here is the complete list of all existing tags in the DTD:
23 :ref:`pf_tag_actor`: request the creation of an actor (deployment file, not in the platform). |br|
24 :ref:`pf_tag_argument`: pass parameters to the created actors (deployment file, not in the platform). |br|
25 :ref:`pf_tag_backbone`: building clusters manually from the XML (deprecated, please use the C++ API). |br|
26 :ref:`pf_tag_bypassRoute`: tweeking the routing (advanced tag). |br|
27 :ref:`pf_tag_bypassZoneRoute`: tweeking the routing (expert-only tag). |br|
28 :ref:`pf_tag_cabinet`: building clusters manually from the XML (deprecated, please use the C++ API). |br|
29 :ref:`pf_tag_cluster`: building a cluster (aka, a full zone in one tag only). |br|
30 :ref:`pf_tag_config`: pass simulation parameters from the XML file. |br|
31 :ref:`pf_tag_disk`: storage resource. |br|
32 :ref:`pf_tag_host`: computing resource. |br|
33 :ref:`pf_tag_host_link`: building clusters manually from the XML (deprecated, please use the C++ API). |br|
34 :ref:`pf_tag_link`: communication resource. |br|
35 :ref:`pf_tag_link_ctn`: name of a link to be included in a route. |br|
36 :ref:`pf_tag_peer`: host located in a :ref:`pf_rm_vivaldi` zone. |br|
37 :ref:`pf_tag_platform`: root tag of any platform description. |br|
38 :ref:`pf_tag_prop`: attach used-defined properties to your :ref:`pf_tag_actor`, :ref:`pf_tag_disk`, :ref:`pf_tag_host`, :ref:`pf_tag_link` or :ref:`pf_tag_zone`. |br|
39 :ref:`pf_tag_route`: intra-zone network path. |br|
40 :ref:`pf_tag_router`: like an :ref:`pf_tag_host` that cannot host actors (for network routing algorithms). |br|
41 :ref:`pf_tag_zone`: area of the network containing elements (:ref:`pf_tag_disk`, :ref:`pf_tag_host`, :ref:`pf_tag_link` and sub-:ref:`pf_tag_zone`). |br|
42 :ref:`pf_tag_zoneRoute`: inter-zone network path.
44 -------------------------------------------------------------------------------
51 This complex tag builds a full zone, with some hosts, links, a router, and the relevant routing algorithm. There is several
52 kind of specifically tailored cluster types: crossbar clusters (contention-free internal network), backbone clusters
53 (constrained internal network), fat-trees, DragonFly and Torus (star clusters are similar, but can only be created from the
54 C++ code). The ``topology`` attribute is used to choose the type of cluster while the ``topo_parameters`` attribute is used
55 to configure the topology. Please refer to the :ref:`examples in the documentation <platform_examples>` for all details.
57 Regardless of its topology, each cluster comes with a router that can be used for inter-zone routing. Its name is defined
58 as ``${prefix}${clusterId}_router${suffix}``.
60 **Parent tags:** :ref:`pf_tag_platform`, :ref:`pf_tag_zone` |br|
61 **Children tags:** none |br|
64 :``id``: The identifier of the cluster. Facilitates referring to this cluster.
65 :``prefix``: Each node of the cluster has to have a name. This name will be prefixed with this prefix.
66 :``suffix``: Each node of the cluster will be suffixed with this suffix
67 :``radical``: Regexp used to generate cluster nodes name.
69 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.
71 The produced number is concatenated between prefix and suffix to form machine names.
72 :``speed``: Same as the ``speed`` attribute of the :ref:`pf_tag_host` tag.
73 :``core``: Same as the ``core`` attribute of the :ref:`pf_tag_host` tag.
74 :``bw``: Bandwidth for the links between nodes and backbone (if any). See :ref:`pf_tag_link` for syntax/details.
75 :``lat``: Latency for the links between nodes and backbone (if any). See :ref:`pf_tag_link` for syntax/details.
76 :``sharing_policy``: Sharing policy for the links between nodes and backbone (if any). See :ref:`pf_tag_link` for syntax/details.
77 :``bb_bw``: Bandwidth for backbone (if any). See :ref:`pf_tag_link` for syntax/details.
79 If bb_bw and bb_lat attributes are omitted, no backbone is created (alternative cluster architecture described earlier).
80 :``bb_lat``: Latency for backbone (if any). See :ref:`pf_tag_link` section for syntax/details.
82 If bb_lat and bb_bw attributes are omitted, no backbone is created (alternative cluster architecture described earlier).
83 :``bb_sharing_policy``: Sharing policy for the backbone (if any). See :ref:`pf_tag_link` section for syntax/details.
84 :``limiter_link``: Bandwidth for limiter link (if any).
86 This adds a specific link for each node, to set the maximum bandwidth reached when communicating in both directions at the same time.
88 In theory this value should be 2*bw for splitduplex 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.
90 More details can be obtained in `Toward Better Simulation of MPI Applications on Ethernet/TCP Networks <https://hal.inria.fr/hal-00919507/>`_
91 :``loopback_bw``: Bandwidth for loopback (if any). See :ref:`pf_tag_link` section for syntax/details.
93 If loopback_bw and loopback_lat attributes are omitted, no loopback link is created and all intra-node communication will use the main network link of the node.
95 The sharing policy of a loopback link is **FATPIPE** :ref:`pf_tag_link`.
96 :``loopback_lat``: Latency for loopback (if any). See loopback_bw for more info.
97 :``topology``: Network topology to use.
99 SimGrid currently supports FLAT (with or without backbone, as described before), TORUS, FAT_TREE and DRAGONFLY attributes for this tag.
101 See :ref:`platform_examples` for more details.
103 :``topo_parameters``: Specific parameters to pass for the topology defined in the topology tag.
105 For torus networks, comma-separated list of the number of nodes in each dimension of the torus.
107 Please refer to :ref:`platform_examples`.
109 -------------------------------------------------------------------------------
116 Adding configuration flags directly into the platform file becomes particularly
117 useful when the realism of the described platform depends on some specific
118 flags. For example, this could help you to finely tune SMPI. Almost all
119 :ref:`command-line configuration items <options_list>` can be configured this
122 Each configuration flag is described as a :ref:`pf_tag_prop` whose ``id`` is the
123 name of the flag and ``value`` is what it has to be set to.
125 **Parent tags:** :ref:`pf_tag_platform` (must appear before any other tags) |br|
126 **Children tags:** :ref:`pf_tag_prop` |br|
131 <?xml version = '1.0'?>
132 <!DOCTYPE platform SYSTEM "https://simgrid.org/simgrid.dtd">
133 <platform version = "4.1">
135 <prop id = "precision/work-amount" value = "0.000010" />
136 <prop id = "cpu/optim" value = "TI" />
137 <prop id = "network/model" value = "SMPI" />
138 <prop id = "network/bandwidth-factor" value = "65472:0.940694;15424:0.697866;9376:0.58729" />
141 <!-- The rest of your platform -->
144 -------------------------------------------------------------------------------
151 SimGrid can simulate the time it takes to read or write data on disk, even if the stored data is not made persistent in
152 any way by SimGrid. This means that your application will correctly be slowed down when doing simulated I/O, but there
153 is no way to get the data stored this way.
155 We decided to not model anything beyond raw access in SimGrid because we believe that there is not single way of doing so.
156 We provide an example model of file system as a plugin, (sparsely) documented in :ref:`plugin_filesystem`.
158 **Parent tags:** :ref:`pf_tag_host` |br|
159 **Children tags:** :ref:`pf_tag_prop` |br|
162 :``id``: A name of your choice (must be unique on this host).
163 :``read_bw``: Read bandwidth for this disk. You must specify a unit as follows.
165 **Units in bytes and powers of 2** (1 KiBps = 1,024 Bps):
166 Bps, KiBps, MiBps, GiBps, TiBps, PiBps, or EiBps. |br|
167 **Units in bits and powers of 2** (1 Bps = 8 bps):
168 bps, Kibps, Mibps, Gibps, Tibps, Pibps, or Eibps. |br|
169 **Units in bytes and powers of 10** (1 KBps = 1,000 Bps):
170 Bps, KBps, MBps, GBps, TBps, PBps, or EBps. |br|
171 **Units in bits and powers of 10:**
172 bps, Kbps, Mbps, Gbps, Tbps, Pbps, or Ebps.
174 :``write_bw``: Write bandwidth for this disk. You must specify a unit as for the read bandwidth.
178 <host id="alice" speed="1Gf">
179 <disk id="Disk1" read_bw="200MBps" write_bw="80MBps">
180 <!-- you can add properties for anything you want: they are not used by SimGrid -->
181 <prop id="content" value="storage/content/small_content.txt"/>
183 <prop id="ram" value="100B" />
186 -------------------------------------------------------------------------------
193 A host is the computing resource on which an actor can run. See :cpp:class:`simgrid::s4u::Host`.
195 **Parent tags:** :ref:`pf_tag_zone` (only leaf zones, i.e., zones containing neither inner zones nor clusters) |br|
196 **Children tags:** :ref:`pf_tag_prop`, :ref:`pf_tag_disk` |br|
200 Must be unique over the whole platform.
201 :``speed``: Computational power (per core, in flop/s).
202 If you use DVFS, provide a comma-separated list of values for each pstate (see :ref:`API_s4u_Host_dvfs`).
203 :``core``: Amount of cores (default: 1).
204 See :ref:`howto_multicore`.
205 :``availability_file``:
206 File containing the availability profile.
207 Almost every lines of such files describe timed events as ``date ratio``.
210 .. code-block:: python
217 - At time t = 1, half of the host computational power (0.5 means 50%) is used to process some background load, hence
218 only 50% of this initial power remains available to your own simulation.
219 - At time t = 2, the available power drops at 20% of the initial value.
220 - At time t = 5, the host can compute at full speed again.
221 - At time t = 10, the profile is reset (as we are 5 seconds after the last event). Then the available speed will drop
222 again to 50% at time t = 11.
224 If your profile does not contain any LOOPAFTER line, then it will
225 be executed only once and not repeated.
227 .. warning:: Don't get fooled: Bandwidth and Latency profiles of a :ref:`pf_tag_link` contain absolute values, while
228 Availability profiles of a :ref:`pf_tag_host` contain ratios.
229 :``state_file``: File containing the state profile.
230 Almost every lines of such files describe timed events as ``date boolean``.
233 .. code-block:: python
239 - At time t = 1, the host is turned off (a zero value means OFF)
240 - At time t = 2, the host is turned back on (any other value than zero means ON)
241 - At time t = 10, the profile is reset (as we are 8 seconds after the last event). Then the host will be turned off
242 again at time t = 11.
244 If your profile does not contain any LOOPAFTER line, then it will
245 be executed only once and not repeated.
247 :``coordinates``: Vivaldi coordinates (meaningful for Vivaldi zones only).
248 See :ref:`pf_tag_peer`.
249 :``pstate``: Initial pstate (default: 0, the first one).
250 See :ref:`API_s4u_Host_dvfs`.
252 -------------------------------------------------------------------------------
259 SimGrid links usually represent one-hop network connections (see :cpp:class:`simgrid::s4u::Link`), i.e., a single wire.
260 They can also be used to abstract a larger network interconnect, e.g., the entire transcontinental network, into a
261 single element. Links are characterized by their bandwidth and latency, and their sharing is realistic wrt TCP connexions.
262 Another unusual point is that SimGrid links can be used to connect more than two elements, just like
263 hyperlinks in an `hypergraph <https://en.wikipedia.org/wiki/Hypergraph>`_.
265 **Parent tags:** :ref:`pf_tag_zone` (both leaf zones and inner zones) |br|
266 **Children tags:** :ref:`pf_tag_prop` |br|
269 :``id``: Link name. Must be unique over the whole platform.
270 :``bandwidth``: Maximum bandwidth for this link. You must specify a unit as follows.
272 **Units in bytes and powers of 2** (1 KiBps = 1,024 Bps):
273 Bps, KiBps, MiBps, GiBps, TiBps, PiBps, or EiBps. |br|
274 **Units in bits and powers of 2** (1 Bps = 8 bps):
275 bps, Kibps, Mibps, Gibps, Tibps, Pibps, or Eibps. |br|
276 **Units in bytes and powers of 10** (1 KBps = 1,000 Bps):
277 Bps, KBps, MBps, GBps, TBps, PBps, or EBps. |br|
278 **Units in bits and powers of 10:**
279 bps, Kbps, Mbps, Gbps, Tbps, Pbps, or Ebps.
281 :``latency``: Latency for this link (default: 0.0). You must specify a unit as follows.
283 ==== =========== ======================
284 Unit Meaning Duration in seconds
285 ==== =========== ======================
286 ps picosecond 10⁻¹² = 0.000000000001
287 ns nanosecond 10⁻⁹ = 0.000000001
288 us microsecond 10⁻⁶ = 0.000001
289 ms millisecond 10⁻³ = 0.001
294 w week 60 * 60 * 24 * 7
295 ==== =========== ======================
297 :``sharing_policy``: Sharing policy for the link. Possible values are ``SHARED``, ``FATPIPE`` or ``SPLITDUPLEX``
298 (default: ``SPLITDUPLEX``).
300 If set to ``SPLITDUPLEX``, the link models the full-duplex
301 behavior, as meant in TCP or UDP. To that extend, the link is
302 actually split in two links whose names are suffixed with "_UP" and
303 "_DOWN". You should then specify the direction to use when
304 referring to that link in a :ref:`pf_tag_link_ctn`.
306 If set to ``FATPIPE``, flows have no impact on each other, hence
307 each flow can exploit the full bandwidth. This models Internet
308 backbones that cannot get saturated by your application. From your
309 application point of view, there is no congestion on these
312 If set to ``SHARED``, the available bandwidth is fairly shared
313 among ALL flows traversing this link. The resulting link is not
314 full-duplex (as UDP or TCP would be): communications in both
315 directions share the same link. Prefer ``SPLITDUPLEX`` for TCP flows.
317 :``bandwidth_file``: File containing the bandwidth profile.
318 Almost every lines of such files describe timed events as ``date
319 bandwidth`` (in bytes per second).
322 .. code-block:: python
328 - At time t = 4, the bandwidth is of 40 Mb/s.
329 - At time t = 8, it raises to 60 Mb/s.
330 - At time t = 24, it drops at 40 MBps again.
332 If your profile does not contain any LOOPAFTER line, then it will
333 be executed only once and not repeated.
335 .. warning:: Don't get fooled: Bandwidth and Latency profiles of a :ref:`pf_tag_link` contain absolute values, while
336 Availability profiles of a :ref:`pf_tag_host` contain ratios.
338 :``latency_file``: File containing the latency profile.
339 Almost every lines of such files describe timed events as ``date
340 latency`` (in seconds).
343 .. code-block:: python
349 - At time t = 1, the latency is of 1ms (0.001 second)
350 - At time t = 3, the latency is of 100ms (0.1 second)
351 - At time t = 8 (5 seconds after the last event), the profile loops.
352 - At time t = 9 (1 second after the loop reset), the latency is back at 1ms.
354 If your profile does not contain any LOOPAFTER line, then it will
355 be executed only once and not repeated.
357 .. warning:: Don't get fooled: Bandwidth and Latency profiles of a :ref:`pf_tag_link` contain absolute values, while
358 Availability profiles of a :ref:`pf_tag_host` contain ratios.
360 :``state_file``: File containing the state profile. See :ref:`pf_tag_host`.
362 -------------------------------------------------------------------------------
369 An element in a route, representing a previously defined link.
371 **Parent tags:** :ref:`pf_tag_route` |br|
372 **Children tags:** none |br|
375 :``id``: Link that is to be included in this route.
376 :``direction``: either ``UP`` (by default) or ``DOWN``, specifying whether to
377 use the uplink or downlink component of the link (that must
378 follow the ``SPLITDUPLEX`` sharing policy). |br|
379 Please refer to the ``sharing_policy`` attribute in
382 -------------------------------------------------------------------------------
389 This tag represents a peer, as in Peer-to-Peer (P2P) networks. It is
390 handy to model situations where hosts have an asymmetric
391 connectivity. Computers connected through set-top-boxes usually have a
392 much better download rate than their upload rate. To model this,
393 <peer> creates and connects several elements: a host, an upload link
396 **Parent tags:** :ref:`pf_tag_zone` (only with Vivaldi routing) |br|
397 **Children tags:** none |br|
400 :``id``: Name of the host. Must be unique on the whole platform.
401 :``speed``: Computational power (in flop/s).
403 If you use DVFS, provide a comma-separated list of values for each pstate (see :ref:`API_s4u_Host_dvfs`).
404 :``bw_in``: Bandwidth of the private downstream link, along with its
405 unit. See :ref:`pf_tag_link`.
406 :``bw_out``: Bandwidth of the private upstream link, along with its
407 unit. See :ref:`pf_tag_link`.
408 :``lat``: Latency of both private links. See :ref:`pf_tag_link`.
409 :``coordinates``: Coordinates of the gateway for this peer.
411 The communication latency between a host A = (xA,yA,zA) and a host B = (xB,yB,zB) is computed as follows:
413 latency = sqrt( (xA-xB)² + (yA-yB)² ) + zA + zB
415 See the documentation of
416 :cpp:class:`simgrid::kernel::routing::VivaldiZone` for details on
417 how the latency is computed from the coordinates, and on how the up
418 and down bandwidth are used.
419 :``availability_file``: File containing the availability profile.
420 See the full description in :ref:`pf_tag_host`
421 :``state_file``: File containing the state profile.
422 See the full description in :ref:`pf_tag_host`
424 -------------------------------------------------------------------------------
431 **Parent tags:** none (this is the root tag of every file) |br|
432 **Children tags:** :ref:`pf_tag_config` (must come first),
433 :ref:`pf_tag_cluster`, :ref:`pf_tag_cabinet`, :ref:`pf_tag_peer`,
434 :ref:`pf_tag_zone`, :ref:`pf_tag_trace`, :ref:`pf_tag_trace_connect`, or
435 :ref:`pf_tag_actor` in :ref:`deployment <deploy>` files. |br|
438 :``version``: Version of the DTD, describing the whole XML format.
439 This versioning allow future evolutions, even if we
440 avoid backward-incompatible changes. The current version
441 is **4.1**. The ``simgrid_update_xml`` program can
442 upgrade most of the past platform files to the most recent
445 -------------------------------------------------------------------------------
452 This tag can be used to attach user-defined properties to some
453 platform elements. Both the name and the value can be any string of
454 your wish. You can use this to pass extra parameters to your code and
457 From your code, you can interact with these properties using the
460 - Actor: :cpp:func:`simgrid::s4u::Actor::get_property`
461 - Cluster: this is a zone, see below.
462 - Disk: :cpp:func:`simgrid::s4u::Disk::get_property`
463 - Host: :cpp:func:`simgrid::s4u::Host::get_property`
464 - Link: :cpp:func:`simgrid::s4u::Link::get_property`
465 - Zone: :cpp:func:`simgrid::s4u::NetZone::get_property`
467 **Parent tags:** :ref:`pf_tag_actor`, :ref:`pf_tag_config`, :ref:`pf_tag_cluster`, :ref:`pf_tag_host`,
468 :ref:`pf_tag_link`, :ref:`pf_tag_disk`,:ref:`pf_tag_zone` |br|
469 **Children tags:** none |br|
472 :``id``: Name of the defined property.
473 :``value``: Value of the defined property.
475 -------------------------------------------------------------------------------
482 A path between two network locations, composed of several occurrences of :ref:`pf_tag_link`. It is only relevant for
483 intra-:ref:`pf_tag_zone` routes. Inter-zone routes must be declared with :ref:`pf_tag_zoneRoute`. More detail can be
484 found in the following sections :ref:`pf_routes` and :ref:`pf_route_usage`.
486 **Parent tags:** :ref:`pf_tag_zone` |br|
487 **Children tags:** :ref:`pf_tag_link_ctn` |br|
490 :``src``: Host from which this route starts. Must be the name of an existing host.
491 :``dst``: Host to which this route leads. Must be the name of an existing host.
492 :``symmetrical``: Whether this route is symmetrical, ie, whether we
493 are defining the route ``dst -> src`` at the same
494 time. Valid values: ``yes``, ``no``, ``YES``, ``NO``
497 -------------------------------------------------------------------------------
504 A router is similar to a :ref:`pf_tag_host`, but it cannot contain any actor. It is only useful to some routing
505 algorithms. In particular, they are useful when you want to use the NS3 bindings to break the routes that are longer
508 **Parent tags:** :ref:`pf_tag_zone` (only leaf zones, i.e., zones containing neither inner zones nor clusters) |br|
511 :``id``: Router name.
512 No other host or router may have the same name over the whole platform.
513 :``coordinates``: Vivaldi coordinates. See :ref:`pf_tag_peer`.
515 -------------------------------------------------------------------------------
522 A networking zone is an area in which elements are located. See :cpp:class:`simgrid::s4u::NetZone`.
524 **Parent tags:** :ref:`pf_tag_platform`, :ref:`pf_tag_zone` (only internal nodes, i.e., zones
525 containing only inner zones or clusters but no basic
526 elements such as host or peer) |br|
527 **Children tags (if internal zone):** :ref:`pf_tag_cluster`, :ref:`pf_tag_link`, :ref:`pf_tag_zone` |br|
528 **Children tags (if leaf zone):** :ref:`pf_tag_host`, :ref:`pf_tag_link`, :ref:`pf_tag_peer` |br|
532 No other zone may have the same name over the whole platform.
533 :``routing``: Routing algorithm to use.
535 -------------------------------------------------------------------------------
537 .. _pf_tag_zoneRoute:
542 All information to factorize the routes between two zones; intra-zone paths must be declared with :ref:`pf_tag_route`.
543 Since zones form a tree, :ref:`pf_tag_zoneRoute` is probably best used to connect sibling zones.
545 When declaring a zoneRoute, you must give the source and destination zones, along with the gateway in each zone (i.e.,
546 the point to reach within that zone to reach the declared route), and the list of links to go from one zone to another.
547 More detail can be found in the following sections :ref:`pf_routes` and :ref:`pf_route_usage`.
549 **Parent tags:** :ref:`pf_tag_zone` |br|
550 **Children tags:** :ref:`pf_tag_link_ctn` |br|
553 :``src``: Zone from which this route starts. Must be an existing zone.
554 :``dst``: Zone to which this route leads. Must be an existing zone.
555 :``gw_src``: Netpoint (within src zone) from which this route starts. Must be an existing host/router.
556 :``gw_dst``: Netpoint (within dst zone) to which this route leads. Must be an existing host/router.
557 :``symmetrical``: Whether this route is symmetrical, ie, whether we are defining the route ``dst -> src`` at the same
558 time. Valid values: ``yes``, ``no``, ``YES``, ``NO``.
560 -------------------------------------------------------------------------------
565 The following list contains some tags that are less often used. They are still valid, but unless you know what you are
566 doing, there is a good chance that you don't really want to use them.
569 -------------------------------------------------------------------------------
571 .. _pf_tag_bypassRoute:
576 This tag can be used to completely bypass the classical :ref:`routing algorithm <pf_route_usage>` for a pair of hosts. The
577 provided list of links will be used directly, with no further routing computation. This is an advanced tag that is rarely
580 **Parent tags:** :ref:`pf_tag_zone` |br|
581 **Children tags:** :ref:`pf_tag_link_ctn` |br|
584 :``src``: Host from which this route starts. Must be the name of an existing host.
585 :``dst``: Host to which this route leads. Must be the name of an existing host.
586 :``symmetrical``: Whether this route is symmetrical, ie, whether we are defining the route ``dst -> src`` at the same time.
587 Valid values: ``yes``, ``no``, ``YES``, ``NO`` (default: YES).
589 -------------------------------------------------------------------------------
591 .. _pf_tag_bypassZoneRoute:
596 This tag can be used to completely bypass the classical :ref:`routing algorithm <pf_route_usage>` between two zones. When
597 provided, it breaks the recursive search and the provided links will be used instead. This tag should probably be reserved
600 **Parent tags:** :ref:`pf_tag_zone` |br|
601 **Children tags:** :ref:`pf_tag_link_ctn` |br|
604 :``src``: Zone from which this route starts. Must be an existing zone.
605 :``dst``: Zone to which this route leads. Must be an existing zone.
606 :``gw_src``: Netpoint (within src zone) from which this route starts. Must be an existing host/router.
607 :``gw_dst``: Netpoint (within dst zone) to which this route leads. Must be an existing host/router.
608 :``symmetrical``: Whether this route is symmetrical, ie, whether we are defining the route ``dst -> src`` at the same
609 time. Valid values: ``yes``, ``no``, ``YES``, ``NO``.
611 -------------------------------------------------------------------------------
618 Within a manually-built cluster, specify the backbone to use. See the documentation of :ref:`pf_tag_cabinet` for all
619 details, even if you should probably stop using this tag and switch to the C++ interface.
621 **Parent tags:** :ref:`pf_tag_zone` with ``routing="Cluster"`` attribute |br|
622 **Children tags:** none |br|
625 :``id``: No other link in the platform shall have the same identifier.
626 :``bw``: Bandwidth, see the :ref:`pf_tag_link` for syntax/details.
627 :``lat``: Latency, see the :ref:`pf_tag_link` for syntax/details.
629 -------------------------------------------------------------------------------
636 The cabinet tag is a shortcut for creating a set of (homogenous) hosts and links quickly, as in cabinets of data centers.
637 This is mostly useful when manually describing a cluster, i.e. a ``<zone routing="Cluster">`` where you manually specify
638 the content with :ref:`pf_tag_cabinet`, :ref:`pf_tag_backbone` and maybe :ref:`pf_tag_host_link`.
640 But this approach is somewhat deprecated now, as the C++ interface is both more convinient and more powerful. For example,
641 the core amount or link characteristics cannot be changed with this tag.
643 **Parent tags:** :ref:`pf_tag_zone` with ``routing="Cluster"`` attribute |br|
644 **Children tags:** none |br|
647 :``id``: The identifier of the cabinet. Facilitates referring to it.
648 :``prefix``: Each node of the cabinet has to have a name. This name will be prefixed with this prefix.
649 :``suffix``: Each node of the cabinet will be suffixed with this suffix.
650 :``radical``: Regexp used to generate cabinet nodes name.
651 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.
653 The produced number is concatenated between prefix and suffix to form machine names.
654 :``speed``: Same as the ``speed`` attribute of the :ref:`pf_tag_host` tag.
655 :``bw``: Bandwidth for the links between nodes and backbone (if any). See the :ref:`pf_tag_link` for syntax/details.
656 :``lat``: Latency for the links between nodes and backbone (if any). See the :ref:`pf_tag_link` for syntax/details.
660 .. literalinclude:: ../../examples/platforms/meta_cluster.xml
662 The hosts generated in the above example are named host-1.cluster, host-2.cluster1
665 -------------------------------------------------------------------------------
667 .. _pf_tag_host_link:
672 Specify the up and down private links of a given host, which must be in a Cluster zone.
674 **Parent tags:** :ref:`pf_tag_zone` with ``routing="Cluster"`` attribute |br|
675 **Children tags:** none |br|
678 :``id``: Identifier of the host to be connected.
679 :``up``: Link id to be used for the outgoing communications.
680 :``down``: Link id to be used for the incoming communications.