X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/368914fb8daebc6d2d2cd58ab4645974b14216c2..501196fba8269024636b011851ce7ea63d7696c9:/doc/doxygen/platform.doc
diff --git a/doc/doxygen/platform.doc b/doc/doxygen/platform.doc
index 7622719696..66e93c9fef 100644
--- a/doc/doxygen/platform.doc
+++ b/doc/doxygen/platform.doc
@@ -1,67 +1,6 @@
/*! @page platform Describing the virtual platform
-
-As usual, SimGrid is a versatile framework, and you should find the
-way of describing your platform that best fits your experimental
-practice.
-
-@section pf_first_example First Platform Example
-
-Here is a very simple platform file, containing 3 resources (two hosts
-and one link), and explicitly giving the route between the hosts.
-
-@code{.xml}
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-@endcode
-
-
-Then, every resource (specified with @ref pf_tag_host, @ref
-pf_tag_link or others) must be located within a given **networking
-zone**. Each zone is in charge of the routing between its
-resources. It means that when an host wants to communicate with
-another host of the same zone, it is the zone's duty to find the list
-of links that are involved in the communication. Here, since the @ref
-pf_tag_zone tag has **Full** as a **routing attribute**, all routes
-must be explicitely given using the @ref pf_tag_route and @ref
-pf_tag_linkctn tags (this @ref pf_rm "routing model" is both simple
-and inefficient :) It is OK to not specify the route between two
-hosts, as long as the processes located on them never try to
-communicate together.
-
-A zone can contain several zones itself, leading to a hierarchical
-decomposition of the platform. This can be more efficient (as the
-inter-zone routing gets factorized with @ref pf_tag_zoneroute), and
-allows to have more than one routing model in your platform. For
-example, you could have a coordinate-based routing for the WAN parts
-of your platforms, a full routing within each datacenter, and a highly
-optimized routing within each cluster of the datacenter. In this
-case, determining the route between two given hosts gets @ref
-routing_basics "somewhat more complex" but SimGrid still computes
-these routes for you in a time- and space-efficient manner.
-Here is an illustration of these concepts:
-
-![A hierarchy of networking zones.](AS_hierarchy.png)
-
-Circles represent processing units and squares represent network
-routers. Bold lines represent communication links. The zone "AS2"
-models the core of a national network interconnecting a small flat
-cluster (AS4) and a larger hierarchical cluster (AS5), a subset of a
-LAN (AS6), and a set of peers scattered around the world (AS7).
-
@section pf_res Resource description
@subsection pf_res_computing Computing Resources
@@ -700,29 +639,6 @@ the shortest paths.
@subsection pf_tag_zone <zone>
-Before SimGrid v3.16, networking zones used to be called Autonomous
-Systems, but this was misleading as zones may include other zones in a
-hierarchical manner. If you find any remaining reference to network
-zones, please report this as a bug.
-
-Attribute | Value | Description
------------ | ------------------------------------------------- | ----------------------------------------------
-id | String (mandatory) | The identifier of this zone (must be unique)
-routing | One of the existing routing algorithm (mandatory) | See Section @ref pf_rm for details.
-
-Example:
-@code
-
-
-
-
-
-
-@endcode
-
-In this example, zone0 contains two hosts (host1 and host2). The route
-between the hosts goes through link1.
-
@subsection pf_rm Routing models
For each network zone, you must define explicitly which routing model will