X-Git-Url: http://bilbo.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/bd8b1f6f7a1fb9e79540cb9eb850c0dc6b99fe3e..512273b5dab057e0f93aaed9c09c79d0e4960b61:/docs/source/Platform_examples.rst diff --git a/docs/source/Platform_examples.rst b/docs/source/Platform_examples.rst index 36592f7b36..29b481d61d 100644 --- a/docs/source/Platform_examples.rst +++ b/docs/source/Platform_examples.rst @@ -11,9 +11,11 @@
.. _platform_examples: - -Platform Examples -================= + +Network Topology Examples +========================= + +.. _platform_example_3hosts: Simple Example with 3 hosts --------------------------- @@ -32,12 +34,12 @@ simulated platform as a graph of hosts and network links. The elements basic elements (with :ref:`pf_tag_host` and :ref:`pf_tag_link`) are described first, and then the routes between -any pair of hosts are explicitly given with :ref:`pf_tag_route`. +any pair of hosts are explicitly given with :ref:`pf_tag_route`. Any host must be given a computational speed in flops while links must be given a latency and a bandwidth. You can write 1Gf for -1,000,000,000 flops (full list of units in the reference guide of -:ref:`pf_tag_host` and :ref:`pf_tag_link`). +1,000,000,000 flops (full list of units in the reference guide of +:ref:`pf_tag_host` and :ref:`pf_tag_link`). Routes defined with :ref:`pf_tag_route` are symmetrical by default, meaning that the list of traversed links from A to B is the same as @@ -48,53 +50,53 @@ root tag must be :ref:`pf_tag_platform`. If the ``version`` attribute does not match what SimGrid expects, you will be hinted to use to the ``simgrid_update_xml`` utility to update your file. +There is often more than one way to model a given platform. For example, the above platform could also be +:ref:`expressed using a shortest path algorithm ` instead of explicitely listing all routes as in +the example above. + Cluster with a Crossbar ----------------------- -A very common parallel computing platform is a homogeneous cluster in -which hosts are interconnected via a crossbar switch with as many -ports as hosts, so that any disjoint pairs of hosts can communicate -concurrently at full speed. For instance: +A very common parallel computing platform is a homogeneous cluster in which hosts are interconnected via a crossbar switch +with as many ports as hosts, so that any disjoint pairs of hosts can communicate concurrently at full speed. Because there +is no contention on the switch, it is modeled as if there were a direct link from each host to the outgoing router. For +instance: + .. literalinclude:: ../../examples/platforms/cluster_crossbar.xml :language: xml :lines: 1-3,18- -One specifies a name prefix and suffix for each host, and then give an -integer range. In the example the cluster contains 65535 hosts (!), -named ``node-0.simgrid.org`` to ``node-65534.simgrid.org``. All hosts -have the same power (1 Gflop/sec) and are connected to the switch via -links with same bandwidth (125 MBytes/sec) and latency (50 +One specifies a name prefix and suffix for each host, and then give an integer range. In the example the cluster contains +65536 hosts (!), named ``node-0.simgrid.org`` to ``node-65535.simgrid.org``. All hosts have the same power (1 Gflop/sec) +and are connected directly to the switch via private links with same bandwidth (125 MBytes/sec) and latency (50 microseconds). -.. todo:: +The outgoing router is named ``${prefix}${cluster_id}_router${suffix}`` so in this case, this is +``node-cluster-crossbar_router.simgrid.org``. - Add the picture. +.. image:: ../../examples/platforms/cluster_crossbar.svg + :align: center Cluster with a Shared Backbone ------------------------------ -Another popular model for a parallel platform is that of a set of -homogeneous hosts connected to a shared communication medium, a -backbone, with some finite bandwidth capacity and on which -communicating host pairs can experience contention. For instance: - +Another popular model for a parallel platform is that of a set of homogeneous hosts connected to a shared communication +medium, a backbone, with some limited bandwidth capacity and on which communicating host pairs can experience contention. +For instance: .. literalinclude:: ../../examples/platforms/cluster_backbone.xml :language: xml :lines: 1-3,18- -The only differences with the crossbar cluster above are the ``bb_bw`` -and ``bb_lat`` attributes that specify the backbone characteristics -(here, a 500 microseconds latency and a 2.25 GByte/sec -bandwidth). This link is used for every communication within the -cluster. The route from ``node-0.simgrid.org`` to ``node-1.simgrid.org`` -counts 3 links: the private link of ``node-0.simgrid.org``, the backbone -and the private link of ``node-1.simgrid.org``. - -.. todo:: +The main differences with the crossbar cluster above are the ``bb_bw`` and ``bb_lat`` attributes that specify the backbone +characteristics (here, a 500 microseconds latency and a 2.25 GBytes/sec bandwidth). This link is used for every +communication within the cluster. The route from ``node-0.simgrid.org`` to ``node-1.simgrid.org`` counts 3 links: the +private link of ``node-0.simgrid.org``, the backbone and the private link of ``node-1.simgrid.org``. The route from +``node-0.simgrid.org`` to the outer internet counts 2 links: the private link of ``node-0.simgrid.org`` and the backbone. - Add the picture. +.. image:: ../../examples/platforms/cluster_backbone.svg + :align: center Torus Cluster ------------- @@ -120,6 +122,8 @@ loopback is given, the communication from a node to itself is handled as if it were two distinct nodes: it goes twice through the private link and through the backbone (if any). +.. _platform_examples_fattree: + Fat-Tree Cluster ---------------- @@ -128,8 +132,8 @@ cluster (and thus reduce its price) while maintaining a high bisection bandwidth and a relatively low diameter. To model this in SimGrid, pass a ``topology="FAT_TREE"`` attribute to your cluster. The ``topo_parameters=#levels;#downlinks;#uplinks;link count`` follows the -semantic introduced in the `Figure 1B of this article -`_. +semantic introduced in the `Figure 1(b) of this article +`_. Here is the meaning of this example: ``2 ; 4,4 ; 1,2 ; 1,2`` @@ -186,9 +190,56 @@ For example, ``3,4 ; 3,2 ; 3,1 ; 2``: :language: xml +Star Zone +--------- + +A Star topology can be seen as a crossbar cluster that does not interconnect hosts, but subzones. It can for example be +used to model a cluster of complex hosts, where each host is disaggregated, with CPUs, GPUs and maybe a network on chip. It +is similar to a cluster topology, with the flexibility to set different route for every component in the star. Because of +its complexity, this topology is only available from the C++ interface. + +.. image:: img/starzone.svg + :scale: 80% + :align: center + +The particularity of this zone is how routes are declared. Instead of declaring the +source and destination, routes are described from a node to everybody else or from +everybody else to the node. In the example, the node *A* uses the *Link1* and *Backbone* +to communicate with other nodes (note that this is valid for both nodes inside or outside +the zone). More precisely, a communication from node *A* to *B* would use links: *Link1, Backbone, +Link3_down*. Note that duplicated links are removed from the route, i.e. in this example we'll use *Backbone* +only once. + +Also, note that the nodes (A, B and C) can be either hosts or other zones. In case of using zones, +set the gateway parameter properly when adding the route. + +The following code illustrates how to create this Star Zone and add the appropriates routes. + +.. code-block:: cpp + + auto* zone = sg4::create_star_zone("star"); + /* create hosts */ + const sg4::Host* hostA = zone->create_host("A", 1e9)->seal(); + const sg4::Host* hostB = zone->create_host("B", 1e9)->seal(); + + /* create links */ + sg4::Link* link1 = zone->create_link("link1", 1e6)->seal(); + sg4::Link* link3_up = zone->create_link("link3_up", 1e6)->seal(); + sg4::Link* link3_down = zone->create_link("link3_down", 1e6)->seal(); + sg4::Link* backbone = zone->create_link("backbone", 1e9)->seal(); + + /* symmetric route route: A->ALL and ALL->A, shared link1 */ + zone->add_route(hostA->get_netpoint(), nullptr, nullptr, nullptr, + std::vector{link1, backbone}, true); + /* route host B -> ALL, split-duplex link3, direction UP */ + zone->add_route(hostB->get_netpoint(), nullptr, nullptr, nullptr, + std::vector{link3_up, backbone}, false); + /* route host ALL -> B, split-duplex link3, direction DOWN */ + zone->add_route(nullptr, hostB->get_netpoint(), nullptr, nullptr, + std::vector{backbone, link3_down}, false); + .. todo:: Complete this page of the manual. SimGrid comes with an extensive set of platforms in the `examples/platforms `_ directory that should be described here. -