Simplenet is a module that implements a network module for use as a
component within model net.
The simplenet model is a basic cost model based on the startup cost
(latency) of the network and the bandwidth (cost per byte transferred)
of the network. Each NIC is assumed to have full-duplex transmit and
receive capability. Messages begin transmission when the sender's output
queue is available. From the sender's perspective, the transmission is
complete as soon as enough virtual time has elapsed to account for the
startup and bandwidth costs of the message. However, the message is
not delivered for processing on the receiver until the receiver's input
queue is also available. The network fabric itself is not modeled and is
instead treated as if it has infinite buffering ability and no internal
Simplenet supports optimistic mode and reverse computation.
The simplenet LPs are intended to be used in conjunction with other LPs that
implement a higher level protocol. For examples, they may be used in
conjunction with LPs that model file servers in a parallel file system.
Each simplenet LP represents a NIC. In terms of LP mapping, each simplenet
LP should also use an LP ID that is a fixed offset from the "node" that it
belongs to. Note that the offset is specified to the simplenet module at
event creation time, which means that multiple "node" LPs can share the same
simplenet LP by using different offsets.
In terms of event transmission, simplenet can be thought of as a wrapper
around other events. It tunnels the upper level events through the network
and delivers them to a remote LP, consuming some amount of virtual time
along the way according to the modeled network characteristics. The upper
level model does not have access to the simplenet LPs, the simplenet message
struct, or any other internal parameters. It is intended to abstract away
network details from some higher level model.
Simple P2P Network model
SimpleP2P is an extension of simplenet to allow for arbitrary point-to-point
SimpleP2P has nearly the same duplex queued transmission semantics as
simplenet, though with a few important differences. First, point-to-point
latencies and bandwidths are different. Network links can also have different
ingress and egress latencies/bandwidths. Second, each unique link is given its
own queue that do not interfere with the others. The use case for this model is
a set of sites with internal networks, with each site communicating via
simplep2p; we assume the internal network is capable of servicing all
outgoing/incoming WAN transmissions at their full capacities.
Additional configuration is needed to initialize the link latencies/capacities.
In the codes-configuration file, the variables "net_latency_ns_file" and
"net_bw_mbps_file" must be set under the PARAMS group. They point (in a path
relative to the configuration file) to configurations for the latency and
bandwidth costs, respectively.
Each of the latency/bandwidth configuration files have the same format, based
on a square matrix of directed point to point capacities. Given N modelnet LPs,
it has the format:
1:1 1:2 ... 1:N2:1 2:2 ... 2:N ...N:1 N:2 ... N:N
where x:y is a pair of latency or bandwidth between components x and y.
An individual entry in this matrix is specified as "a,b" where 'a' is the egress
latency/bandwidth of the link and 'b' is the ingress latency/bandwidth of the link.
Whitespace is ignored, but linebreaks are not, and delimit rows of the matrix.
The relative simplep2p identifiers 1..N are assigned to simplep2p LPs in the
order of their appearance in the codes-configuration file. It is expected that
all i:i entries are 0 - modelnet currently doesn't handle self messages.
Support in the code is also available for triangular matrices of the format:
1:2 1:3 ... 1:N2:3 2:4 ... 2:N ... N-1:N
However, this option is currently disabled (the configuration code path has not
been expanded to allow specifying the option). The option will be enabled
into the configuration routines if deemed necessary.
The model-net statistics are slightly more complex than in other model-net
implementations because there are in essence multiple queues per simplep2p
instance. In particular, the "send time" and "recv time" stats are computed as
ranges of time in which the simplep2p LP is actively sending/receiving data
from any link. Hence, simple bandwidth calculations (send bytes / send time)
may not be accurate due to skew in message issuance.
Having more than one category in simplep2p will cause the times in the
derived "all" category to be off. "all" is currently implemented as the sum of
the various categories, which doesn't work when times in certain categories may