1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
|
/**
@defgroup XBT_API XBT: SimGrid core toolbox
@brief The core toolbox of SimGrid, containing useful datatypes and friends
*/
/**
@defgroup TRACE_API TRACING
@brief Gather data about your simulation for later analysis
SimGrid can trace the resource (of hosts and links) utilization using
any of its programming interfaces (MSG, SimDAG and SMPI). This means
that the tracing will register how much power is used for each host
and how much bandwidth is used for each link of the platform.
The idea of the tracing facilities is to give SimGrid users to
possibility to classify MSG and SimDAG tasks by category, tracing the
platform utilization (hosts and links) for each of the categories.
The API enables the declaration of categories and a function to
associate them to the tasks (MSG and SD). The tasks that are not
classified according to a category are not traced. If no categories
are specified, simulations can still be traced using a special
parameter in the command line (see @ref outcomes_vizu for details).
*/
/** @defgroup ROUTING_API Routing: Determining the communication paths
@brief Organize the platform to determine the links used by each communication
@section routing_basics Basic Concepts
The purpose of the simgrid::kernel::routing module is to retrieve the
routing path between two points in a time- and space-efficient manner.
Indeed, the network model needs both the list of links that the convey
the created communication, and the summed latency that these links
represent. This operation is clearly on the critical path of most
SimGrid simulations.
When defining how the information is routed in the simulated network,
it is certainly very tempting to use a formalism somehow 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 <b>intra-zone level</b> is naturally handled by the netzones. Each
netzone have to specify the routing algorithm it uses for that.
@ref simgrid::kernel::routing::FullZone "FullZone" netzones have complete matrix where matrix(a,b)
represents the full path (the list of links) between the hosts a and
b. @ref simgrid::kernel::routing::FloydZone "FloydZone" apply the Floyd-Warshall algorithm to compute the
paths. @ref simgrid::kernel::routing::ClusterZone "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 <b>inter-zone algorithm</b> 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 <b>bypass mechanism</b> to specify manually some
shortcuts that directly provide the list of links interconnecting two
given processes.
@section routing_declaring Declaring a platform
For now, you can only declare a platform from an XML file, but we are
working to make it possible from the C++ code (or even from bindings
in other languages). Until then, please head to @ref platform.
*/
/**
@defgroup SURF_API SURF
@brief Internal kernel of all the simulators used in SimGrid, and associated models.
SURF provides the core functionnalities to simulate a virtual
platform. It is very low-level and is not intended to be used by end
users, but rather to serve as a basis for higher-level simulators. Its
interfaces are not frozen (and probably never will be), and the
structure emphasis on performance over ease of use. This module
contains the platform models. If you need a model that is not encoded
yet, please come to the devel mailing list so that we can discuss on
the feasibility of your idea.
Please note that as it is not really intended for public use, this
module is only partially documented.
*/
|
