X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/652eb99105d979fcd897c2f26cfbce0f7d81ecd3..78c5c8810d149086107852e20a2716689db2bfe8:/doc/doxygen/platform.doc diff --git a/doc/doxygen/platform.doc b/doc/doxygen/platform.doc index 038de80427..b35d4e575a 100644 --- a/doc/doxygen/platform.doc +++ b/doc/doxygen/platform.doc @@ -36,51 +36,86 @@ If you read the DTD, you should notice the following: \section pf_basics Basic concepts -Nowadays, the Internet is composed of a bunch of independently managed -networks. Within each of those networks, there are entry and exit -points (most of the time, you can both enter and exit through the same -point); this allows to leave the current network and reach other -networks, possibly even in other locations. -At the upper level, such a network is called -Autonomous System (AS), while at the lower level it is named -sub-network, or LAN (local area network). -They are indeed autonomous: routing is defined -(within the limits of his network) by the administrator, and so, those -networks can operate without a connection to other -networks. So-called gateways allow you to go from one network to -another, if such a (physical) connection exists. Every node in one network -that can be directly reached (i.e., without traversing other nodes) from -another network is called a gateway. -Each autonomous system consists of equipment such as cables (network links), -routers and switches as well as computers. - -The structure of the SimGrid platform description relies exactly on the same -concept as a real-life platform (see above). Every resource (computers, -network equipment etc.) belongs to an AS, which can be defined by using the -\ tag. Within an AS, the routing between its elements can be defined -abitrarily. There are several modes for routing, and exactly one mode must be -selected by specifying the routing attribute in the AS tag: +It is certainly very tempting to defining how the information is +routed in the simulated network in a way that is very similar to how +it is defined on real network. One would have to define the routing +tables of each routers interconnections sub-networks, just like in the +real life. Given the daunting amount of configuration required, we +could complete the information given by the user with classical +protocols such as BGP and RIP. Many network simulator take such +configuration as an input, for good reasons. + +This is not the way it goes in SimGrid: the network routing is defined +in a global and compact way instead. This eases the modeling of very +large systems, and allows highly optimized datastructures and +algorithms in the simulator. The proposed description mechanism is +thus much more convinient and efficient. In addition, it is more +expressive than the classical solution based on forwarding tables on +each host and router. + +The price to pay is that this representation of networks is very +specific to SimGrid, so you will have to read further to understand +it, even if you already know how real networks work. + +The central notion here are \b Networking \b Zones. NetZones represent +network areas in which the routing is done in an homogeneous way. +Conceptually, netzones generalize from the ideas of local networks +(such as Ethernet switched networks) and Autonomous System. The +network as a whole is represented as a single hierarchy of netzones, +meaning that every netzone is part of another netzone (but the \c +NetRoot, which is the top-level netzone). + +The main goal of the routing module is to provide a list of links +traversed by a given communication and/or a latency to apply. These +information are then used by the network model to compute the time +that this communication takes. This information is retrieved by three +combined algorithms: intra-zone routing, inter-zone routing, and the +bypass mechanism. + +The intra-zone level is naturally handled by the netzones. Each +netzone have to specify the routing algorithm it uses for that. +@ref{FullZone} netzones have complete matrix where matrix(a,b) +represents the full path (the list of links) between the hosts a and +b. @ref{FloydZone} apply the Floyd-Warshall algorithm to compute the +paths. @ref{ClusterZone} model classical switched or hub networks, +where each component is connected through a private link onto a common +backbone. Many other routing algorithms are provided to model the +classical needs, but you can naturally define your own routing if the +provided ones do not fit your needs. + +The inter-zone algorithm is used when the communication +traverses more than one zone. The overall path goes from the source up +in the netzones' tree, until the first common ancestor zone, and moves +down to the destination. It crawls the differing netzones on its path +according to the user-defined inter-zone routes, moving from gateway +to gateway. + +You can also use the bypass mechanism to specify manually some +shortcuts that directly provide the list of links interconnecting two +given processes. + \verbatim - + \endverbatim \remark Other supported values for the routing attribute can be found below, Section \ref pf_raf. -There is also the ```` tag; this tag takes two attributes, ``src`` (source) -and ``dst`` (destination). Both source and destination must be valid identifiers -for routers (these will be introduced later). Contained by the ```` are -network links; these links must be used in order to communicate from the source -to the destination specified in the tag. Hence, a route merely describes +There is also the ```` tag; this tag takes two attributes, +``src`` (source) and ``dst`` (destination). Both source and +destination must be valid identifiers for routers (these will be +introduced later). Contained by the ```` are network links; +these links must be used in order to communicate from the source to +the destination specified in the tag. Hence, a route merely describes how to reach a router from another router. \remark More information and (code-)examples can be found in Section \ref pf_rm. -An AS can also contain itself one or more AS; this allows you to -model the hierarchy of your platform. +A netzone can also contain itself one or more netzone; this allows you to model +the hierarchy of your platform. ### Within each AS, the following types of resources exist: @@ -92,14 +127,15 @@ router | \ref pf_router | In SimGrid, routers are used to provid link | \ref pf_link | In SimGrid, (network)links define a connection between two or potentially even more resources. Every link has a bandwidth and a latency and may potentially experience congestion. cluster | \ref pf_cluster | In SimGrid, clusters were introduced to model large and homogenous environments. They are not really a resource by themselves - technically, they are only a shortcut, as they will internally set up all the hosts, network and routing for you, i.e., using this resource, one can easily setup thousands of hosts and links in a few lines of code. Each cluster is itself an AS. -%As it is desirable to interconnect these resources, a routing has to be -defined. The AS is supposed to be Autonomous, hence this has to be done at the -AS level. The AS handles two different types of entities (host/router -and AS). However, the user is responsible to define routes between those resources, -otherwise entities will be unconnected and therefore unreachable from other -entities. Although several routing algorithms are built into SimGrid (see -\ref pf_rm), you might encounter a case where you want to define routes -manually (for instance, due to specific requirements of your platform). +As it is desirable to interconnect these resources, a routing has to +be defined. The AS is supposed to be Autonomous, hence this has to be +done at the AS level. The AS handles two different types of entities +(host/router and AS). However, the user is responsible +to define routes between those resources, otherwise entities will be +unconnected and therefore unreachable from other entities. Although +several routing algorithms are built into SimGrid (see \ref pf_rm), +you might encounter a case where you want to define routes manually +(for instance, due to specific requirements of your platform). There are three tags to use: \li ASroute: to define routes between two AS @@ -137,8 +173,8 @@ routing | yes | Full\| Floyd\| Dijkstra\| DijkstraCache\| None\| V Example: \code - - + + @@ -161,7 +197,7 @@ Attribute name | Mandatory | Values | Description --------------- | --------- | ------ | ----------- id | yes | String | The identifier of the host. facilitates referring to this AS. speed | yes | double (must be > 0.0) | Computational power of every core of this host in FLOPS. Must be larger than 0.0. -core | no | int (Default: 1) | The number of cores of this host. If more than one core is specified, the "power" parameter refers to every core, i.e., the total computational power is no_of_cores*power.
If 6 cores are specified, up to 6 tasks can be executed without sharing the computational power; if more than 6 tasks are executed, computational power will be shared among these tasks.
Warning: Although functional, this model was never scientifically assessed. +core | no | int (Default: 1) | The number of cores of this host. If more than one core is specified, the "speed" parameter refers to every core, i.e., the total computational power is no_of_cores*speed.
If 6 cores are specified, up to 6 tasks can be executed without sharing the computational power; if more than 6 tasks are executed, computational power will be shared among these tasks.
Warning: Although functional, this model was never scientifically assessed. availability_file| no | string | (Relative or absolute) filename to use as input; must contain availability traces for this host. The syntax of this file is defined below.
Note: The filename must be specified with your system's format. state_file | no | string | Same mechanism as availability_file.
Note: The filename must be specified with your system's format. coordinates | no | string | Must be provided when choosing the Vivaldi, coordinate-based routing model for the AS the host belongs to. More details can be found in the Section \ref pf_P2P_tags. @@ -177,8 +213,8 @@ Tag name | Description | Documentation ### Example ### \verbatim - - + + @@ -196,7 +232,7 @@ and a separate text file whose syntax is exemplified below. \verbatim - + \endverbatim @@ -231,7 +267,7 @@ It is also possible to specify whether the host is up or down by setting the \verbatim - + \endverbatim @@ -320,7 +356,7 @@ id | yes | string | The identifier of the cluster. Facilitate prefix | yes | string | Each node of the cluster has to have a name. This name will be prefixed with this prefix. suffix | yes | string | Each node of the cluster will be suffixed with this suffix radical | yes | string | Regexp used to generate cluster nodes name. 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. The produced number is concatenated between prefix and suffix to form machine names. -power | yes | int | Same as the ``power`` attribute of the ``\`` tag. +speed | yes | int | Same as the ``speed`` attribute of the ``\`` tag. core | no | int (default: 1) | Same as the ``core`` attribute of the ``\`` tag. bw | yes | int | Bandwidth for the links between nodes and backbone (if any). See the \ref pf_link "link section" for syntax/details. lat | yes | int | Latency for the links between nodes and backbone (if any). See link section for syntax/details. @@ -332,7 +368,7 @@ limiter_link | no | int | Bandwidth for limiter link (if any). Th loopback_bw | no | int | Bandwidth for loopback (if any). See link section for syntax/details. If loopback_bw and loopback_lat (see below) attributes are omitted, no loopback link is created and all intra-node communication will use the main network link of the node. Loopback link is a \ref pf_sharing_policy_fatpipe "\b FATPIPE". loopback_lat | no | int | Latency for loopback (if any). See link section for syntax/details. See loopback_bw for more info. topology | no | FLAT\|TORUS\|FAT_TREE\|DRAGONFLY (default: FLAT) | Network topology to use. SimGrid currently supports FLAT (with or without backbone, as described before), TORUS , FAT_TREE, and DRAGONFLY attributes for this tag. -topo_parameters | no | string | Specific parameters to pass for the topology defined in the topology tag. For torus networks, comma-separated list of the number of nodes in each dimension of the torus. For fat trees, refer to \ref simgrid::surf::AsClusterFatTree "AsClusterFatTree documentation". For dragonfly, refer to \ref simgrid::surf::AsClusterDragonfly "AsClusterDragonfly documentation". +topo_parameters | no | string | Specific parameters to pass for the topology defined in the topology tag. For torus networks, comma-separated list of the number of nodes in each dimension of the torus. For fat trees, refer to \ref simgrid::kernel::routing::AsClusterFatTree "AsClusterFatTree documentation". For dragonfly, refer to \ref simgrid::kernel::routing::AsClusterDragonfly "AsClusterDragonfly documentation". the router name is defined as the resulting String in the following @@ -349,10 +385,10 @@ Consider the following two (and independent) uses of the ``cluster`` tag: \verbatim + speed="1e9" bw="125e6" lat="5E-5"/> \endverbatim @@ -386,7 +422,7 @@ id | yes | string | The identifier of the cabinet. Facilitate prefix | yes | string | Each node of the cabinet has to have a name. This name will be prefixed with this prefix. suffix | yes | string | Each node of the cabinet will be suffixed with this suffix radical | yes | string | Regexp used to generate cabinet nodes name. 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. The produced number is concatenated between prefix and suffix to form machine names. -power | yes | int | Same as the ``power`` attribute of the \ref pf_host "<host>" tag. +speed | yes | int | Same as the ``speed`` attribute of the \ref pf_host "<host>" tag. bw | yes | int | Bandwidth for the links between nodes and backbone (if any). See the \ref pf_link "link section" for syntax/details. lat | yes | int | Latency for the links between nodes and backbone (if any). See the \ref pf_link "link section" for syntax/details. @@ -403,11 +439,11 @@ shows how to use the cabinet tag. \verbatim + speed="1Gf" bw="125MBps" lat="100us" radical="1-10"/> + speed="1Gf" bw="125MBps" lat="100us" radical="11-20"/> + speed="1Gf" bw="125MBps" lat="100us" radical="21-30"/> @@ -442,7 +478,7 @@ and values. These are: Attribute name | Mandatory | Values | Description --------------- | --------- | ------ | ----------- id | yes | string | The identifier of the peer. Facilitates referring to this peer. -power | yes | int | See the description of the ``host`` tag for this attribute +speed | yes | int | See the description of the ``host`` tag for this attribute bw_in | yes | int | Bandwidth downstream bw_out | yes | int | Bandwidth upstream lat | yes | double | Latency for both up- and downstream, in seconds. @@ -455,7 +491,7 @@ Internally, SimGrid transforms any ``\`` construct such as \verbatim @@ -465,7 +501,7 @@ is completely equivalent to the following declaration: \verbatim - + @@ -502,7 +538,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 +As said before, router is used only to give some information for routing algorithms. So, it does not have any attributes except : #### Attributes #### @@ -884,11 +920,11 @@ Here is a simple example, taken from the file ``examples/platform/storage.xml``: content="content/small_content.txt" content_type="txt_unix" attach="denise"/> - + - + @@ -1050,11 +1086,11 @@ Floyd example: - + @@ -1091,9 +1127,9 @@ routing model (the path is given relative to SimGrid's source directory) Dijkstra example : \verbatim - - - + + + @@ -1114,7 +1150,7 @@ Dijkstra example : DijkstraCache example: \verbatim - + ... (platform unchanged compared to upper example) \endverbatim @@ -1141,8 +1177,8 @@ if there are no example files listed here, this is likely to be correct. Full example : \verbatim - - + + @@ -1305,12 +1341,12 @@ This is mainly useful when you're in the \ref pf_routing_model_full "Full routin \verbatim + radical="150-299" speed="1000000000" bw="125000000" lat="5E-5" + bb_bw="2250000000" bb_lat="5E-4"/> @@ -1368,7 +1404,7 @@ A route in the \ref pf_routing_model_shortest_path "Shortest-Path routing model" \subsubsection pf_routing_tag_bypassasroute bypassASroute -%As said before, once you choose +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 AS at an upper stage: @@ -1405,7 +1441,7 @@ attribute was not given, this route is presumed to be symmetrical. \subsubsection pf_routing_tag_bypassroute bypassRoute -%As said before, once you choose +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 AS at an upper stage : @@ -1441,7 +1477,7 @@ and AS_2. If you want to make a host (h1) from AS_1 with another one (h2) from AS_2 then you'll have to proceed as follows: \li First, you have to ensure that a route is defined from h1 to the AS_1's exit gateway and from h2 to AS_2's exit gateway. -\li Then, you'll have to define a route between AS_1 to AS_2. %As those +\li Then, you'll have to define a route between AS_1 to AS_2. As those AS are both resources belonging to AS_Big, then it has to be done at AS_big level. To define such a route, you have to give the source AS (AS_1), the destination AS (AS_2), and their respective @@ -1451,18 +1487,18 @@ and AS_2. If you want to make a host (h1) from AS_1 with another one defined inside AS_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 ASroute: to define routes between two AS \li route: to define routes between two host/router -%As we are dealing with routes between AS, it means that those we'll +As we are dealing with routes between AS, it means that those we'll have some definition at AS_Big level. Let consider AS_1 contains 1 host, 1 link and one router and AS_2 3 hosts, 4 links and one router. There will be a central router, and a cross-like topology. At the end of the crosses arms, you'll find the 3 hosts and the router that will act as a gateway. We have to define routes inside those two AS. Let say that AS_1 contains full routes, and AS_2 contains some Floyd -routing (as we don't want to bother with defining all routes). %As +routing (as we don't want to bother with defining all routes). As we're using some shortest path algorithms to route into AS_2, we'll then have to define some route to gives some topological information to SimGrid. Here is a file doing it all : @@ -1470,7 +1506,7 @@ information to SimGrid. Here is a file doing it all : \verbatim - + @@ -1478,9 +1514,9 @@ information to SimGrid. Here is a file doing it all : - - - + + + @@ -1606,7 +1642,7 @@ entity. \verbatim - + @@ -1693,8 +1729,8 @@ non-intuitive schema ... Something like that : - - + + @@ -1737,21 +1773,18 @@ SimGrid allows you to use some coordinated-based system, like vivaldi, to describe a platform. The main concept is that you have some peers that are located somewhere: this is the function of the coordinates of the \ or \ tag. There's nothing -complicated in using it, here is an example of it: +complicated in using it, here is an example: \verbatim - - - - - + + ... - + \endverbatim @@ -1774,13 +1807,10 @@ That is for example what is commonly done when using peers (see Section \ref pf_ - - - - - - + + + \endverbatim