X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/6b7277f4add5918aabe1e661f03ad1fa7b66f7d3..9913e297eeba0983a5ff635c076e3f458b178766:/doc/doxygen/platform.doc diff --git a/doc/doxygen/platform.doc b/doc/doxygen/platform.doc index c8d898c68c..94e1194de1 100644 --- a/doc/doxygen/platform.doc +++ b/doc/doxygen/platform.doc @@ -2,6 +2,17 @@ @tableofcontents +\htmlonly +
+\endhtmlonly +\htmlinclude graphical-toc.svg +\htmlonly +
+ +\endhtmlonly + As @ref starting_components "explained in the introduction," any SimGrid study must entail the description of the platform on which you want to simulate your application. You have to describe **each element @@ -329,7 +340,7 @@ The hosts generated in the above example are named host-1.cluster, host-2.cluste etc. -\subsubsection pf_peer \ (Vivaldi netzones only) +\subsubsection pf_peer <peer> (Vivaldi netzones only) This tag represents a peer, as in Peer-to-Peer (P2P) networks. This can only be used in Vivaldi NetZones. It creates the following @@ -392,7 +403,7 @@ several other tags that are available only in certain contexts. \subsubsection pf_router <router/> As said before, router is used only to give some information -for routing algorithms. So, it does not have any attributes except : +for routing algorithms. So, it does not have any attributes except: #### Attributes #### @@ -605,7 +616,7 @@ that include storage facilities: Entity name | Description --------------- | ----------- \ref pf_storage_entity_storage_type "storage_type" | Defines a template for a particular kind of storage (such as a hard-drive) and specifies important features of the storage, such as capacity, performance (read/write), contents, ... Different models of hard-drives use different storage_types (because the difference between an SSD and an HDD does matter), as they differ in some specifications (e.g., different sizes or read/write performance). -\ref pf_storage_entity_storage "storage" | Defines an actual instance of a storage type (disk, RAM, ...); uses a ``storage_type`` template (see line above) so that you don't need to re-specify the same details over and over again. +\ref pf_tag_storage "storage" | Defines an actual instance of a storage type (disk, RAM, ...); uses a ``storage_type`` template (see line above) so that you don't need to re-specify the same details over and over again. \ref pf_tag_mount "mount" | Must be wrapped by a \ref pf_tag_host tag; declares which storage(s) this host has mounted and where (i.e., the mountpoint). @@ -740,7 +751,7 @@ called alice (which is again not defined here). | Attribute | Mandatory | Values | Description | | ----------- | ----------- | -------- | ------------- | -| id | yes | string | Refers to a \ref pf_storage_entity_storage "<storage>" entity that will be mounted on that computer | +| id | yes | string | Refers to a \ref pf_tag_storage "<storage>" entity that will be mounted on that computer | | name | yes | string | Path/location to/of the logical reference (mount point) of this disk This tag must be enclosed by a \ref pf_tag_host tag. It then specifies where the mountpoint of a given storage device (defined by the ``id`` attribute) @@ -773,7 +784,7 @@ Here is a simple example, taken from the file ``examples/platform/storage.xml``: This example is quite interesting, as the same device, called "Disk2", is mounted by two hosts at the same time! Note, however, that the host called ``alice`` is actually -attached to this storage, as can be seen in the \ref pf_storage_entity_storage "<storage>" +attached to this storage, as can be seen in the \ref pf_tag_storage "<storage>" tag. This means that ``denise`` must access this storage through the network, but SimGrid automatically takes care of that for you. @@ -825,7 +836,7 @@ RAM -- Host B \endverbatim An easy way to model this scenario is to setup and define the RAM via the -\ref pf_storage_entity_storage "storage" and \ref pf_storage_entity_storage_type "storage type" +\ref pf_tag_storage "storage" and \ref pf_storage_entity_storage_type "storage type" entities and attach it to a remote dummy host; then, every host can have their own links to this host (modelling for instance certain scenarios, such as PCIe ...) @@ -990,7 +1001,7 @@ routing model (the path is given relative to SimGrid's source directory) \verbinclude example_filelist_routing_dijkstra -Dijkstra example : +Dijkstra example: \verbatim @@ -1040,7 +1051,7 @@ if there are no example files listed here, this is likely to be correct. \anchor pf_routing_model_full ### Full ### -Full example : +Full example: \verbatim @@ -1286,7 +1297,7 @@ to bypass some routes defined in lower level zone at an upper stage: bypasszoneroute is the tag you're looking for. It allows to bypass routes defined between already defined between zone (if you want to bypass route for a specific host, you should just use byPassRoute). -The principle is the same as zoneroute : bypasszoneroute contains +The principle is the same as zoneroute: bypasszoneroute contains list of links that are in the path between src and dst. #### Attributes #### @@ -1319,10 +1330,10 @@ attribute was not given, this route is presumed to be symmetrical. As said before, once you choose a model, it (most likely; the constant network model, for example, doesn't) calculates routes for you. But maybe you want to define some of your routes, which will be specific. You may also want -to bypass some routes defined in lower level zone at an upper stage : +to bypass some routes defined in lower level zone at an upper stage: bypassRoute is the tag you're looking for. It allows to bypass routes defined between host/router. The principle is the same -as route : bypassRoute contains list of links references of +as route: bypassRoute contains list of links references of links that are in the path between src and dst. #### Attributes #### @@ -1362,7 +1373,7 @@ and zone_2. If you want to make a host (h1) from zone_1 with another one defined inside zone_Big. If you choose some shortest-path model, this route will be computed automatically. -As said before, there are mainly 2 tags for routing : +As said before, there are mainly 2 tags for routing: \li zoneroute: to define routes between two zone \li route: to define routes between two host/router @@ -1376,7 +1387,7 @@ say that zone_1 contains full routes, and zone_2 contains some Floyd routing (as we don't want to bother with defining all routes). As we're using some shortest path algorithms to route into zone_2, we'll then have to define some route to gives some topological -information to SimGrid. Here is a file doing it all : +information to SimGrid. Here is a file doing it all: \verbatim @@ -1599,7 +1610,7 @@ platforms. \subsection pf_exit_zone Exit Zone: why and how Users that have looked at some of our platforms may have notice a -non-intuitive schema ... Something like that : +non-intuitive schema ... Something like that: \verbatim @@ -1704,7 +1715,7 @@ You may have noted that conveniently, a peer named FOO defines an zone named FOO Choosing wisely the routing model to use can significantly fasten your simulation/save your time when writing the platform/save tremendous disk space. Here is the list of available model and their -characteristics (lookup : time to resolve a route): +characteristics (lookup: time to resolve a route): \li Full: Full routing data (fast, large memory requirements, fully expressive)