X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/9104957deccc59e0e804215d5db498fabfd40d29..390f07ace843ed23ed4d2a1d26f90148d07836ad:/doc/doxygen/platform.doc
diff --git a/doc/doxygen/platform.doc b/doc/doxygen/platform.doc
index 2e9967f6f6..f17a30356b 100644
--- a/doc/doxygen/platform.doc
+++ b/doc/doxygen/platform.doc
@@ -111,7 +111,7 @@ c-99.me
is set to ``Cluster``.
The ``<cabinet />`` tag is, like the @ref pf_tag_cluster "<cluster>" tag,
-a meta-tag. This means that it is simply a shortcut for creating a set of (homogenous) hosts and links quickly;
+a meta-tag. This means that it is simply a shortcut for creating a set of (homogeneous) hosts and links quickly;
unsurprisingly, this tag was introduced to setup cabinets in data centers quickly. Unlike
<cluster>, however, the <cabinet> assumes that you create the backbone
and routers yourself; see our examples below.
@@ -159,11 +159,11 @@ The hosts generated in the above example are named host-1.cluster, host-2.cluste
etc.
-@subsection pf_ne Network equipments
+@subsection pf_ne Network equipment
There are two tags at all times available to represent network entities and
several other tags that are available only in certain contexts.
-1. ````: Represents a entity that has a limited bandwidth, a
+1. ````: Represents an entity that has a limited bandwidth, a
latency, and that can be shared according to TCP way to share this
bandwidth.
@remark
@@ -514,12 +514,12 @@ router1 must belong to zone1 and router2 must belong to zone2.
The purpose of this entity is to define a route between two
NetZones. Recall that all zones form a tree, so to connect two
-sibiling zones, you must give such a zoneRoute specifying the source
+sibling zones, you must give such a zoneRoute specifying the source
and destination zones, along with the gateway in each zone (ie, the
point to reach within that zone to reach the netzone), and the list of
links in the ancestor zone to go from one zone to another.
-So, to go from an host @c src_host that is within zone @c src, to an
+So, to go from a host @c src_host that is within zone @c src, to a
host @c dst_host that is within @c dst, you need to:
- move within zone @c src, from @c src_host to the specified @c gw_src;
@@ -672,7 +672,7 @@ attribute was not given, this route is presumed to be symmetrical.
@subsection pb_baroex Basic Routing Example
-Let's say you have an zone named zone_Big that contains two other zone, zone_1
+Let's say you have a zone named zone_Big that contains two other zones, zone_1
and zone_2. If you want to make a host (h1) from zone_1 with another one
(h2) from zone_2 then you'll have to proceed as follows:
@li First, you have to ensure that a route is defined from h1 to the
@@ -780,7 +780,7 @@ you say that the file trace must be used by the entity.
| Attribute name | Mandatory | Values | Description |
| --------------- | --------- | ---------------------- | ----------- |
| id | yes | String | Identifier of this trace; this is the name you pass on to @c trace_connect. |
-| file | no | String | Filename of the file that contains the information - the path must follow the style of your OS. You can omit this, but then you must specifiy the values inside of <trace> and </trace> - see the example below. |
+| file | no | String | Filename of the file that contains the information - the path must follow the style of your OS. You can omit this, but then you must specify the values inside of <trace> and </trace> - see the example below. |
| trace_periodicity | yes | String | This is the same as for @ref pf_tag_host "hosts" (see there for details) |
Here is an example of trace when no file name is provided:
@@ -910,11 +910,11 @@ non-intuitive schema ... Something like that:
In the zone_4, you have an exitzone_4 defined, containing only one router,
and routes defined to that zone from all other zone (as cluster is only a
-shortcut for an zone, see cluster description for details). If there was
+shortcut for a zone, see cluster description for details). If there was
an upper zone, it would define routes to and from zone_4 with the gateway
router_4. It's just because, as we did not allowed (for performances
-issues) to have routes from an zone to a single host/router, you have to
-enclose your gateway, when you have zone included in your zone, within an
+issues) to have routes from a zone to a single host/router, you have to
+enclose your gateway, when you have zone included in your zone, within a
zone to define routes to it.
@subsection pf_P2P_tags P2P or how to use coordinates
@@ -966,7 +966,7 @@ That is for example what is commonly done when using peers (see Section @ref pf_
In such a case though, we connect the zone created by the peer tag with the Vivaldi routing mechanism.
This means that to route between zone1 and zone2, it will use the coordinates of router_zone1 and router_zone2.
This is currently a convention and we may offer to change this convention in the DTD later if needed.
-You may have noted that conveniently, a peer named FOO defines an zone named FOO and a router named router_FOO, which is why it works seamlessly with the peer tag.
+You may have noted that conveniently, a peer named FOO defines a zone named FOO and a router named router_FOO, which is why it works seamlessly with the peer tag.
@subsection pf_routing_howto_choose_wisely Choosing wisely the routing model to use